Модернизация legacy-приложений без остановки бизнеса

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

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

Почему legacy со временем становится обузой

«Legacy» — это не просто «старое». Это код, который всё труднее и дороже безопасно менять. Сигналы появляются постепенно:

• Стоимость изменений растёт: правка, занимавшая день, теперь требует двух недель и бесконечного ручного тестирования.
• Накапливаются риски безопасности: фреймворки и библиотеки без обновлений становятся точкой входа для атак.
• Тяжело нанимать: мало кто хочет работать с мёртвыми технологиями, а знающие систему люди превращаются в единую точку отказа.
• Интеграция с новыми инструментами (платежи, AI, облачные сервисы) блокируется архитектурой, не рассчитанной на это.

Ловушка переписывания «big-bang»

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

Strangler-fig: замена по кусочкам

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

Чтобы выбрать, что модернизировать первым, ищите модули на пересечении высокой ценности для бизнеса и высокой боли в поддержке. Простое упражнение по расстановке приоритетов:

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

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

Берегите данные и вовлекайте команду

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

Когда полное переписывание всё же оправдано

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

Вывод

Модернизация legacy не обязана быть прыжком в неизвестность. С паттерном strangler-fig, ясными приоритетами и бережным отношением к данным вы приведёте систему в настоящее, не остановив бизнес ни на день. Если у вас есть приложение, «которого больше никто не трогает», напишите нам — вместе проведём быструю оценку и покажем, с чего начать с наименьшим риском и наибольшей отдачей.