Разговор начинается одинаково: «здесь всё плохо, давайте перепишем». Иногда это верно. Чаще — способ не разбираться в чужом коде. Разберём, как отличить одно от другого до того, как подписан договор.
Почему переписывание проваливается чаще
Старая система выглядит хаосом, потому что в ней десять лет накапливались исключения. Странное условие в середине функции — это чей-то давний баг-репорт. Дублирующаяся проверка — авария трёхлетней давности.
Новая система начинается чистой и собирает те же исключения заново, по одному, в проде, на живых пользователях. Через два года она выглядит так же.
Второй фактор — время. Пока пишется замена, старая система продолжает развиваться: бизнес не останавливается. Команда либо тянет два продукта, либо замораживает изменения на год, чего бизнес не переживает.
Четыре критерия, по которым считают
1. Доля кода, который придётся тронуть. Оцените, сколько файлов затрагивают запланированные на год изменения. Меньше 30% — рефакторинг. Больше 70% — переписывание становится рациональным.
2. Наличие тестов. Рефакторинг без тестов — это переписывание вслепую с надеждой. Если тестов нет, первый шаг — покрыть тестами критичные сценарии, и это отдельный проект на 40–120 часов. Отказ от него делает разговор беспредметным.
3. Живость платформы. PHP 5.6, Python 2, Angular 1 — платформы без обновлений безопасности. Здесь удобство ни при чём: вы обязаны уйти, и это переписывание независимо от качества кода.
4. Скорость внесения изменений. Замеряется просто. Возьмите последние десять задач и посмотрите, сколько заняла каждая. Если правка, которая должна занимать день, занимает неделю, и так системно — стоимость владения уже выше стоимости замены.
Третий путь, который выбирают чаще обоих
Постепенная замена по частям. Новый код пишется рядом со старым, трафик переводится по кускам, старая система отмирает по модулю за раз.
Схема такая: перед старым приложением ставится маршрутизатор. Сначала он отправляет все запросы в старое. Потом один раздел — в новое. Потом второй. Через год старого не остаётся.
Что это даёт: работающая система в любой момент времени, откат за минуту, результат виден бизнесу через месяц.
Что стоит: период, когда живут две системы и данные надо синхронизировать. Чаще всего это самая сложная часть, и планировать её надо до начала работ.
Что делать в первую очередь в любом случае
Зафиксируйте поведение. Тесты на критичные сценарии: оформление заказа, оплата, вход, выгрузка. Они понадобятся при любом сценарии и переживут любое решение.
Опишите интеграции. Что система принимает, что отдаёт, кому. Это карта рисков: сломанная интеграция обнаруживается через неделю, когда у партнёра накопится расхождение.
Соберите метрики. Время ответа, частота ошибок, нагрузка по разделам. Без них «стало лучше» останется вопросом веры.
Как считать деньги
Рефакторинг: часы на покрытие тестами плюс часы на изменения плюс регрессия после каждого этапа. Считается предсказуемо, потому что объём известен.
Переписывание: полная стоимость разработки текущей функциональности плюс изучение старой системы плюс параллельное сопровождение обеих плюс миграция данных. Последние три пункта в первоначальных оценках отсутствуют почти всегда, и они дают перерасход в полтора-два раза.
Практическое правило: если оценка переписывания не превышает оценку рефакторинга минимум вдвое, вы что-то не учли.
Короткий чек-лист
Переписывать, если: платформа без поддержки безопасности, тестов нет и код непроверяем, изменения затрагивают почти всю кодовую базу, разработчиков на этом стеке не найти.
Рефакторить, если: система работает, изменения локальны, есть люди, которые её понимают, бизнес не готов заморозить развитие на год.
В остальных случаях — постепенная замена. Она скучнее обоих вариантов и почти всегда дешевле.