Почему мы не советуем переписывать legacy с нуля

Big Bang — самый дорогой способ провалить проект

«Давайте просто перепишем всё с нуля. Чистый код, современный стек, никакого legacy-болота».

Звучит заманчиво. Мы слышим это от клиентов регулярно. Обычно после того, как очередной разработчик сказал, что «проще переписать, чем разобраться».

Big Bang подход (переписывание всей системы целиком) имеет три фатальные проблемы:

1. Бизнес не может ждать

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

2. Вы теряете бизнес-логику

Legacy-код — это не просто «плохой код». Это 5-10 лет накопленных бизнес-правил, edge case'ов и налоговых нюансов. Даже если код выглядит ужасно, он работает правильно в 99% случаев. Переписывая с нуля, вы гарантированно воспроизведёте только 70% логики. Остальные 30% всплывут в продакшене после релиза.

3. Мотивация команды падает

Big Bang — это марафон без промежуточных финишей. Первые 3 месяца всё отлично. Потом начинается «а когда уже готово?». К 6-му месяцу команда выгорает. К 12-му — половина увольняется.

> Реальный пример: Проект переписывания CRM для дистрибьютора. Запланировали 8 месяцев. Сдали за 22 месяца. Бюджет вырос в 3 раза. Первые полгода после запуска чинили баги упущенной бизнес-логики.

Strangler Fig Pattern — модульная замена

В AKDEV мы используем подход, который в индустрии называется Strangler Fig (фикус-удушитель). В природе фикус начинает расти вокруг дерева, постепенно оплетая его, пока дерево не засыхает. С legacy — то же самое.

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

Как это выглядит на практике

Ставим прокси-слой (API gateway / reverse proxy) перед legacy

2. Выбираем один модуль — самый критичный или самый простой

3. Пишем его заново рядом с legacy

4. Перенаправляем трафик на новый модуль через прокси

5. Убеждаемся, что работает

6. Повторяем для следующего модуля

Через N итераций вся система обновлена. Ни одного дня простоя. Ни одной потерянной транзакции.

Почему это работает

• Бизнес не останавливается — каждый модуль заменяется независимо

• Риски минимальны — если новый модуль работает некорректно, прокси возвращает трафик на старый

• Команда видит прогресс — каждые 2-4 недели готовый результат

• Бюджет управляем — можно остановиться в любой момент, система уже работает

• Бизнес-логика сохраняется — старый модуль — это живая документация того, как должно работать

Пример из практики: модульная замена legacy

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

Разбили систему на 4 модуля и заменяли по одному.

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

• Один из модулей пришлось оставить в старом исполнении дольше запланированного — внешний сервис, с которым он интегрировался, менял API, и переписывать пришлось дважды за полгода.

• После подключения складского учёта остатки разошлись в первую же неделю. Оказалось, в старой системе был ночной пересчёт себестоимости, про который все забыли.

Система заменена за 6 месяцев. Без полной остановки бизнеса. Без потери данных. Но с компромиссами: один модуль так и остался в гибридном режиме (старый + новый), синхронизация требует поддержки, а бухгалтерия пару раз проклинала нас за расходящиеся остатки — пока не починили.

Модульный подход не сделал проект идеальным. Он сделал его управляемым. Мы могли фиксить проблемы по одной, а не разгребать последствия единого релиза.

> Главный урок: Замена legacy — это не спринт, а серия компромиссов. Модульный подход не обещает, что будет легко. Он обещает, что будет контролируемо. Для бизнеса это важнее.

Дорожная карта модульной замены

Фаза 1: Аудит (1-2 недели)

• Картируем все модули current system

• Определяем зависимости между модулями

• Выбираем первый кандидат на замену (независимый, критичный, или наоборот — самый простой)

• Настраиваем прокси-слой

Фаза 2: Первый модуль (2-4 недели)

• Пишем новый модуль с теми же API-контрактами

• Тестируем в изоляции

• Перенаправляем трафик через прокси

• Наблюдаем неделю

Фаза 3: Каскад (2-4 месяца, параллельно)

• Заменяем остальные модули

• Каждый модуль — отдельный цикл: разработка → тест → переключение → наблюдение

Фаза 4: Завершение

• Убираем legacy-инфраструктуру

• Документируем новую архитектуру

• Передаём команде заказчика

Когда Big Bang всё-таки оправдан?

Мы честны: есть ситуации, когда Big Bang работает лучше:

Система меньше 20 000 строк кода — проще переписать, чем выстраивать прокси

2. Нет работающей legacy — например, проектная документация или прототип

3. Полная смена бизнес-процессов — если новый продукт настолько отличается от старого, что поэтапная миграция не имеет смысла

Но в 90% случаев модульная замена выигрывает.

Заключение

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

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

В AKDEV мы прошли этот путь с десятком проектов. Если у вас есть legacy-система, которая «просит переписывания» — не спешите. Начните с аудита и одного модуля.