Як підкорити застарілий код

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

За останні два десятиліття я неодноразово був у цій ситуації. Я можу допомогти.

Як зрозуміти застарілий код

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

Давайте поговоримо про те, що ви збираєтеся робити у цих нещасних випадках.

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

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

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

Тож зупинись. Зробіть крок назад і зрозумійте, що все в цій кодовій базі було зроблено певним чином з причини.

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

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

Не пустіть порожню коду.

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

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

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

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

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

Для отримання бонусних балів обов’язково діліться своїми нотатками та схемами. Помістіть їх у добре помітне місце, де наступний розробник, який з’явиться, може легко їх виявити. Не хвилюйтеся про те, щоб зробити їх ідеальними або навіть гарними. Просто роби те, що можеш. Кожна дрібниця допомагає.

Загалом, найголовніше - запастися терпінням і уникати побиття себе. Кодекс - річ складна. Розуміння застарілого коду вимагає часу. Залишайся спокійним.

Як виправити застарілий код

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

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

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

Мартін Фаулер склав каталог рефакторингу, який дасть вам гарне уявлення про типи змін, які ви можете вносити для поступового вдосконалення кодової бази. Перевірте тут. Ідея полягає в тому, щоб завжди залишати код у кращій формі, ніж це було тоді, коли ви його знайшли.

Іноді ви стикаєтеся з помилкою, яка насправді є результатом структурного дефекту. Ці помилки неможливо виправити простою зміною якоїсь умовної логіки. Вони вимагають більш інвазивних змін.

Тут все стає волохатим. Ви повинні бути брутально чесними із собою щодо того, яка мінімальна життєздатна зміна. Кожне волокно вашої істоти захоче розірвати код і переписати все це. Не робіть цього!

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

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

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

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

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

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

Як додати нові функції до застарілого коду

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

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

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

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

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

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

DO Factory має гарне пояснення шаблону адаптера:

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

Ось кілька посилань на пояснення та приклади різними мовами.

  • Приклад JavaScript шаблону адаптера
  • C # приклад адаптера
  • Приклад Java шаблону адаптера

Ключові винос

Підсумовуючи, ось ключові моменти, які допоможуть вам вирішити та врешті-решт завоювати будь-яку кодову базу:

  1. Ніколи не судіть застарілий код і не змінюйте його, поки не знайдете часу, щоб повністю його зрозуміти.
  2. Діаграми послідовностей - це ваш друг.
  3. Віддавайте перевагу невеликим, поступовим покращенням перед оптовими перезаписами чи змінами.
  4. Кожна зміна повинна намагатись залишити код трохи кращим, ніж коли ви його знайшли.
  5. Якщо вам потрібно внести серйозні зміни, спочатку зробіть бізнес-аргументацію та отримайте схвалення.
  6. Додаючи нові функції, спробуйте "йти в ногу".
  7. Якщо вам потрібно взяти код у новому напрямку, ізолюйте свої зміни та скористайтеся адаптерним шаблоном для інтеграції.

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

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