Modernization починається з safety baseline
Модернізація legacy-модуля не починається з переписування. Спочатку потрібно зафіксувати, як модуль поводиться сьогодні: які має входи, observable outputs, side effects, інтеграції та failure paths. Baseline захищає від непомітної зміни контракту під виглядом технічного покращення.
Baseline — це не твердження, що поточна поведінка правильна. Це зафіксована точка порівняння, яку можна переглянути після кожного малого кроку і окремо зіставити з business expectations.
Що входить до baseline
| Шар | Що зафіксувати | Evidence anchor |
|---|---|---|
| Contract | публічні входи, outputs, помилки та повідомлення | API, public methods, integration contract |
| State | зміни стану, записи, events і timestamps | tests, persistence code, logs |
| Dependencies | зовнішні clients, configuration і feature flags | imports, config, environment, callers |
| Checks | існуючі тести, build, static checks і manual scenarios | command + фактичний результат |
| Recovery | rollback point, stop condition і owner рішення | Git baseline, runbook, review decision |
Інваріанти та characterization candidate
- зовнішній API та формат результату не змінюються без окремого scope decision;
- коди помилок, повідомлення та важливі side effects залишаються узгодженими;
- порядок операцій зберігається, якщо він впливає на гроші, дані або retry behavior;
- кожен candidate для characterization має конкретний input, observable output і evidence anchor;
- невідома поведінка позначається як unknown, а не заповнюється припущенням.
Послідовність підготовки
- Визначте один модуль або business flow, який входить у modernization slice.
- Прочитайте current-state карту, tests, configuration, callers і зовнішні boundaries.
- Опишіть inputs, outputs, side effects, failure path та invariants.
- Запустіть доступні focused checks або позначте їх як unknown, якщо запуск неможливий.
- Збережіть baseline та rollback point.
- Попросіть reviewer перевірити, чи baseline описує фактичну поведінку, а не бажану архітектуру.
Коли не можна переходити до змін
Не переходьте до refactoring, якщо scope охоплює кілька незвʼязаних потоків, немає способу спостерігати результат або невідомо, хто приймає business decision. Відсутність safety net — причина спочатку збирати evidence, а не причина збільшувати patch.
Rollback має бути практичною дією: зрозумілий checkpoint, обмежений diff і перевірка, що повернення не залишає частково переміщеного стану.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush