Рефакторинг в проекте: 9 ошибок, которые дорого обходятся

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

Что считать рефакторингом, а что уже переписыванием

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

Граница важна не ради терминологии. При рефакторинге тесты проверяют, что система осталась прежней. При изменении поведения тесты должны описывать новый контракт. Если смешать оба типа работы в одном pull request, невозможно понять, что вызвало поломку и какой коммит откатывать.

Без зафиксированного поведения рефакторинг превращается в спор о вкусе: один разработчик видит улучшение, а пользователь — исчезнувшую функцию.

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

Девять типичных ошибок

1. Начинать с переписывания большого модуля

Фраза «этот сервис пора переписать» обычно означает, что границы работы не определены. В результате меняются структура каталогов, зависимости, SQL-запросы и обработка ошибок одновременно. Проверить такой набор изменений целиком трудно, а откат одного участка тянет за собой остальные.

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

2. Не снять поведенческий снимок до изменений

Набор существующих тестов не всегда описывает реальную систему. Контракт может быть зашит в интеграции, очереди, выгрузке CSV или в клиенте, который отправляет неожиданные значения. Если тестов мало, сначала соберите минимальный набор наблюдений:

• какие запросы и команды запускают сценарий;
• какие статусы, поля ответа и сообщения об ошибках получает клиент;
• какие записи появляются в базе и какие события уходят во внешние системы;
• сколько времени и ресурсов занимает операция на обычных данных.

Это не повод замораживать систему навсегда. Такой снимок нужен только для выбранной области, иначе команда будет исправлять то, что раньше считалось ошибкой, хотя это мог быть частью контракта.

3. Смешать рефакторинг с новой функциональностью

Изменение названий классов, переход на новый способ расчёта скидки и добавление поля в API в одном pull request выглядят как одна задача только в трекере. Для ревью это три разных риска.

Разделяйте работу минимум на два этапа: сначала сохранение поведения, затем изменение поведения. Если разделить нельзя, прямо отметьте в описании pull request, какие проверки относятся к структурным изменениям, а какие — к новой логике.

4. Проверять только модульные тесты

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

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

5. Делать абстракцию заранее

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

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

6. Ориентироваться на размер кода, а не на риск

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

Перед работой выберите показатель: число зависимостей модуля, время тестов, количество повторяющихся веток, частоту дефектов или сложность ревью. После изменения сравните тот же показатель, иначе успех останется субъективным.

7. Игнорировать скрытые контракты

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

Перед удалением или переименованием найдите использования в репозитории и проверьте конфигурации, схемы сообщений, миграции и документацию интеграций. Для внешнего API сначала добавьте новый вариант, затем переведите клиентов и только после этого удаляйте старый.

8. Проводить структурные изменения вместе с миграцией базы

Изменение кода и схемы базы в одном необратимом шаге опасно для систем с несколькими экземплярами приложения. Старый экземпляр может ещё отправлять запросы к прежнему столбцу, пока новый уже ожидает другой.

Для таких случаев используйте совместимые этапы: добавить новую структуру, научить код писать или читать оба варианта, перенести данные, переключить чтение и удалить старое только после проверки. Конкретная стратегия зависит от СУБД и способа деплоя; миграции нужно проверять на копии производственного объёма данных.

9. Оставить изменения без безопасного отката

Откат — это не только команда Git. Если релиз отправил сообщения нового формата, изменил данные или запустил миграцию, возврат старого кода может не восстановить работоспособность.

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

Как выбрать безопасный способ работы

У рефакторинга нет единственного правильного масштаба. Выбор зависит от того, есть ли тесты, сколько потребителей у модуля и можно ли быстро вернуть предыдущую версию.

Когда что выбирать

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

Что ломается на практике

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

В ревью полезны конкретные формулировки:

• «Какой тест доказывает, что код ошибки для этого входа не изменился?»
• «Что произойдёт, если старый экземпляр приложения обработает запись после миграции?»
• «Какая система использует это поле кроме текущего модуля?»
• «Какой показатель должен улучшиться и где его сравнивать после релиза?»
• «Можно ли откатить код, не откатывая уже изменённые данные?»

Если ответа нет, изменение ещё не готово к слиянию. Формулировка «проверим на проде» не заменяет тест, метрику или план возврата.

Что сделать дальше

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

Для терминологии и базовых приёмов сверяйтесь с каталогом Refactoring. Правила работы с ветками и коммитами проверяйте по документации версии Git, установленной в проекте: в этой статье не используются команды, зависящие от конкретного флага.