# 10 ошибок рефакторинга / Habr

TL;DR: Рефакторинг -это не просто механическая уборка, это скорее хирургия. Можно сделать всё правильно технически и всё равно потерять ветку при мёрже через три месяца. Эти 10 ошибок собраны из реальных проектов - от стартапов до энтерпрайза.

Ошибка	Цена
Смешать рефакторинг с улучшениями	Непредсказуемый diff, споры на ревью
Один огромный коммит	Откатиться невозможно, найти причину - лотерея
Без промежуточных проверок	«Прилетело» с другого конца системы
Долго не релизить	Ветка умерла в мёрж-конфликтах
Нет запасного варианта	Инцидент в продакшене без пути назад
Рефакторить без понимания зачем	Красивый код, сломанная логика
Игнорировать покрытие тестами	Рефакторинг вслепую
Не договориться с командой	Параллельные изменения, конфликты, обиды
Рефакторить всё сразу	Слона надо есть по частям
Не зафиксировать результат	Через полгода - снова хаос

Что вы узнаете:

Почему смешивание рефакторинга с улучшениями убивает ревью
Как коммит-стратегия спасает от потери недель работы
Чем опасно «вдохновение» без промежуточных проверок
Почему долгий рефакторинг умирает сам по себе
Как feature-флаг спасает от инцидента в продакшене
Что происходит, когда рефакторят код, который не понимают
Почему рефакторинг без тестов - это рулетка
Как несогласованный рефакторинг разрушает команду
Как есть слона по частям и не подавиться
Почему без фиксации результата всё повторится

В своем канале в Telegram и в канале Max о разработке в стартапах рассказываю ещё больше интересного и делюсь опытом, заходите, найдете полезные кейсы!

1. Добавлять в рефакторинг улучшения

Вот классическая сцена: задача «переименовать методы и вынести дублирование». Через два часа в PR уже лежит: переименование, вынос дублирования, новый вспомогательный класс, чуть оптимизированный запрос и «заодно поправил вот это». Diff на 800 строк.

Ревьюер смотрит в экран и не понимает - что тут рефакторинг, а что изменение поведения. Тест упал. Из-за чего - непонятно.

Правило железное: рефакторинг - это преобразование кода из одной формы в другую с полным сохранением поведения. Никаких улучшений, оптимизаций, «заодно поправлю», «тут же рядом». Это отдельный коммит, отдельный PR, отдельный разговор.

// ❌ Рефакторинг + улучшение в одном коммите
- def getUser(id: Int): User = db.findById(id)
+ def findUser(id: UserId): Option[User] = cache.getOrLoad(id)  // переименование + кэш + тип

// ✅ Сначала рефакторинг
- def getUser(id: Int): User = db.findById(id)
+ def findUser(id: Int): User = db.findById(id)  // только переименование

// Потом - отдельным PR - улучшение
- def findUser(id: Int): User = db.findById(id)
+ def findUser(id: UserId): Option[User] = cache.getOrLoad(id)

Ключевой инсайт: Если в рефакторинг-PR упал тест - причину найти легко. Если в нём смешаны ещё три изменения - удачи на ревью.

2. Делать один огромный коммит

Рефакторинг - это как ходьба по заминированному лабиринту. Нужно записывать каждый ход. Потому что иногда придётся вернуться - на шаг, на три, на десять.

Один коммит на весь рефакторинг - это нет ни карты, ни точек возврата. Нашли проблему на середине пути - откатывать всё. Потеряли контекст через неделю - читать портянку из 40 файлов.

Стратегия коммитов для рефакторинга:

git commit -m "refactor: rename UserService methods to match domain language"
git commit -m "refactor: extract PaymentValidator from OrderService"
git commit -m "refactor: move DTO conversion to dedicated mapper"
git commit -m "refactor: inline dead code in ReportBuilder"

Каждый коммит - один логический шаг. Каждый должен оставлять систему в рабочем состоянии. Тогда git bisect находит сломанное место за минуты, а не часы.

Ключевой инсайт: Рефакторинг с мелкими коммитами - это страховка. Вы всегда знаете, где были пять минут назад.

3. Рефакторить без промежуточных проверок

Вдохновение - страшная сила. Особенно когда код наконец начинает складываться красиво. «Вот тут вынесу, вот тут переименую, вот тут схлопну три класса в один» - и через час смотришь на 15 красных тестов и не понимаешь, где именно свернул не туда.

Рефакторинг нужно делить на логические этапы с проверками между ними:

Этап 1: переименование → компиляция ✅ → коммит
Этап 2: вынос метода → компиляция + unit-тесты ✅ → коммит  
Этап 3: изменение структуры → полный прогон тестов ✅ → коммит
Этап 4: крупное изменение → регрессионное тестирование ✅ → коммит → релиз

«Дешёвые» проверки - компиляция, unit-тесты - запускать как можно чаще. Регрессию - между крупными этапами. И лучший финал любого этапа рефакторинга - поэтапный релиз в продакшен: никакие синтетические тесты не заменят живой трафик.

Ключевой инсайт: Чем длиннее цикл проверки, тем дороже ошибка. Компиляция стоит секунды. Инцидент в продакшене - часы и нервы.

4. Затягивать и долго не релизить рефакторинг

Топ способов потерять рефакторинг — это желание довести его до идеала. Исправить всё. Привести в абсолютную симметрию. «Ещё чуть-чуть — и будет идеально».

Пока ветка с рефакторингом лежит, продуктовые спринты идут. Каждый день мёрж-конфликтов становится больше. Через месяц ветка начинает пахнуть. Через три — её выбрасывают.

На практике это работает так: каждый день задержки — это дополнительный overhead на синхронизацию с основной веткой. При активной команде рефакторинг длиной более 2-3 недель в отдельной ветке — это высокий риск потери всей работы.

Что делать:

Делить большой рефакторинг на независимые части, каждую из которых можно зарелизить отдельно
Устанавливать дедлайн релиза в самом начале
Лучше зарелизить 70% рефакторинга, чем не зарелизить 100%

// Не пытаемся переписать всё сразу
// Шаг 1: рефакторим публичный API модуля → релиз
// Шаг 2: рефакторим внутреннюю реализацию → релиз  
// Шаг 3: рефакторим зависимые модули → релиз

Ключевой инсайт: Идеальный рефакторинг, который не вышел в продакшен — это ноль. Хороший рефакторинг, который вышел — это единица.

5. Не думать о запасном варианте

Все проверки пройдены. Тесты зелёные. Код ревью одобрен. Релиз прошёл. И тут — инцидент. Что-то, что не поймали ни тесты, ни регрессия, проявилось под реальной нагрузкой или в редком сценарии, который просто не был покрыт.

Особенно больно это в самых ключевых местах системы — там, где рефакторинг был нужнее всего.

Спасение — feature-флаг с переключением на старый код, желательно без рестарта:

def processOrder(order: Order): Result =
  if featureFlags.isEnabled("use-refactored-order-processing") then
    newOrderProcessor.process(order)   // новый код
  else
    legacyOrderProcessor.process(order) // старый код как он был

Флаг позволяет:

Откатиться за секунды без деплоя
Выкатить на 1% трафика и сравнить поведение
Убрать старый код через неделю, когда убедились что всё хорошо

Ключевой инсайт: Запасной вариант — это не страх, это профессионализм. Хирург тоже готовит реанимацию до операции, а не во время.

6. Рефакторить код, который не понимаешь

Казалось бы, очевидно. Но на практике — «ну тут же явно дублирование, вынесем» — и через час выясняется, что это дублирование было намеренным: два похожих блока обрабатывают тонко разные случаи, разница — в одном условии, которое не сразу видно.

Рефакторинг без понимания контекста — это переставлять мебель в темноте. Красиво переставишь, но вазу разобьёшь.

Перед рефакторингом:

Прочитать не только код, но и тесты — они документируют намерение
Найти историю в git log -p — понять, почему код стал таким
Поговорить с автором, если он доступен
Написать тест на поведение, которое ты собираешься сохранить

# Сначала понять историю
git log -p --follow path/to/file.scala

# Потом смотреть кто и когда трогал критичный участок
git blame path/to/file.scala

Ключевой инсайт: Чем запутаннее код — тем больше в нём намеренных решений. Странный код часто странный не просто так.

7. Рефакторить без достаточного покрытия тестами

Рефакторинг без тестов — это рулетка. Ты меняешь внутреннюю структуру, не меняя поведения. Но если нет тестов, которые это поведение фиксируют — ты не узнаешь, что что-то сломалось, до продакшена.

Прежде чем рефакторить — убедись, что поведение зафиксировано тестами. Если тестов нет — сначала напиши их, потом рефактори.

// Шаг 0: написать тест на текущее поведение ПЕРЕД рефакторингом
test("calculateDiscount returns 10% for premium users") {
  val result = legacyService.calculateDiscount(premiumUser, order)
  assert(result == order.total * 0.9)
}

// Теперь рефакторим — тест покажет если что-то сломалось

Это называется «characterization test» — тест, который фиксирует текущее поведение как эталон. Не «как должно быть», а «как есть прямо сейчас».

Ключевой инсайт: Тесты перед рефакторингом — это не про TDD. Это про страховку. Написал тест, сделал рефакторинг, тест зелёный — значит поведение сохранено.

8. Не договориться с командой заранее

Рефакторинг в командной разработке — это не только технический, но и социальный процесс. Начать большой рефакторинг молча, без обсуждения — значит создать конфликты.

Сценарий: разработчик начинает рефакторинг модуля. Параллельно второй разработчик активно пилит в этом же модуле фичу. Через неделю — мёрж-ад и взаимные претензии.

Перед большим рефакторингом:

Объявить команде: «я рефакторю этот модуль, не трогайте его до такого-то числа»
Договориться о стратегии: или все ждут, или разбиваем на части чтобы не пересекаться
Зафиксировать договорённости письменно, чтобы через неделю не было «я не знал»

// Хорошая практика: завести задачу в трекере
// "Рефакторинг модуля OrderService"
// Описание: что трогаем, что не трогаем, срок, кто ответственный
// Статус виден всей команде

Ключевой инсайт: Несогласованный рефакторинг — это не только технический риск. Это риск для отношений в команде.

9. Рефакторить всё сразу

«Раз уж взялись за модуль — давайте перепишем всё». Знакомо? Это ловушка перфекционизма в промышленном масштабе.

Чем больше охват рефакторинга — тем выше риск, тем дольше ревью, тем сложнее мёрж, тем больше вероятность что ветка умрёт. Слона едят по частям.

Принцип: определи минимальный рефакторинг, который решает конкретную проблему. Остальное — в следующий раз.

// ❌ «Рефакторим весь платёжный модуль»
// Охват: 20 файлов, 3 недели, высокий риск

// ✅ «Рефакторим только логику валидации платежа»
// Охват: 3 файла, 2 дня, низкий риск → релиз
// Потом: «рефакторим логику проведения платежа»
// Охват: 4 файла, 3 дня, низкий риск → релиз

Серия маленьких успешных рефакторингов лучше одного большого провала. И каждый маленький рефакторинг — это реальное улучшение кода в продакшене, а не ветка в статусе «in progress» три месяца.

Ключевой инсайт: Рефакторинг — это не спринт, это марафон. Маленькими шагами дальше уйдёшь.

10. Не зафиксировать результат

Рефакторинг сделан. Код стал чище. Все довольны. Через полгода — тот же хаос. Откуда?

Потому что рефакторинг без фиксации принципов — это разовая уборка без системы хранения. Если не объяснить команде «почему теперь так» и «как поддерживать это состояние» — следующий разработчик воспроизведёт старые паттерны просто потому что не знает о новых.

Что фиксировать после рефакторинга:

ADR (Architecture Decision Record) — коротко: что было, что стало, почему
Обновлённые линтер-правила или архитектурные тесты, которые не дадут вернуться к старому
Краткий разбор на командном синке — «вот что поменяли, вот как теперь писать»

// Архитектурный тест как живая документация
// Если кто-то нарушит принцип — тест упадёт
test("domain layer must not depend on infrastructure") {
  val violations = ArchUnit
    .classes.that.resideInPackage("..domain..")
    .should.notDependOnClassesThat.resideInPackage("..infrastructure..")
  violations.check(importedClasses)
}

Ключевой инсайт: Рефакторинг без фиксации результата — это технический долг с отложенным сроком возврата. Через год придёшь на то же место.

Итого

Рефакторинг — не уборка. Это управляемое изменение сложной системы под нагрузкой, в движущейся команде, с ненулевым риском инцидента. Большинство провалов рефакторинга — не технические. Это организационные и процессные ошибки.

Три правила, которые спасают чаще всего:

Мелкие коммиты + промежуточные проверки — всегда знаешь где ты и можешь отступить
Релизить рано и часто — лучше 70% в продакшене, чем 100% в ветке
Запасной вариант — feature-флаг на откат без рестарта в самых рискованных местах

Удачного рефакторинга. И не забудьте каску.