Старую систему чинить или переписать с нуля?

«Legacy» — это не «старый» и не «плохой» код. Legacy — это система, которую страшно менять, потому что никто до конца не понимает, как она устроена. Она может быть написана пять лет назад на современном стеке и всё равно быть legacy, если автор ушёл, документации нет, а каждое изменение — лотерея.

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

Когда новый исполнитель, едва взглянув на вашу систему, говорит «тут всё плохо, надо переписывать с нуля», — чаще всего это не про вашу систему, а про его удобство.

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

Это конфликт интересов, о котором редко говорят вслух: то, что выгодно исполнителю, не всегда выгодно заказчику. Признак честного подрядчика — он сначала проводит аудит и считает оба варианта, а не выносит вердикт «переписать» с порога.

Решение «чинить или менять» — это сравнение двух чисел, а не вопрос вкуса:

1. Аудит. Что внутри системы, где риски, есть ли исходники, насколько связаны модули.
2. Стоимость владения текущей системой. Во что обходится поддержка сейчас и как быстро эта стоимость растёт: ручные обходы, простои, дорогие точечные правки, риски безопасности.
3. Стоимость замены + риск миграции. Сколько стоит построить новое и чем рискуете при переносе данных и процессов.
4. Приоритеты. Что критично исправить сейчас, а что может подождать или вовсе не мешает.
5. Вердикт. Один из трёх: отрефакторить критичные модули, заменять поэтапно или (реже) переписать целиком.

Ключевая идея — почти никогда ответ не бывает «всё чинить» или «всё переписать». Реальное решение почти всегда гибридное: часть системы оставляют, критичное чинят, безнадёжное заменяют по частям.

Критерии, по которым выносится вердикт на аудите. Чем больше пунктов попадает в правую колонку — тем сильнее аргумент за замену:

Критерий	Скорее чинить	Скорее переписать
Исходники	есть и собираются	потеряны / не собираются
Архитектура	модульная, понятная	всё связано со всем, любое изменение ломает соседнее
Технологии	поддерживаются	сняты с поддержки, нет специалистов
Бизнес-логика	актуальна	процессы давно изменились, система им не соответствует
Данные	целостные	хаос, дубли, нельзя доверять
Стоимость поддержки	предсказуема	растёт быстрее пользы
Безопасность	управляема	критичные дыры, закрыть нельзя без переписывания

Как читать таблицу. Редко всё однозначно. Чаще вывод — «отрефакторить критичные модули, остальное оставить» или «переписывать поэтапно, не всё сразу». Полную замену оправдывает только перевес в правой колонке по нескольким ключевым строкам сразу — особенно если исходники потеряны, а архитектура не поддаётся изменению.

Главный критерий — архитектура (разбор)

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

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

Что обычно недооценивают

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

Главный страх владельца — «пока вы возитесь, бизнес встанет». Этого не должно происходить. Правильная модернизация идёт поэтапно: старая система продолжает работать, а новое подключается по частям и сверяется с действующим. Данные переносятся постепенно, с проверкой на каждом шаге. К моменту, когда старое выключают, новое уже доказало, что работает на тех же данных. Это дольше, чем «переписать в вакууме», но именно так бизнес не теряет ни дня.

Частый и не безнадёжный случай. Даже без полных исходников можно восстановить картину: проанализировать работающую систему, базу данных, поведение, оставшиеся фрагменты кода. На аудите мы оцениваем, что реально восстановить и собрать, а что придётся замещать. Потеря исходников — сильный аргумент в сторону замены, но не автоматический приговор: иногда дешевле обернуть старое в новый интерфейс, чем переписывать с нуля.

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

• Вы всегда советуете переписать с нуля? Нет. Сначала аудит, потом честный вердикт по каждому модулю. Чаще доработка выгоднее замены — так и скажем.
• Исходники потеряны — что делать? Восстанавливаем картину по работающей системе, базе и фрагментам кода; что реально собрать, оцениваем на аудите.
• Можно ли модернизировать без остановки бизнеса? Да — поэтапно, параллельно со старой системой, с проверкой на каждом шаге.
• С чего начать? С аудита: он и есть честный ответ на вопрос «чинить или менять», с цифрами вместо эмоций.
• Сколько это стоит? Цена считается индивидуально; аудит даёт расчёт до крупных вложений. Диапазон — в калькуляторе.