Команды устают от сложной системы и закономерно начинают мечтать о чистом старте. Современный стек, понятная архитектура, никаких исторических костылей.
Проблема в том, что переписывание само по себе ничего не лечит. Иногда оно необходимо. Но иногда компания просто меняет известный набор проблем на новый и пока неизвестный.
Плохой код ещё не причина переписывать систему
Некрасивый код, старый framework или сложная структура раздражают инженеров, но этого недостаточно для большой инвестиции.
Причина становится серьёзной, когда технические ограничения системно мешают бизнесу: изменения слишком медленные, риск релиза неприемлем, нужный масштаб недостижим или дальнейшее развитие объективно блокируется.
Нужно понимать, что именно вы хотите исправить
Фраза «система стала слишком сложной» слишком общая. Какая конкретно проблема исчезнет после rewrite?
Если на этот вопрос нет измеримого ответа, через год новая система может оказаться такой же сложной — только с более свежими технологиями.
Старую логику придётся обнаружить заново
Legacy хранит не только технический долг. В нём годами накапливаются реальные правила бизнеса, исключения и обходы редких сценариев.
При переписывании команда часто узнаёт о них не из документации, а когда новая версия впервые сталкивается с реальным миром.
Big bang — самый опасный сценарий
Чем дольше новая система строится отдельно от production, тем дольше компания получает нулевую отдачу и тем больше расхождение между двумя мирами.
Если возможно, безопаснее менять систему частями: выделять границы, заменять наиболее дорогие области и постепенно сокращать старый контур.
Иногда rewrite всё-таки правильный выбор
Если архитектурные ограничения делают стратегически важное изменение практически невозможным, стоимость поддержки растёт быстрее пользы от системы, а постепенная модернизация не решает базовое ограничение, переписывание может быть рациональным.
Но это должна быть бизнес-инвестиция с понятной причиной, а не инженерная мечта о чистом коде.
Сначала посчитайте альтернативы
Перед rewrite стоит сравнить как минимум три варианта: оставить как есть, модернизировать постепенно или заменить систему целиком.
Переписывать систему стоит не тогда, когда старую неприятно поддерживать, а когда сохранение её ограничений становится дороже и рискованнее, чем управляемая замена.