Рефакторинг, модернізація, міграція

Три різні режими роботи зі змінами

Рефакторинг змінює внутрішню структуру без навмисної зміни зовнішнього контракту. Modernization покращує або замінює частини legacy-системи, часто залишаючи бізнес-поведінку та інтеграційні межі стабільними. Migration переносить систему або її slice із source state до target state: іншої версії runtime, framework, платформи, API, формату чи середовища.

Ці режими можуть перетинатися, але не є синонімами. Під час migration можуть знадобитися refactoring або modernization, проте сам факт зміни версії чи платформи не доводить, що виконано rewrite або production rollout.

Порівняння scope і доказів

Discovery перед рішенням про міграцію

• назвіть source і target: версії, runtime, framework, build або платформу;
• зафіксуйте, який boundary справді переноситься, а що залишається поза scope;
• відокремте підтверджені факти від припущень і Unknown;
• визначте, який contract має залишитися стабільним і як його спостерігати;
• не називайте міграцією звичайне перейменування або внутрішнє переміщення без source-to-target зміни.

Коли не можна змішувати режими

Якщо під час migration discovery знайдено окрему business-вимогу, bugfix або широке очищення коду, не додавайте їх мовчки до migration scope. Винесіть роботу в окреме рішення, щоб результати compatibility analysis і behavior comparison залишалися зрозумілими.

Migration brief у цьому гайді є documented example: він демонструє спосіб мислення та поля документа, але не описує реально виконаний upgrade конкретного репозиторію.