Перепиши всё с нуля — на этот раз точно получится

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

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

Сравнивай старую реальность с новым замыслом

Допустим, мы переписываем систему заказов. За первую неделю получается красивый основной сценарий: товар, корзина, оплата. За вторую — аккуратная админка. Возникает ощущение, что прежняя команда годами усложняла то, что делается за десять дней.

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

Часть условий наверняка устарела. Но отличить мёртвую ветку от действующего обязательства придётся исследованием. Новый язык программирования этого знания не приносит.

Самый дорогой мусор выглядит ровно так же, как самое важное исключение.

Пообещай, что старый продукт пока трогать не будут

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

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

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

Кнопка возврата на старый интерфейс не возвращает назад изменённую модель данных.

Сотри код раньше, чем поймёшь поведение

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

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

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

Переписывание иногда действительно нужно

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

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

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

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