Переписывать проект или нет: как принять решение без ошибок

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

Сначала выясните, что именно стало дорого

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

• Срок изменения. Сколько времени проходит от постановки задачи до работающего изменения? Отделите собственно разработку от ожидания согласований и внешних команд.
• Повторные дефекты. Возникают ли похожие сбои после изменений в одних и тех же компонентах? Уточните, связаны ли они с архитектурой или с отсутствием тестов и наблюдаемости.
• Операционный риск. Какие операции требуют ручного вмешательства, а восстановление после сбоя не проверяли на практике?
• Ограничения продукта. Какие нужные функции невозможно добавить без смены архитектуры, а какие просто ещё не спроектировали?

Сравнивайте не впечатления, а примеры. Например: «изменение расчёта заказа затрагивает три компонента, занимает две недели и дважды приводило к регрессии» — полезнее, чем «старый сервис невозможно поддерживать». Такой список показывает, нужно ли менять систему целиком или достаточно устранить конкретные узкие места.

Новый код не отменяет старые требования. Он только переносит их в место, где команда пока ещё не успела накопить собственные обходные пути.

Три варианта вместо одного большого решения

Полный rewrite — не единственный способ выйти из тупика. Часто разумнее оставить стабильную основу и постепенно заменить самые дорогие в изменении части. Сравнивайте варианты по сроку до первой пользы, объёму параллельной поддержки и сложности безопасного переключения.

Технический долг¹ — это будущие затраты, которые возникают из-за компромиссов в реализации. Сам по себе долг не доказывает, что систему нужно переписать: иногда его дешевле погашать именно там, где он мешает продукту.

Как принять решение и не спорить о вкусах

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

1. Сформулируйте измеримую цель. Не «сделать современно», а, например, сократить время изменения конкретного сценария или убрать ручную операцию. Зафиксируйте, как измерите результат.
2. Выберите самый болезненный участок. Проследите путь одной важной операции от интерфейса до хранения данных. Отметьте зависимости и владельцев компонентов.
3. Проверьте гипотезу на ограниченном изменении. Улучшите участок без полной замены и оцените, снизились ли стоимость изменения и риск регрессии. Если это невозможно, выясните конкретную техническую причину.
4. Сравните три оценки. Посчитайте рефакторинг, поэтапную замену и полный rewrite с одинаковыми требованиями к проверкам, переносу данных и готовности к эксплуатации.
5. Назначьте условие остановки. Заранее решите, при каких результатах команда продолжит, изменит план или вернётся к старому решению. Без этого эксперимент легко превращается в rewrite без конца.

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

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

Рефакторинг, если причина локальна

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

Поэтапную замену, если границы можно провести

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

Полный rewrite, если старое основание мешает самому продукту

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

Что ломается первым

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

Замеры полезны только с условиями. Фиксируйте сценарий, объём и форму тестовых данных, профиль нагрузки, конфигурацию среды и критерий успеха. Не сравнивайте скорость старого и нового проекта на разных наборах данных или после разной степени прогрева: число без контекста не помогает выбрать подход.

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

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

При постепенной замене полезно изучить паттерн Strangler Fig: он описывает перенос функций по мере готовности новой реализации, а не одномоментное отключение старой.