Этому серверу 8 лет, и я его не трогаю. Вот почему

Один мой клиент пришёл с запросом: «Нам нужно переписать бэкенд. Он старый». Я спросил: «Что конкретно сломано?» Пауза. «Ну... он старый».

Это не технический аргумент. Это культурный рефлекс.

Мы живём в индустрии, где «переписать» стало синонимом «заняться делом». Если ты не мигрируешь, значит, прячешь голову в песок. Системе три года — она уже «легаси». Не использует последний фреймворк: умирает.

Я с этим не согласен.

Как «переписать» стало дефолтным ответом

Архитектурные решения принимаются в контексте. Через два года контекст меняется: новый тимлид, новая мода на микросервисы, новый стек у соседней команды. И старое решение начинает выглядеть неправильным не потому что оно сломалось, а потому что оно *другое*.

Переписывание проще продать. «Давайте мигрируем на Next.js» звучит как прогресс. «Давайте оставим PHP, добавим кеш и закроем три баги» звучит как капитуляция. Хотя второе решит реальную проблему, а первое создаст шесть новых.

Разработчики хотят работать с новым кодом. Это нормально. Но это мотивация разработчика, а не бизнеса.

Что на самом деле стоит миграция

Когда команда предлагает переписывание, она называет стоимость разработки. И не называет стоимость всего остального.

Во-первых, переписывание ломает знание. Каждая строка в работающей системе — это решение, принятое кем-то, кто знал контекст. Почему тут такая обработка граничного случая? Почему вот этот запрос такой странный? Когда переписываешь с нуля, ты теряешь весь этот неявный контекст. Его нет в Confluence. Его нет в README. Он в коде.

Во-вторых, появляется период неопределённости. Полгода-год новая система существует параллельно старой. Кто занимается поддержкой старой? Кто принимает баг-репорты? Как синхронизировать состояние? Это отдельный проект внутри проекта, о котором никто не думает заранее.

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

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

Три признака системы, которую не надо трогать

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

Второй: операционная стоимость предсказуема. Ты знаешь, где что сломается и как починить. Эта предсказуемость стоит денег, и её трудно посчитать, потому что она проявляется в отсутствии инцидентов.

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

Три признака системы, которую трогать нужно

Я не говорю «никогда не мигрируйте». Это была бы другая крайность.

Первый: базовые вещи перестали поддерживаться. Если PHP-версия или библиотека получают CVE и патч не выходит — это безопасность, а не архитектура. Тут выбора нет.

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

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

Три вопроса перед «давайте перепишем»

Я пользуюсь этим фреймворком каждый раз, когда слышу этот аргумент — от клиента, от коллеги, от себя.

Первый: что конкретно сломано? Не «старый», не «некрасивый», не «не на нашем стеке». А что именно не работает, с какой частотой и какой бизнес-ценой?

Второй: что произойдёт, если мы этого не сделаем? Иногда ответ: «Ничего плохого». Тогда разговор заканчивается. Иногда ответ: «Через год мы не сможем нанимать разработчиков» — и это реальный аргумент.

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

Когда я отказался от контракта на переписывание, там был ровно этот сценарий: клиент хотел переписать Bitrix, потому что разработчик сказал «он устарел». Мы зашли в логи. 40 SQL-запросов на страницу каталога. LCP 4.2 секунды. Всё это починилось без переписывания за три недели.

Честная оговорка: когда стабильность становится ловушкой

Стабильность — не самоцель. Есть момент, когда «мы это не трогаем» превращается из осознанного решения в избегание.

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

В таких случаях правильный ответ — не «переписать с нуля», а «разобрать по частям». Сначала изолировать проблемный модуль, потом заменить его, не трогая остальное. Дольше, но последствий меньше.

Owner mindset — это не «защищать старое». Это считать последствия каждого решения. Включая решение переписать.

Итог

Стабильная система — это актив. Не идеальный, не красивый, но предсказуемый. А предсказуемость — это деньги, которые ты не тратишь.

Три вопроса перед следующим «давайте перепишем» — они сами по себе часто закрывают разговор.