Не вирок, а виклик. Як працювати з легасі-кодом — практичні поради розробникам

Легасі-код — необов’язково погано написаний код. Ним може бути й нещодавно створений код на основі сучасних технологій. Хоча здебільшого з легасі доводиться мати справу, заходячи в старий проєкт. Його буває важко читати, підтримувати й змінювати. Виникає чимало проблем для всієї команди. Розробникам доводиться витрачати багато зусиль на пошук рішень, переписувати частини коду, вводити додаткові перевірки. Бізнес втрачає в динаміці розвитку проєкту, марнує ресурси на обслуговування продукту та додавання нових фіч…

Однак не все так погано.

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

Павло Попов (зліва) та Олександр Квасенко (справа), PHP-розробники з команди NIX

Як зрозуміти, що легасі-код потребує змін

Виявити проблеми на рівні бізнесу

Коли застосунок заважає досягати потрібної клієнту мети, легасі потрібно замінювати якомога швидше. Тут варто дивитися ширше, не лише на базові KPI. Суто технічні проблеми, про які розкажуть тільки розробники, теж призводять до фінансових втрат. Наприклад, якщо написання функціонала вимагає забагато часу через «‎розплутування» нашарувань старого коду. Або ж якщо архітектура ускладнює масштабування чи адаптацію продукту до сучасних вимог.

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

Надайте замовнику наочні пояснення потреби змін — його «мовою‎». Покажіть, яку конкретну користь для бізнесу матиме оновлення легасі-коду і як це вплине на розвиток проєкту. Наводьте цифри, наприклад, потрібний час на рефакторинг, можливе зростання прибутку. Клієнт має чітко розуміти, як окупиться оновлення легасі-коду й скільки часу це займе.

Визначити відповідність коду поточним завданням проєкту

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

Робота з легасі-кодом: які знання та навички потрібні

Не обов'язково мати специфічний досвід. Рефакторинг за своєю суттю базується на загальних принципах програмування. Будь-якому фахівцю достатньо з цими знаннями зануритися в проєкт, щоб розібратися в його функціоналі та побачити, що не так і що треба виправити. Саме заглиблення відіграє важливу роль. Адже без розуміння, як усе організовано (від архітектури до окремих частин коду), неможливо якісно переписати легасі та при цьому не створити нових багів.

Проте не обійтися без практичного досвіду рефакторингу. Інакше не вийде обрати дійсно гарний шлях для оновлення коду.

Навички рефакторингу важливі й з інших причин:

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

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

Як оновити легасі-код — основні кроки

1. Аналіз коду

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

Звісно, ви ще й матимете цілісну картину. Наприклад, якщо оновлення вимагає понад 80 % коду, то тут краще написати все з нуля. Аналогічна ситуація — коли треба змінити не просто фреймворк, а версію мови, інфраструктурні елементи чи екосистему. Часто це вимагає капітальної перебудови проєкту.

2. Створення роадмап

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

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

3. Рефакторинг

Насамперед визначте, з якими технологіями на проєкті ви не знайомі та вирішіть: вивчатимете спочатку їх чи візьметеся за знайомі? Єдиного правильного рішення немає:

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

Тож треба комплексно оцінити все наявне в коді: від продуктивності до частоти оновлення інструментів. Іноді нехай і тимчасовим, але гарним рішенням буде поєднання старих і нових технологій.

4. Тестування

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

Жодних специфічних перевірок, набір стандартний:

• юніт-тести;
• інтеграційні тести;
• функціональні;
• тестування навантаження.

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

Рефакторинг не повинен «‎застопорити» розвиток проєкту

Робіть невеликі ітераційні зміни

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

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

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

Працюйте над оновленням коду паралельно з основним проєктом

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

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

Створюйте нову систему

У чомусь це схоже на попередній варіант: окрема команда працює над старим кодом, але не оновлює його, а переписує з нуля. Функціонал залишається старим, але легасі замінюється більш продуктивним рішенням. І коли ця команда закінчить роботу, проєкт частинами переносять на нову систему.

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

Як документувати оновлення легасі-коду

Одна з поширених причин виникнення легасі — проблеми з документування коду. Часто на проєктах від самого початку не створили правил документування або їх недостатньо, чи взагалі не дотримувалися. Зрештою нові учасники команди не розуміють ні логіку, ні залежності, ні інші важливі для оновлення речі. Тому під час рефакторингу варто коректно документувати всі нововведення:

• Пишіть зрозумілий код. Якісний код не потребує коментарів — у ньому все й так зрозуміло. Сьогодні дехто може вважати коментарі в коді олдскулом. Проте за бажання можете додавати їх. Це точно не завадить новим розробникам.
• Ведіть документацію. Це може бути технічна, функціональна та інші види документації чи гайдів. Їх можна доповнювати схемами чи діаграмами для пояснення окремих залежностей між частинами коду.
• Використовуйте систему контролю версій. Фіксуйте і детально описуйте в комітах кожну зміну в легасі: що й чому модифікуєте, чому саме так тощо. Не можна допускати, коли щось описано в Jira, а щось — лише в документації.
• Описуйте не тільки новий код. В ідеалі треба вести документацію для всіх фрагментів легасі, які ви оновлюєте. Навіть первинна документація стане допоміжною під час роботи над новими фічами чи в подальшій підтримці проєкту.

Чекліст оцінки успішності рефакторингу

#1 Стабільна функціональність

Ідея рефакторингу — змінити код, а не функціонал. Тому передусім переконайтеся, що після оновлення продукт надає ті самі можливості, що й раніше.Часто через складність переписування окремих фрагментів коду команда йде на компроміс та спрощує функціонал. А це може погіршити проєкт.

#2 Витримані терміни

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

#3 Позитивні відгуки

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

#4 Пришвидшення розробки

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

#5 Покращення продукту

Тут традиційні KPI: стабільність, швидкість завантаження контенту чи відгуку на запит, рівень безпеки. Щонайменше ці показники мають бути не гіршими, ніж до оновлення. А в ідеалі — стати кращими.

Як не створити новий легасі

При оновленні застарілого та заплутаного коду є ризик появи такого самого коду. Тому в процесі роботи...

• Думайте стратегічно. Ви маєте створити архітектуру зі стабільним фундаментом для подальшої розбудови проєкту. З іншого боку — намагатися дивитися майбутнє та бачити можливі шляхи розвитку продукту. Цей підхід допоможе закласти основу для додавання необхідного функціоналу. Якщо цього не зробити, то за зміни вимог чи для нових фіч можуть знадобитися якісь «‎милиці».
• Обирайте довготривалі рішення. Це дасть змогу довше зберегти технологічну актуальність проєкту. Зважайте на популярність фреймворку, на частоту оновлень, активність спільноти, яка ним користується, кількість пов’язаних бібліотек, якість документації тощо. Навіть якщо розробник такого рішення раптом зупинить свою роботу, фреймворк за інерцією житиме досить довго.
• Дотримуйтеся правил програмування. За класикою: пишіть чистий та зрозумілий код за принципами SOLID, слідуйте правилам роботи на вашому проєкті, ведіть документацію, впроваджуйте систему тестів та моніторингу. А ще не забувайте стежити за технічним боргом. Інакше кількість проблем швидко зростає і немов сніжний ком руйнує злагоджену роботу.
• Налаштуйте систему код рев’ю. Так ви бачитимете, чи в правильному напрямку «розплутуєте» легасі, чи стає код зрозумілішим, чіткішим, чи дійсно ваша робота допомагає іншим девелоперам.