Рефакторинг зберігає зовнішню поведінку
Рефакторинг змінює внутрішню організацію коду, але не його зовнішній контракт. Його цілі — читабельність, менше дублювання, чіткі відповідальності, простіше тестування та менша звʼязаність.
Якщо змінюється результат для клієнта, це вже bugfix, feature, migration або інший тип роботи. Не маскуйте таку зміну під structural cleanup.
| Спостережувана поведінка | Приклади |
|---|---|
| API | HTTP-статус, JSON, headers і публічні сигнатури |
| Повідомлення | Коди та тексти помилок |
| Стан | Записи в БД, події, листи й webhooks |
| Порядок | Послідовність бізнес-перевірок і side effects |
Інваріанти — що має залишитися незмінним
- ті самі релевантні входи й вихідні дані;
- ті самі винятки та повідомлення;
- незмінний порядок перевірок, якщо він впливає на результат;
- ті самі записи, події та побічні ефекти;
- відсутність змін у public API.
Безпечні кандидати й небезпечні підміни
| Може бути рефакторингом | Не є чистим рефакторингом |
|---|---|
| Винести validation у private helper | Виправити неправильний результат |
| Перейменувати private method | Додати новий user scenario |
| Спрощення умов без зміни логіки | Оновити framework або залежності |
| Прибрати дублювання | Переписати весь модуль або змінити API |
Попросіть Claude спочатку про аналіз
- Знайдіть виклики, тести, залежності та межі модуля.
- Попросіть Claude назвати локальні structural candidates.
- Для кожного кандидата вимагайте користь, ризик і affected files.
- Оберіть одну структурну проблему.
- Зафіксуйте goal, non-goals та invariants.
- Лише потім доручайте один малий крок.
Правило одного рефакторинг-PR
Один PR має вирішувати одну структурну проблему. Його опис повинен пояснювати, що змінилося, чого навмисно не змінювали та як перевіряється збереження поведінки.
Якщо мету не можна сформулювати без додавання «і ще», зміни, найімовірніше, потрібно розділити.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush