Roadmap модернізації — це послідовність risk gates
Roadmap потрібен не для обіцянки повністю переписати legacy, а для керування невизначеністю. Кожен milestone має конкретний fragment, owner, evidence, exit criteria і рішення: proceed, narrow, hold або rollback.
Порядок етапів визначається не красою архітектури, а поєднанням business criticality, change risk, залежностей і здатності спостерігати результат.
Структура milestone
| Поле | Зміст |
|---|---|
| Target fragment | один flow, boundary або модуль |
| Reason | який risk або operational pain зменшується |
| Owner | хто підтверджує behavior і приймає decision |
| Dependencies | seams, data, flags, teams або checks |
| Evidence gate | що має бути перевірено до переходу |
| Exit criteria | коли slice завершений або готовий до наступного |
| Rollback/hold | що робити при regression або недостатньому evidence |
Приклад порядку без вигаданих результатів
- Discovery: підтвердити current behavior, module boundaries і critical flows.
- Baseline: зафіксувати observable contract, invariants і available checks.
- Seam: обрати одну перевірювану точку розділення та описати dependency direction.
- Slice: виконати один incremental refactoring або strangler fragment.
- Gate: порівняти behavior, side effects, checks і risk map.
- Expand або hold: прийняти рішення на основі evidence, а не календарного плану.
- Retire: прибрати legacy fragment лише після окремих exit criteria та rollback window.
Анти-патерни modernization roadmap
- Big-bang rewrite із датою завершення, але без проміжних evidence gates;
- roadmap як список усіх бажаних refactors без business priority;
- один milestone одночасно змінює architecture, dependencies і behavior;
- owner вказаний формально, але не має повноважень підтвердити контракт;
- успіх вимірюється кількістю переміщених рядків, а не зменшенням risk;
- legacy removal заплановано до того, як доведено coverage нового path і rollback.
Roadmap review перед наступним кроком
Перед переходом до наступного milestone перевірте, що попередній результат можна пояснити через конкретні докази: які inputs пройшли, які outputs спостерігалися, що змінилося в risk map і які unknowns залишилися. Якщо відповідь залежить від припущення, milestone не готовий до розширення.
У modernization roadmap нормально мати hold або deferred work. Відкладений fragment із чіткою причиною безпечніший за видалення legacy-коду без достатнього контролю.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush