Систематичний рефакторинг коду на основі методології Мартіна Фаулера. Використовуйте, коли користувачі просять рефакторити код, покращити структуру коду, зменшити технічний борг, очистити застарілий код, усунути запахи коду (code smells) або покращити супровідність коду. Ця навичка проводить через поетапний підхід з дослідженням, плануванням та безпечною інкрементальною реалізацією.
Систематичний підхід до рефакторингу коду на основі книги Мартіна Фаулера Refactoring: Improving the Design of Existing Code (2-ге видання). Ця навичка наголошує на безпечних, інкрементальних змінах, підкріплених тестами.
«Рефакторинг — це процес зміни програмної системи таким чином, що не змінює зовнішню поведінку коду, але покращує його внутрішню структуру.» — Мартін Фаулер
Фаза 1: Дослідження та аналіз
↓
Фаза 2: Оцінка покриття тестами
↓
Фаза 3: Виявлення запахів коду
↓
Фаза 4: Створення плану рефакторингу
↓
Фаза 5: Інкрементальна реалізація
↓
Фаза 6: Перегляд та ітерація
Перед початком уточніть:
Представити знахідки користувачу:
«Рефакторинг без тестів — як їзда без пасків безпеки.» — Мартін Фаулер
Тести — ключовий засіб безпечного рефакторингу. Без них ви ризикуєте внести помилки.
Перевірити наявні тести
# Пошук файлів тестів
find . -name "*test*" -o -name "*spec*" | head -20
Запустити існуючі тести
# JavaScript/TypeScript
npm test
# Python
pytest -v
# Java
mvn test
Перевірити покриття (якщо доступно)
# JavaScript
npm run test:coverage
# Python
pytest --cov=.
Якщо тести існують та проходять:
Якщо тести відсутні або неповні: Представити варіанти:
Якщо тести не проходять:
Для кожної функції, що рефакториться, забезпечити тести для:
Використовуйте цикл «red-green-refactor»:
Симптоми глибших проблем у коді. Це не помилки, а індикатори того, що код можна покращити.
Див. references/code-smells.md для повного каталогу.
| Запах | Ознаки | Вплив |
|---|---|---|
| Довгий метод | Методи > 30-50 рядків | Важко зрозуміти, тестувати, супроводжувати |
| Дубльований код | Та сама логіка в кількох місцях | Виправлення помилок потрібне в кількох місцях |
| Великий клас | Клас з занадто багатьма відповідальностями | Порушує принцип єдиної відповідальності |
| Заздрість до функцій | Метод використовує дані іншого класу більше | Погана інкапсуляція |
| Одержимість примітивами | Надмірне використання примітивів замість обʼєктів | Відсутні доменні концепції |
| Довгий список параметрів | Методи з 4+ параметрами | Складно викликати правильно |
| Групи даних | Ті самі елементи даних зʼявляються разом | Відсутня абстракція |
| Оператори Switch | Складні ланцюжки switch/if-else | Важко розширювати |
| Спекулятивна загальність | Код «на всякий випадок» | Зайва складність |
| Мертвий код | Невикористаний код | Плутанина, тягар супровідності |
Автоматичний аналіз (якщо скрипти доступні)
python scripts/detect-smells.py <file>
Ручний перегляд
Пріоритезація Зосередитися на запахах, які:
Представити користувачу:
Для кожного запаху обрати відповідний рефакторинг з каталогу.
Див. references/refactoring-catalog.md для повного списку.
| Запах коду | Рекомендований рефакторинг |
|---|---|
| Long Method | Extract Method, Replace Temp with Query |
| Duplicated Code | Extract Method, Pull Up Method, Form Template Method |
| Large Class | Extract Class, Extract Subclass |
| Feature Envy | Move Method, Move Field |
| Primitive Obsession | Replace Primitive with Object, Replace Type Code with Class |
| Long Parameter List | Introduce Parameter Object, Preserve Whole Object |
| Data Clumps | Extract Class, Introduce Parameter Object |
| Switch Statements | Replace Conditional with Polymorphism |
| Speculative Generality | Collapse Hierarchy, Inline Class, Remove Dead Code |
| Dead Code | Remove Dead Code |
Використовуйте шаблон templates/refactoring-plan.md.
Для кожного рефакторингу:
КРИТИЧНО: Впроваджуйте рефакторинг поступово, фазами.
Фаза A: Швидкі перемоги (Низький ризик, висока цінність)
Фаза B: Структурні покращення (Середній ризик)
Фаза C: Архітектурні зміни (Вищий ризик)
Перед реалізацією:
«Зміна → Тест → Зелений? → Коміт → Наступний крок»
Для кожного кроку рефакторингу:
Попередня перевірка
Зробити ОДНУ малу зміну
Верифікація
Якщо тести проходять (зелені)
Якщо тести не проходять (червоні)
Кожен коміт має бути:
Приклади повідомлень комітів: