Як бічна примітка: пошук нової роботи. Цей не став би кращим.
Цілями коду, який ви переглядаєте, є:
Поставити функцію, яка повинна працювати відповідно до вимог.
Щоб зменшити зростання технічної заборгованості.
Перша мета переглядається, перевіряючи, чи є тут блок тестування, інтеграція, системні та функціональні тести, що вони є релевантними та що вони охоплюють усі ситуації, які потрібно перевірити. Ви також повинні перевірити переконання, які може мати оригінальний автор щодо мови програмування, що може призвести до тонких помилок або до коду, який робить вигляд, що робить щось інше від того, що він насправді робить.
Друга мета - та, на яку зосереджено ваше питання. З одного боку, не передбачається, що новий код збільшить технічну заборгованість. З іншого боку, область огляду - це сам код, але в контексті всієї бази коду. Звідти ви, як рецензент, можете сподіватися на два підходи від оригінального автора:
Зовнішній код - не моя вина. Я просто реалізую цю функцію і не хвилююся про всю кодову базу.
У цьому ракурсі код буде копіювати недоліки кодової бази і так неминуче збільшуватиме технічну заборгованість: більше поганого коду завжди гірше.
Хоча це дійсний короткостроковий підхід, в довгостроковій перспективі це призведе до збільшення затримок і низької продуктивності, і в кінцевому підсумку призведе до того, що процес розробки буде настільки дорогим і ризикованим, що продукт перестане еволюціонувати.
Написання нового коду - це можливість рефакторного застарілого.
У цій перспективі вплив недоліків застарілого коду на новий може бути обмежений. Більше того, технічну заборгованість можна зменшити або принаймні не збільшити пропорційно зростанню коду.
Хоча це дійсний довгостроковий підхід, він має свої короткотермінові ризики. Найголовнішим є те, що в короткостроковому періоді іноді знадобиться більше часу, щоб передати певну особливість. Ще одним важливим аспектом є те, що якщо застарілий код не перевіряється, його рефакторинг становить величезний ризик введення регресії.
Залежно від точки зору, яку ви хочете заохотити, ви можете бути схильні порадити рецензуючим рефактор більше чи ні. У всіх випадках не сподівайтесь на бездоганний чистий фрагмент коду з приємною архітектурою та дизайном всередині шаленої бази даних. Те, що не слід заохочувати, - це поведінка, коли досвідчений розробник, який повинен працювати над шаленою кодовою базою, намагається добре виконати свою роль . Замість того, щоб робити речі простішими, це лише ускладнює їх, ніж раніше. Тепер замість уніфікованого поганого коду ви маєте частину з моделями дизайну, іншу частину з чистим, чітким кодом, іншу частину, яка значно змінилася з часом, і жодної єдності.
Уявімо, наприклад, що ви відкриваєте застарілу базу коду веб-сайту середнього розміру. Ви здивовані відсутністю будь-якої звичної структури та тим, що ведення журналу, коли це робиться, робиться шляхом додавання матеріалів до текстового файлу вручну, замість того, щоб використовувати рамку реєстрації. Ви вирішили для нової функції використовувати MVC та рамку ведення журналу.
Ваш колега реалізує ще одну особливість і дуже здивований відсутністю ORM, де можна було б зробити ідеальний розмір. Тож він починає використовувати ORM.
Ні ви, ні ваш колега не можете пройти сотні тисяч рядків коду, щоб використовувати MVC, або систему реєстрації журналів, або ORM скрізь. Власне, це вимагало б місяців роботи: уявіть, щоб запровадити MVC; скільки часу це займе? А як щодо ORM у ситуаціях, коли запити SQL хаотично генерувались шляхом конкатенації (з випадковими місцями для ін'єкцій SQL), всередині коду ніхто не міг зрозуміти?
Ви думаєте, що ви зробили чудову роботу, але зараз новий розробник, який приєднається до проекту, повинен зіткнутися з набагато більшою складністю, ніж раніше:
Старий спосіб обробки запитів,
Шлях MVC,
Старий механізм лісозаготівель,
Рамка реєстрації,
Прямий доступ до бази даних із SQL-запитами, побудованими на льоту,
ОРМ.
В одному проекті, над яким я працював, було чотири (!) Рамки ведення журналу, які використовувались поряд (плюс ручний журнал). Причина полягає в тому, що кожного разу, коли хтось хотів вести журнал, не було спільного підходу до цього, тому замість вивчення нового фреймуворку (який у всіх випадках використовувався лише у 5% кодової бази), просто додавали б ще одного вже знає. Уявіть безлад.
Кращим підходом було б переробляти кодову базу покроково. Взявши ще раз приклад ведення журналу, рефакторинг складається з наступних невеликих кроків:
Знайдіть усі місця, де робиться застарілий журнал (тобто, коли безпосередньо до файлу журналу можна отримати доступ), і переконайтесь, що всі вони викликають однакові методи.
Перенесіть цей код до спеціальної бібліотеки, якщо це можливо. Я не хочу зберігати логіку зберігання даних у класі кошика.
Змініть, якщо потрібно, інтерфейс методів ведення журналів. Наприклад, ми можемо додати рівень, який вказує, чи є повідомлення неофіційним, чи це попередження чи помилка.
Використовуйте щойно відновлені методи в новій функції.
Перехід до системи реєстрації журналів: єдиний код, на який впливає, - код у спеціальній бібліотеці.