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

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

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

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