Чи є у нас відповідальність за вдосконалення Старого кодексу?

Я переглядав якийсь старий код, який я написав. Це працює, але це не великий код. Зараз я знаю більше, ніж тоді, тому могла вдосконалити. Це не поточний проект, але це поточний, робочий, виробничий код. Чи несемо ми відповідальність за повернення та вдосконалення коду, про який ми писали раніше, чи правильне ставлення «якщо він не зламався, не виправляй»? Моя компанія спонсорувала клас з перегляду коду кілька років тому, і одним із головних заходів було те, що іноді це досить добре; рухайся.

Отже, в якийсь момент ви повинні просто назвати це досить добре і рухатися далі, або ви намагаєтесь підштовхнути проекти, щоб поліпшити старий код, коли ви думаєте, що це може бути краще?

Якщо ви не будете вносити зміни до цього "старого коду", щоб виправити помилки чи додати функції, я б не потурбувався покращити його лише заради цього. Якщо ви хочете в кінцевому підсумку його вдосконалити, переконайтесь, що у вас встановлені одиничні тести, які перевірять код перед тим, як розпочати його рефакторинг.

Ви можете використовувати "старий код" для вивчення кращих практик. Якщо ви це зробите, це навчання за сумісництвом, і ви не повинні очікувати, що цей код замінить те, що випускається або розгортається клієнтами / клієнтами.

Refactor області коду, які потрібно найчастіше змінювати . Оскільки ви часто відвідуєте ці райони, рефакторинг покращить ваше розуміння коду та читабельності, коли вам доведеться їх знову відвідувати, тоді як код рефактора не має сенсу, і ніхто більше не збирається його переглянути.

Більше того, якщо ви використовуєте лише області рефактора коду, коли вам потрібно змінити їх, це дає вагому виправдання, якщо ваш рефакторинг викликає регрес . Звичайно, намагайтеся прикрити свої рефактори з одиничними тестами, але це не завжди можливо, особливо це стосується застарілого коду, і вам слід сподіватися, що великі рефакторингу створюватимуть регресії раз у раз.

Якщо вам потрібно додати функції, і ваш дизайн сповільнює вас або спричиняє дублювання, тоді рефактор . Коли я розробляю код, я майже ніколи не прогнозую, які саме зміни будуть потрібні в майбутньому. Однак, коли я додаю нові функції, я зазвичай закінчую рефакторинг спільного коду. На той момент я додав третій цикл функцій / рефакторингу, моє рефакторинг вже окупається, і мій загальний код досить стабільний.

TLDR: Refactor за потребою, немає ніяких зобов'язань.

Все, що ви робите, має вартість. У вас обмежений час на програмування. Все, що ви робите в програмуванні, слід дивитись проти: "Яка користь від цього?" і "Яка користь робити щось інше?"

Якщо ви не враховуєте можливу вартість (яка вартість чогось іншого?), То якість безкоштовна. Краще поліпшити свій код. Ви чогось навчитесь. Він буде працювати краще. Це продасть більше.

Справжнє питання - що наступне найкраще, що ви могли б зробити зі своїм часом? І тоді у вас є компроміси.

Чи буде продавати більше програмного забезпечення?

Чи спричинить це менше головних болів для підтримки?

Що ви навчитесь?

Чи стане це естетичніше?

Чи поліпшить це ваша репутація?

Задайте ці питання (та будь-які інші, що стосуються вас) щодо цієї та інших дій у вашій черзі, і це допоможе відповісти, чи варто її виправити. Ці компроміси є тим, чому економіка важлива для програмістів. Джоель сказав це до мене, а старий наставник сказав мені це ще до Джоела.

Або якщо ви хочете простішої відповіді, просто перестаньте дивитися телевізор, поки ви не зафіксуєте код. :-)

Я думаю, вам слід почати з того, щоб задати собі питання, яке, здається, було пропущено. Яким чином код поганий? І цим ви справді задаєте собі таке:

• Чи код не робить те, що він повинен робити?
• Чи викликає у вас код під час обслуговування програмного забезпечення?
• Чи код повністю автономний?
• Чи плануєте ви оновлювати чи замінювати код у будь-який час у осяжному майбутньому?
• Чи є обгрунтований діловий випадок, який ви можете зробити для оновлення коду, який вас зацікавив?

Якщо є щось, про що я дізнався за ці роки, це те, що ви не можете дозволити собі вдруге здогадуватися за фактом. Щоразу, коли ви вирішуєте проблему з кодом, ви дізнаєтесь щось і, ймовірно, побачите, як ваше рішення - чи щось подібне - могло б бути кращим рішенням проблеми, яку ви вирішили по-різному років тому. Це гарна річ, адже вона показує, що ви дізналися зі свого досвіду. Однак справжнє питання полягає в тому, чи може код, який ви писали раніше, ставши застарілою проблемою, з якою складніше вирішуватись із часом.

Про що ми говоримо насправді, це те, чи легко чи важко підтримувати код, який вас турбує, і наскільки витратним буде те, що пройде час з плином часу. Це по суті питання про технічний борг і про те, чи варто погасити цю заборгованість за допомогою невеликого хірургічного обслуговування зараз чи борг є досить малим, що ви можете дозволити йому ковзати на деякий час.

Це питання, які вам справді потрібно зважити на теперішнє та майбутнє навантаження на роботу, і їх слід детально обговорити з вашим керівництвом та командою, щоб краще зрозуміти, куди інвестувати свої ресурси та чи варто ваш старий код час, який вам може знадобитися витратити на це - якщо взагалі. Якщо ви можете зробити хороший бізнес-приклад для внесення змін, то будь-якими способами зробіть це, але якщо ви зіткнулися з бажанням повозитися з кодом, тому що ви збентежилися з приводу того, як ви це написали, то я пропоную, що немає приміщення для особистої гордості, коли мова йде про підтримку старого коду. Це або працює, або ні, і це просто простий у обслуговуванні, або дорогого утримання, і це ніколи не є добре або погано просто тому, що сьогоднішній досвід був вам недоступний вчора.

Однозначно не вдосконалюйте його лише заради покращення. Як вже говорили інші (і це здоровий глузд), у нас все стає кращим (для деякого значення "кращого") з часом. Однак, перегляд коду (формально чи неофіційно) часто висвітлює ці шматочки, які, мабуть, бажаємо ніколи більше не побачити світло дня.

Хоча я не вірю, що ми несемо відповідальність за повернення та вдосконалення коду, який не є принципово порушеним, незахищеним або залежить від особливостей у застарілому списку / EOL, ось деякі речі, які я робив раніше в цій ситуації :

• Визначте людей у ​​команді, які справді копаються назад та покращують код, як своєрідне очищення мозку чи приємне завдання з розміром укусів, яке дає відчуття виконання, і знайдіть час у графіку, щоб вони це робили регулярно. У мене завжди було в команді принаймні один із таких людей, і такий підхід також може підвищити моральний стан (або принаймні настрій), якщо ми всі в затишному або спадному періоді.

• Використовуйте його як основу для навчальної вправи. Для стажистів, студентів або нових / молодших членів команди, рефакторинг старого коду з керівництвом старших членів команди дає їм можливість спілкуватися з новими членами команди, більше розуміти систему та ввійти в звичку писати / оновлення тестів модулів та робота з постійною інтеграцією. Важливо зауважити, що ця вправа виконується з настановами та чітко оформлена як вправа для поліпшення коду, оскільки він не відповідає чинним стандартам / нормам.

Отже, відповідальності за її виправлення не потрібно, але старі речі можуть бути дуже корисними. А одиничні тести та ІС - ваші друзі!

Не обов'язково. Однак якщо ви виконуєте технічне обслуговування коду і трапляєтеся натрапити на щось, що може бути кращим, ви можете змінити це за умови, що у вас є відповідні одиничні тести, щоб переконатися, що ви не створили регресію.

Якщо таких тестів не існує, і ви не можете бути впевнені, що він буде вести себе саме так, як слід, вам краще залишити його в спокої.

З точки зору інженера, я впевнений, що я дуже хотів би працювати над старим кодом, поки його більше не можна покращити. Але чи є справа для цього? Зрештою, код є для того, щоб внести свій внесок у підсумок, прибутковість вашого робочого місця. Якщо це не так, просто залиште його.

Є великий застереження, якщо, вдосконалюючи код, ви збираєтеся уникати помилок (думаючи, що тут великі кульки Y2K ..), я б точно визначив це з кимось вище, можливо, менеджером вашого бізнес-підрозділу, та обговорити наслідки вдосконалення коду.

Щодо мене, питання можна перефразовувати та узагальнювати: "Чому хтось повинен витрачати додатковий ресурс (час, гроші, розумові тощо), якщо цей конкретний фрагмент коду зараз працює нормально? Чи це не витрата ресурсів (-ів) ? "

Кожен раз, коли я знаходжу застарілий код, я думаю про кілька речей, які здаються важливими.

1. Для чого я збираюся внести зміни?
2. Чи потрібно мені підтримувати цей код? Як швидко це може статися (найближче / далеке майбутнє)?
3. Чи цей код досить зручний для роботи? (Негайно)
4. Чи можу я бути впевнений, що всі зміни, які я роблю, є безпечними? Різні тести зазвичай допомагають відповісти на це питання.
5. З якими наслідками я можу зіткнутися, якщо помиляюсь (-ла) під час зміни коду? Чи можливо відновити зміни швидко? Це буде марною тратою часу?
6. ...

Власне, вам слід задати собі багато питань. Повного та остаточного їх переліку немає. Лише ви та, можливо, ваші товариші по команді можуть знайти відповідь.

PS Я помітив, що я, як правило, переписую код дуже часто, тоді як мій друг і товариш по команді, як правило, залишають його недоторканим. Це тому, що ми відповідаємо на вказані питання по-різному. І я мушу сказати, що ми дуже часто відповідаємо на них неправильно ... тому що не можемо передбачити майбутнє.

Чи потрібно Microsoft оновлювати Windows? Чи повинні всі * nix Distros продовжувати розвиватися? Або більш практичний приклад, чи все ще всі водять машини 1970-х?

Ви можете звичайно писати код краще другий раз, ви дізналися більше про домен, написавши його спочатку.

Немає простої відповіді для того, щоб промокати, варто підкріпитися. Як правило, ви не повинні, якщо: a) це хороший досвід для вас чи б) ви заощадите час у довгостроковій перспективі з кращим кодом. Пам'ятайте про кожну зміну ризикують помилки.

Як бічну зауваження, я настійно виступаю за одиничні тести. Дуже легко приховати рефракції, особливо якщо у вас поточна поведінка чітко не позначена автоматизованими залишками.

Я вважаю, що ми несемо відповідальність написати найкращий код, який ми можемо сьогодні. Це означає використовувати все, про що ми навчилися в минулому, і відмовитися від скорочень у дизайні. Якщо тиск у графіку змушує щось скоротити, я не вважаю, що якість нашого програмного забезпечення навіть слід враховувати, а ось цей акуратний маленький анімований скріпку з іншого боку ...

Тепер, якщо ви працюєте і виявите, що код, з яким потрібно взаємодіяти, не записується до рівня, на який ви зараз здатні писати, то розумно це виправити, якщо ви зможете це зробити контрольованим методичним способом. Я особисто маю дуже мінімальний досвід роботи з подібним рефакторингом, як і всі (майже всі?) Я спробував цілий "дозволяє просто змінити все і молитися, щоб це працювало" і перекусив це досить погано. Я б запропонував вивчити дискусії Мартіна Фаулера (або його книгу, або одну з багатьох статей ) з цього питання. Він, здається, надихнув більшість поточних думок на процес.

Звичайно, іноді ви не зможете очистити код так, як хотілося б. Джоел Спольський написав статтю про те, чому ви, можливо, захочете присвятити кілька тижнів, щоб просто змінити код. Прочитайте його тут і так, воно трохи старе, але я думаю, що інформація все ще є актуальною.

Я сподіваюся, що це допомагає

Я відчуваю, що рефакторинг / поліпшення старого коду визначає сам програміст. Бажаючи вдосконалити код, який ви написали рік тому, це лише показує ваш прогрес, і якщо це покращить програму, і ви маєте можливість, час та схвалення покращити її, зробіть це.

Краще / вдосконалено багаторівневе порівняння. Як ви думаєте, ви можете зробити її швидшою, меншою, більш ефективною з ресурсів, більш читаною, кориснішою інформацією, більш точними результатами, більш гнучким, більш загальним, здатним працювати в більшій кількості систем, усунути залежність від окремого продукту?

Чому ваша компанія повинна платити вам витрачати час на перезапис цього коду, замість того, щоб писати новий код або переписувати якийсь інший фрагмент коду?

Ви повинні вдосконалюватись, оскільки представлена ​​можливість, але можливість означає, що ви вже працюєте над кодом, або ви вказали ділову причину для внесення змін.

Натискання змін на виробництво створює ненульовий шанс зламати речі (одиничне та функціональне тестування лише зменшують цей шанс, вони не усувають його), і робити це слід лише тоді, коли очікувана користь перевищує ризик.

Який ще один момент слід врахувати - чи ВИМОГАєте ви змінити виробництво або просто галузь розвитку? Штрих для двох сценаріїв абсолютно різний. Якщо він збирається лише у галузі розвитку, і ніколи не може потрапити у виробництво, тоді можливість в основному означає, що ви дивитесь на якийсь код, і це не забирає багато часу. Вона може бути переглянута за потребою, якщо коли-небудь відбудеться поштовх, і вийти з ладу, якщо в цей час вона вважається невиправданою . Якщо, з іншого боку, зараз вийде на виробництво, як я вже говорив вище, вам потрібно врахувати, чи варта ця зміна вартості: з точки зору часу, витраченого на натиск, та переваг використання нового коду.

Хорошим правилом є те, що якщо вам знадобився час, щоб зрозуміти, що робить код, і якщо цей час вдасться скоротити, рухаючись вперед деякими добре підібраними рефакторингами, то ви обслуговуєте потреби бізнесу та своєї команди шляхом роблячи ці кроки.

Якщо код не приносить користі вашому аналізу, якщо назви полів не стали виражати наміри коду і методи не були розбиті на читабельні фрагменти, то бізнес втратив щось цінне: ваш стан розуміння. З такими інструментами, як Visual Studio та ReSharper, такі види рефакторингу є безпечними, логічно нейтральними та можуть мати велике значення для продуктивності та впевненості майбутніх розробників.

Як каже дядько Боб Мартін, "завжди залишайте табір більш чистим, ніж ви знайшли".

Це питання, яке потрібно задати керівництву вашої компанії.

Чи є у вас час та ресурси, необхідні для повернення та внесення змін до старого коду?

Чи є у вас час та ресурси, щоб команда з контролю якості перевірила те, що ви змінили, щоб переконатися, що воно не порушено?

Я потрапив у цю пастку раніше, де я опинився б у модулі, що виправляв помилку, і побачив код, який я чи хтось інший написав, що це було неефективно або неелегантно, змінити його і в кінцевому підсумку виникнути більше проблем, ніж вирішити, ніж якщо я щойно виправив помилку, яку мені доручили виправити.

Це залежить.

Якщо код, про який йдеться, справді зламаний, так що він містить помилки, які неминуче з'являться в одній точці (наприклад, лічильник, який в якийсь момент переповниться і спричинить неприємні проблеми), тоді виправлення цих проблем може бути вартим зусиль - але якщо ви зробіть усі можливі гарантії першими, щоб уникнути нових помилок: переконайтеся, що у вас є значущі тестові одиниці, що охоплюють усе, що ви торкаєтесь, перегляньте всі свої зміни хтось компетентний, наполягайте на ретельному тестуванні, переконайтеся, що ви зможете повернутися до старого версії в будь-який час, створити резервну копію будь-яких даних перед початком виробництва, спершу розгорнутись у середовищі прийняття та перевірити її фактичними користувачами тощо. Ви також хочете отримати схвалення перед тим, як продовжувати роботу: якщо помилка справді бомба за часом , а ваш менеджер дещо компетентний,ви зможете переконати його / її дозволити вам виправити це (і якщо ви не отримаєте схвалення, то, можливо, це знак того, що ви помиляєтесь).

ОТОХ, якщо у вашої скарги є лише відсутність елегантності коду, тоді не смійте торкатися її. Вже тривалий час ви працюєте у вірній службі на виробництві, зміна коду лише задовольнить вас, але не додасть ніякої цінності, і, як і кожна зміна, є ризик, що ви щось зламаєте. Навіть якщо ви цього не зробите, ваш час є цінним (буквально: вам платять за те, що ви робите, тому кожна хвилина вашого часу коштує грошей), і оскільки ви не додаєте жодної фактичної цінності, така зміна буде чистий збиток для компанії та проекту.