Когда переписывать проект: чек-лист перед продакшеном

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

Сначала зафиксируйте версию проекта и цену решения

Этот материал относится к веб-сервисам и внутренним приложениям, где есть код, база данных, внешние интеграции и команда, отвечающая за релиз. Он не привязан к конкретной версии Django, Laravel, Node.js или другого фреймворка: здесь нет команд и API, которые могли бы измениться между версиями.

Перед обсуждением «переписать или нет» запишите четыре числа:

• сколько пользователей и операций должен выдержать первый продакшен-релиз;
• какая дата запуска действительно важна и что произойдёт при переносе;
• сколько инженерных недель доступно до этой даты;
• какой ущерб принесёт сбой: потерянные заказы, простой, ручная обработка, штрафы или репутационные издержки.

Без этой рамки спор превращается в конкурс вкусов. «Код плохой» не помогает принять решение. «Изменение схемы заказа требует трёх недель, а релиз через десять дней» — уже помогает.

Переписывать нужно не код, который раздражает разработчиков, а риск, который нельзя принять в продакшене.

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

Чек-лист: действительно ли нужен новый проект

1. Есть ли блокирующая причина

Отделите неудобство от угрозы релизу. Блокирующими обычно становятся не названия папок и не отсутствие модного фреймворка, а конкретные ограничения:

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

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

2. Можно ли локализовать проблему

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

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

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

3. Есть ли тестируемое поведение

Перед переписыванием зафиксируйте не внутреннюю структуру, а внешнее поведение: какие данные принимает система, что возвращает, какие побочные эффекты создаёт и что происходит при повторном запросе.

Минимальный набор для критичного сценария:

1. успешный путь;
2. невалидный ввод;
3. повтор запроса после тайм-аута;
4. недоступность внешней зависимости;
5. частично выполненная операция;
6. восстановление после перезапуска.

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

4. Есть ли измерения, а не только жалобы

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

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

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

Четыре варианта вместо бинарного выбора

Между «оставить всё» и «выбросить всё» есть несколько рабочих стратегий. Их нужно сравнивать по сроку, обратимости и риску, а не по эстетике кода.

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

Оставляйте текущий код

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

Рефакторьте часть системы

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

Заменяйте постепенно

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

Переписывайте полностью

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

Что обычно ломается

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

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

Контрольная встреча перед решением

Соберите на одну страницу следующие ответы:

1. Какая конкретная проблема заставляет обсуждать переписывание?
2. Как она воспроизводится и чем измеряется?
3. Какие внешние контракты нельзя изменить?
4. Какие данные нужно перенести и как проверить их полноту?
5. Как выглядит откат после частичного переключения?
6. Кто принимает решение о релизе и кто отвечает за инцидент?
7. Какой минимальный объём новой реализации приносит пользу?

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

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

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