Інкрементальний рефакторинг — це серія контрольованих slices
Legacy-модуль стає безпечнішим не від одного великого rewrite, а від послідовності малих змін із чіткою метою. Кожен slice має обмежений scope, non-goals, safety net, focused check і зрозумілий rollback.
Якщо під час structural refactoring виявлено bugfix, зміну бізнес-правила або новий public contract, роботу потрібно зупинити й винести це в окрему задачу.
Один slice — одна structural hypothesis
| Елемент | Приклад питання |
|---|---|
| Goal | Яку одну structural проблему усуваємо? |
| Allowed scope | Які файли, символи або boundary можна торкнутися? |
| Non-goals | Які API, залежності та business rules не змінюємо? |
| Safety net | Який observable behavior порівнюємо до і після? |
| Stop condition | Коли треба повернутися до baseline або попросити рішення? |
Цикл малого кроку
- Сформулюйте structural goal і перелік заборонених змін.
- Перевірте usages, tests, current baseline та dependency direction.
- Виконайте найменшу зміну, яка перевіряє гіпотезу.
- Запустіть focused check і порівняйте observable output.
- Прочитайте повний diff та перевірте список touched files.
- Створіть логічний checkpoint або commit лише після review.
- Оновіть modernization record фактичним результатом і відкритими ризиками.
Що не є інкрементальним refactoring
- масове перейменування разом зі зміною поведінки;
- оновлення framework або dependencies без окремого compatibility plan;
- переміщення коду через десятки модулів без safety net;
- додавання feature під час очищення legacy-класу;
- послаблення тесту, щоб приховати regression.
Prompt для контрольованого кроку
Goal: extract one internal responsibility
Allowed: <one module> and focused tests
Preserve: public API, outputs, errors, side effects
Forbidden: dependency updates, feature work, broad formatting
Check: <focused command>
Stop if: behavior or scope is unclearКанонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush