Що таке legacy-код і як з ним працювати
Джерело: Dou Рано і пізно програмісту, напевно, доведеться зустрітися з legacy-кодом. Щоб полегшити наслідки цього знайомства, я підібрав кілька практичних порад та прикладів із власного досвіду — зокрема роботи з успадкованою Java-системою.Особливості legacy
Legacy (спадщина) - це чужий код, який часто буває жахливий настільки, що виявляється взагалі незрозуміло, як з ним працювати. І якщо вам доведеться працювати з legacy-системою, крім старого коду ви також зустрінетесь:- із застарілою технологією;
- неоднорідною архітектурою;
- недоліком чи навіть повною відсутністю документації.
-
Ми не можемо зневажливо ставитися до системи, яка заробляє мільйони, або до якої звертаються тисячі людей на день. Як би погано вона не була написана, цей огидний код дожив до продакшена і працює в режимі 24/7.
-
Якщо ця система приносить реальні гроші, робота з нею пов'язана з великою відповідальністю. Це не стартап у стіл, а те, з чим користувачі працюватимуть уже завтра. Це має на увазі і дуже високу ціну помилки, причому справа тут не в претензіях клієнта, а в реальному стані речей.
Зворотній інжиніринг
Для успішної роботи з legacy-кодом доведеться скористатися прийомами reverse engineering. Для початку потрібно уважно читати код, щоб точно розуміти, як саме він працює. Це обов'язково, адже документації ми, швидше за все, не матимемо. Якщо ми не зрозуміємо ходу думок автора, робитимемо зміни з непередбачуваними наслідками. Щоб убезпечити себе від цього потрібно вникати ще й у суміжний код. І при цьому рухатися не лише вшир, а й углиб. Звідки викликається метод із помилкою? Звідки викликається код, що викликає? У legacy-проекті "call hierarchy" і "type hierarchy" використовується частіше, ніж будь-що ще. Доведеться провести багато часу з відладчиком: по-перше, щоб знаходити помилки, і, по-друге, щоб зрозуміти, як усе працює. Щодо документації, не зайвим буде вдатися до промислової археології. Дуже корисно буває відкопати десь стару документацію і поговорити з тими, хто пам'ятає, як писався код, що дістався вам. Використовуючи ці прийоми, рано чи пізно ви почнете більш менш розуміти код. Але щоб ваші зусилля не пішли прахом, ви повинні обов'язково відразу документувати результати своїх пошуків. Для цього я раджу малювати блок-схеми чи діаграми послідовності (sequence diagrams). Звичайно, вам буде ліньки, але робити це точно потрібно, інакше через півроку без документації ви самі в цьому коді копатиметеся як вперше. Для цього я раджу малювати блок-схеми чи діаграми послідовності (sequence diagrams). Звичайно, вам буде ліньки, але робити це точно потрібно, інакше через півроку без документації ви самі в цьому коді копатиметеся як вперше. Для цього я раджу малювати блок-схеми чи діаграми послідовності (sequence diagrams). Звичайно, вам буде ліньки, але робити це точно потрібно, інакше через півроку без документації ви самі в цьому коді копатиметеся як вперше.Не переписуйте код
Найважливіше у процесі розробки — вчасно бити себе по руках і не намагатися переписати весь код наново. Прикиньте, скільки людино-років для цього потрібно. Навряд чи замовник захоче витратити стільки грошей на переробку того, що вже й так працює. Це стосується не лише системи загалом, а й будь-якої її частини. Вам, звичайно, можуть дати тиждень на те, щоб у всьому розібратися, і ще тиждень на те, щоби щось виправити. Але навряд чи дадуть два місяці на написання частини системи наново. Натомість реалізуйте новий функціонал у тому самому стилі, в якому написаний решта коду. Іншими словами, якщо код старий, не варто піддаватися спокусі використовувати нові красиві технології: такий код потім буде дуже важко читати. Наприклад, ви можете зіткнутися із ситуацією, яка була у нас: частина системи написана на Spring MVC, а частина — на голих сервлетах.Дотримуйтесь бізнес-інтересу
Потрібно пам'ятати, що будь-які завдання обумовлені насамперед цінністю для бізнесу. Якщо ви не доведете замовнику необхідність тих чи інших змін із погляду бізнесу, цих змін не буде. А для того, щоб переконати замовника, ви повинні спробувати стати на його місце та зрозуміти його інтереси. Зокрема, якщо вам хочеться провести рефакторинг лише тому, що код погано читається, вам не дадуть цього зробити, і з цим треба змиритись. Якщо зовсім неспроможна, реорганізовувати код можна по-тихому і потроху, розмазуючи роботу з бізнес-тикетів. Або переконати замовника у цьому, що це, наприклад, скоротить час, необхідне пошуку помилок, отже, зрештою скоротить витрати.Тестуйте
Зрозуміло, що тестування необхідне у будь-якому проекті. Але при роботі з legacy-системами тестуванню потрібно приділяти особливу увагу ще й тому, що вплив змін, що вносяться, не завжди передбачувано. Тестувальників потрібно не менше, ніж розробників, інакше у вас має бути все просто неймовірно добре з автоматизацією. У нашому проекті тестування складалося з наступних фаз:- Верифікація, коли реалізований функціонал фічі перевіряється окремій гілці.
- Стабілізація, коли перевіряється гілка релізу, де всі фічі злиті разом.
- Сертифікація, коли все те ж саме проганяється ще раз на дещо інших тест-кейсах у сертифікаційному оточенні, максимально наближеному до продакшена за характеристиками заліза та конфігурації.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ