Read-then-refactor: безопасный рефакторинг

Отрефактори {{target}}. Причина: {{reason}}.

Правило №1: Рефакторинг = изменение структуры без изменения поведения. Если поведение меняется — это уже не рефакторинг, это фича/фикс. Никогда не смешивай.

Алгоритм

Фаза 1. Понять (НЕ менять)

1. Прочитай файл целиком, не сканируй
2. Прочитай вызывающие места (grep "{{target}}")
3. Прочитай тесты
4. Напиши себе на бумаге: что эта штука делает (без жаргона из самого кода)
5. Найди скрытые контракты: что неочевидно но кто-то на это полагается
6. Запиши все side effects (logging, http, файлы, db)

Фаза 2. Подготовить тесты

• Если тестов нет — напиши characterization tests: что код делает сейчас
• Эти тесты должны проходить ДО рефакторинга
• Они твоя страховка

Фаза 3. Рефакторить маленькими шагами

Каждый шаг:

1. Делаешь одно изменение
2. Прогоняешь тесты
3. Если зелёное — коммит "refactor: ..."
4. Если красное — откат

Шаблоны рефакторингов

• Extract function — длинный метод → несколько маленьких
• Inline variable — переменная использована один раз и не добавляет смысла
• Rename — имя не отражает суть
• Replace conditional with polymorphism — if/else по типу → методы
• Introduce parameter object — функция с 5+ параметрами → объект
• Remove dead code — найдено через ловление "обходов"

Фаза 4. Проверка

• Все тесты проходят
• Нет изменений в публичном API (или они документированы)
• Нет лишних изменений (см. diff)
• Lint и type check без новых ошибок

Чего НЕ делать

• ✗ Не меняй поведение в "заодно" — это другая задача
• ✗ Не рефактори то, что не трогал в этой задаче (scope creep)
• ✗ Не добавляй комментарии "что делает функция" — имена должны говорить
• ✗ Не вводи абстракцию ради абстракции — three's a pattern, two's a coincidence
• ✗ Не переделывай в "паттерн" без причины

В конце дай

• Diff сводку (что переименовано, что вынесено, что удалено)
• Что НЕ менял и почему (защита от scope creep)
• Открытые вопросы — если что-то требует отдельной задачи