Переписывать устаревшую систему или модернизировать поэтапно

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

В какой-то момент появляется закономерная идея: проще всё переписать заново.

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

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

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

Старая система не обязательно плохая

Возраст сам по себе мало говорит о качестве системы. Проект может работать десять лет, использовать не самые новые технологии и при этом стабильно решать задачи бизнеса. Если его можно поддерживать, развивать и безопасно обновлять, переписывать его только ради современного технологического стека вряд ли рационально.

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

Например:

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

Это уже предмет для анализа.

Сначала нужно понять состояние существующей системы

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

Обычно приходится смотреть на несколько уровней:

• архитектуру;
• кодовую базу;
• используемые технологии и версии;
• базу данных;
• интеграции;
• инфраструктуру;
• производительность;
• безопасность;
• автоматические тесты;
• процесс развёртывания;
• мониторинг;
• документацию.

Одновременно нужно изучить бизнес-процессы. Часть ограничений может находиться вообще не в программном коде. Например, новый личный кабинет работает медленно не из-за старого сайта, а потому что для каждого действия синхронно запрашивает данные из устаревшей ERP. Переписывание интерфейса эту проблему не решит.

Важно разделить локальный и системный технический долг

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

В другом ограничения могут пронизывать весь проект: бизнес-логика смешана с интерфейсом, компоненты сильно связаны друг с другом, нет понятных границ модулей, автоматические тесты практически отсутствуют, а изменение одного процесса регулярно ломает другой.

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

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

Полный rewrite кажется проще, чем он есть

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

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

• особый расчёт цены для определённого типа клиента;
• исключение для конкретного склада;
• дополнительная проверка перед изменением статуса;
• нестандартная обработка возврата;
• исторический формат обмена с партнёром.

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

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

Нельзя просто остановить старую систему на время разработки

Если система критична для бизнеса, она продолжает работать, пока создаётся новая. За это время в старом проекте появляются новые данные, пользователи продолжают выполнять операции, меняются законодательные или бизнес-требования, могут потребоваться срочные доработки.

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

Миграция данных — отдельный проект внутри проекта

Новое приложение без исторических данных редко можно просто включить вместо старого. Нужно перенести клиентов, товары, заказы, документы, настройки, права пользователей и другие сущности. При этом структуры данных в новой системе обычно уже отличаются.

Возникают вопросы:

• какие исторические данные переносить;
• что можно оставить в архиве;
• как сопоставить старые и новые сущности;
• что делать с некорректными и дублирующимися данными;
• как проверить полноту переноса;
• как синхронизировать изменения в период перехода.

Чем дольше существует система и чем больше данных она накопила, тем значимее эта часть работы. Поэтому оценивать rewrite только по объёму новой разработки нельзя.

Поэтапная модернизация снижает размер одного изменения

Альтернативный подход — не заменять систему целиком, а выделять отдельные части и обновлять их последовательно. Например, сначала вынести поиск в отдельный сервис. Затем заменить механизм интеграции с ERP. После этого модернизировать каталог, личный кабинет или административную часть.

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

Но поэтапно заменить можно не любую систему

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

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

Иногда сначала приходится создать границы

Даже монолит не обязательно переписывать целиком. Первым этапом модернизации может стать не новая пользовательская функция, а выделение понятных интерфейсов вокруг проблемной области.

Например, прямые обращения разных частей системы к базе данных заменяются единым сервисным слоем. После этого конкретный модуль можно постепенно заменить, сохранив контракт для остальных компонентов. Такой подход требует дополнительной работы, но позволяет уменьшить объём одновременных изменений.

По сути, система сначала становится пригодной для постепенной замены, а уже затем начинается сама замена.

Полезно выбирать границы по бизнес-возможностям

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

Иногда разумнее выделять законченные бизнес-области:

• управление каталогом;
• поиск;
• оформление заказа;
• личный кабинет;
• документы;
• работа с партнёрами.

Тогда новый компонент можно провести через весь необходимый технологический стек и запустить как законченную часть процесса. Так проще измерить результат и постепенно переключать реальную нагрузку.

Нужна стратегия сосуществования старого и нового

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

Поэтому для каждого этапа важно определить:

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

Иначе временная архитектура рискует стать постоянной.

Переписывание не должно превращаться в копирование старой системы

Если выбран полный rewrite, возникает ещё одна крайность — попытка воспроизвести старый продукт экран в экран и функцию в функцию.

За годы часть возможностей могла перестать использоваться. Некоторые процессы появились как обход старых ограничений. Какие-то функции можно упростить благодаря новым интеграциям или изменившейся организации работы. Поэтому перед переписыванием стоит провести предпроектное обследование и заново проверить требования.

Новая система должна сохранять необходимое бизнес-поведение, но не обязана наследовать каждое историческое решение. Иначе компания получит старую систему на новом технологическом стеке — вместе с большей частью прежней сложности.

Сравнивать нужно полную стоимость вариантов

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

Для полного переписывания стоит учитывать:

• обследование и восстановление требований;
• разработку;
• интеграции;
• миграцию данных;
• тестирование;
• параллельную поддержку старой системы;
• обучение пользователей;
• переключение;
• период стабилизации после запуска.

Для модернизации:

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

Сравнивать имеет смысл не стоимость ближайших трёх месяцев, а стоимость достижения нужного целевого состояния.

Риск остановки бизнеса тоже имеет цену

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

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

Когда аргументы склоняются в сторону полного переписывания

Rewrite стоит серьёзно рассматривать, если несколько фундаментальных ограничений совпадают одновременно.

Например:

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

Но даже в этом случае переход не обязательно должен происходить одним большим релизом. Новую систему тоже можно вводить по частям.

Когда логичнее модернизировать постепенно

Поэтапный сценарий особенно привлекателен, если ядро системы остаётся работоспособным, а ограничения сосредоточены в конкретных областях.

Дополнительные аргументы:

• система критична и длительная остановка недопустима;
• бизнесу нужны улучшения уже в ближайшие месяцы;
• отдельные модули можно изолировать;
• накоплено много работающей бизнес-логики;
• полный перенос данных и функций слишком рискован;
• требования продолжают активно меняться.

В этом случае модернизация позволяет направлять инвестиции сначала туда, где ограничения действительно мешают бизнесу.

Решение можно представить как несколько вопросов

Вопрос	Что помогает понять
Проблемы локальны или распределены по всей системе?	Можно ли менять компоненты отдельно
Поддерживается ли текущая технологическая база?	Насколько срочно требуется замена
Можно ли безопасно выпускать изменения?	Жизнеспособен ли дальнейший рефакторинг
Насколько связаны компоненты?	Реалистична ли поэтапная модернизация
Сколько полезной бизнес-логики накоплено?	Какова скрытая стоимость rewrite
Насколько изменились требования бизнеса?	Стоит ли воспроизводить существующую систему
Какой объём данных нужно перенести?	Сложность миграции
Может ли бизнес ждать большого релиза?	Насколько важен постепенный эффект
Каковы последствия неудачного переключения?	Требования к стратегии миграции
Как выглядит целевая архитектура?	Есть ли понятное направление модернизации

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

Начинать стоит не с выбора между двумя крайностями

На практике решение редко сводится к чистому «оставляем всё» или «выбрасываем всё».

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

Устаревшая технология сама по себе не является достаточным основанием для полного rewrite. Как и страх большого проекта не должен заставлять бесконечно ремонтировать архитектуру, которая уже объективно мешает развитию.

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