Як оцінити вартість legacy-міграції

Legacy-міграція — один із найскладніших проєктів для бюджетування. Код «уже працює», тож стейкхолдери очікують, що переписування буде швидким і дешевим, — тоді як інженери знають, що ризиковані й дорогі частини зазвичай непомітні ззовні. Достовірна оцінка — це не вгадування числа, а системне виявлення того, що насправді формує вартість. У цьому матеріалі — фреймворк, який ми у WebMriya використовуємо для оцінки міграцій фронтенду, разом із практичним прикладом і реальними цифрами.

Чому бюджети міграцій зриваються

На відміну від розробки з нуля, міграція обмежена рішеннями, які хтось ухвалив роки тому. Бізнес-логіка часто захована у в’ю, поведінка не задокументована, а «крайні випадки» кодують реальні вимоги клієнтів, про які вже ніхто не пам’ятає. Вартість визначається не переписуванням UI, а реверс-інжинірингом наміру й збереженням поведінки. Саме тому кількість рядків коду сама по собі оманлива.

1. Проаудитуйте наявний код

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

• Обсяг: кількість екранів/маршрутів, окремих компонентів, а також частка перевикористовуваного UI проти одноразового.
• Фреймворк і версія: AngularJS 1.x, jQuery, Backbone чи застарілий React/Angular — у кожного свій шлях міграції.
• Залежності: скільки сторонніх бібліотек закинуто й у яких немає сучасного аналога.
• Покриття тестами: наявні автотести — найбільший фактор зниження ризику міграції.
• Стан і потоки даних: глобальний змінюваний стан, двостороннє зв’язування й пряма робота з DOM дорого розплутуються.
• Зв’язаність із бекендом: наскільки логіка представлення протікає у шаблони й наскільки жорстко UI прив’язаний до конкретних форматів API.

2. Оберіть стратегію міграції

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

• Big-bang переписування: збудувати застосунок на новому стеку й переключитися разово. Менше витрат на координацію, але високий ризик і тривалий період без відвантажуваної цінності.
• Поетапна (strangler-fig): старе й нове працюють паралельно, міграція йде маршрут за маршрутом або фіча за фічею. Патерн описав Мартін Фаулер; він потребує більше «риштувань» на старті, але ви релізите безперервно й знижуєте ризик поступово — зазвичай кращий вибір для продуктів в активному використанні.

3. Визначте справжні драйвери вартості

Два застосунки з однаковою кількістю екранів можуть відрізнятися у вартості міграції в 3–4 рази. Ось фактори, що реально впливають на оцінку:

1. Бізнес-логіка у шарі представлення — чим більше логіки у шаблонах і контролерах, тим більше доведеться реверс-інжинірити.
2. Складність керування станом — двостороннє зв’язування й спільний змінюваний стан потребують ретельного перемоделювання у односпрямованому світі.
3. Прогалини в дизайн-системі — якщо немає бібліотеки компонентів, ви фактично будуєте її паралельно з міграцією.
4. Приховані й недокументовані функції — feature-флаги, екрани під конкретні ролі та рідко використовувані сценарії, що спливають лише під час тестування.
5. Покриття тестами — низьке покриття означає ручну регресію кожного екрана, що домінує у вартості QA.
6. Вимоги до браузерів, пристроїв і доступності — суворі матриці підтримки множать зусилля на перевірку.
7. Готовність бекенду — міграції часто виявляють, що API теж потребують перебудови, а це розширює обсяг.

4. Побудуйте оцінку

Маючи аудит і драйвери вартості, оцінюйте знизу вгору, а не згори вниз. Розбийте застосунок на модулі, оцініть кожен і зведіть докупи:

• Оцінюйте помодульно (або помаршрутно), а не застосунок цілком — малі одиниці набагато легше оцінити точно.
• Класифікуйте кожен модуль як простий, середній чи складний і калібруйте за одним модулем, який мігруєте першим як еталон.
• Додавайте явні буфери на інтеграцію, QA і стабілізацію — зазвичай 20–35% залежно від покриття тестами.
• Враховуйте паралелізацію: більше інженерів скорочує календар, але додає витрати на координацію, а не лінійне пришвидшення.

Практичний приклад (із цифрами)

Щоб було конкретно — ось показовий приклад із нашої практики (анонімізований). Fintech-компанія звернулася з платформою на AngularJS 1.x: 40 екранів, інтенсивне двостороннє зв’язування даних і лише 12% покриття тестами. За помодульним фреймворком вище — і мігрувавши спершу один еталонний модуль — ми оцінили роботу в 23 інженеро-тижні. Фактична доставка склала 26 тижнів (+13%); перевитрату майже цілком спричинили недокументовані сценарії під конкретні ролі, що спливли лише під час QA.

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

5. Поширені помилки бюджетування

• Оцінка лише за кількістю екранів, без урахування прихованої логіки й складності стану.
• Припущення, що переписування дешевше за поетапну міграцію — зазвичай ні, коли врахувати ризик і втрачений час на релізи.
• Забуті непродуктові роботи: збірка й тулінг, CI, аналітика, SEO та паритет доступності.
• Відсутність еталонного модуля: оцінка всього застосунку до валідації на одній реальній міграції.
• Ставлення до QA як до другорядного, а не найбільшої окремої статті витрат у коді з низьким покриттям.

Швидкий чекліст оцінки

1. Проаудитуйте обсяг, фреймворк, залежності, тести й стан.
2. Оберіть стратегію міграції (поетапна за замовчуванням для живих продуктів).
3. Мігруйте один еталонний модуль і виміряйте фактичні зусилля.
4. Оцініть решту модулів відносно еталона.
5. Додайте буфери на QA, інтеграцію і стабілізацію.
6. Переоцініть після першого етапу вже з реальними даними.

Як до міграцій підходить WebMriya

Кожну модернізацію legacy ми починаємо з аудиту з фіксованим обсягом, який дає помодульну оцінку й знижений за ризиком поетапний план міграції, — тож ви отримуєте обґрунтований бюджет ще до старту повного проєкту. Якщо ви плануєте перехід з AngularJS чи jQuery на сучасний React-стек, напишіть нам — і ми допоможемо перетворити ці фактори на конкретне число.