Почему нельзя просто взять и переписать всё с нуля, когда пора прощаться с системой и как защитить бюджет на миграцию
Привет, Хабр!
Константин Густов, IT бизнес-партнёр MANGO OFFICE, недавно принял участие в подкасте Валерия Котелова.
В MANGO OFFICE Константин отвечает за архитектурные решения и помогает превращать бизнес-задачи в работающие продукты.
Ниже — основные выводы из разговора о legacy-системах. И практический опыт работы с ними в MANGO OFFICE.
Что такое legacy на самом деле
Legacy часто ассоциируется с чем-то устаревшим и проблемным – вроде Windows 98.
На практике это просто код, который достался в наследство от предыдущих разработчиков.
Legacy может быть даже сервис с годичной историей.
В MANGO OFFICE также есть код с большой историей. Он стабильно работает и не мешает бизнесу. Задача архитекторов и разработчиков — поддерживать это состояние и постоянно улучшать системы.
Старые и новые системы: два примера от MANGO OFFICE
Речевая аналитика — новый сервис, построенный на микросервисной архитектуре, без накопленного legacy.
Биллинг — консервативная система с длинной историей. Основная логика реализована на Java и частично вынесена в базу PostgreSQL через хранимые процедуры.
Со временем система превратилась в монолит, в котором сложно разобраться и безопасно вносить изменения.
Постепенно части функциональности выносятся из ядра системы в отдельные микросервисы. Команда занимается этим процессом уже много лет.
Что дешевле: поддерживать или переписать
Краткосрочно поддержка legacy обходится дешевле, чем переписывание системы. Но без модернизации такой подход приводит к росту сроков, рисков и стоимости изменений. Поэтому нужно непрерывно замещать самые проблемные участки чем-то новым.
В MANGO OFFICE нет разделения на change и run. Каждая команда отвечает и за стабильность системы, и за её развитие.
Например, команда биллинга в прошлом квартале реализовала новый функционал в микросервисе и одновременно дорабатывала функции в основной базе. Пропорция примерно 50 на 50.
Почему big bang не работает
Есть два подхода к миграции legacy-систем:
Big bang — полная замена системы за один этап
Постепенное замещение — поэтапный вынос функциональности и «удушение» монолита
Практика и опыт архитекторов показывают, что постепенное замещение работает надёжнее, чем big bang.
Обычно начинают с самых проблемных частей системы и поэтапно выносят их в новые сервисы, параллельно развивая функциональность.
Что страшнее всего для пользователей
Самая большая проблема — не сама миграция, а момент, когда привычный функционал перестаёт работать из-за накопленных ограничений.
Например, пользователь много лет формировал отчёт по одному сценарию, а потом он внезапно перестал генерироваться. Причина — устаревший код, к которому долго не возвращались. В итоге страдает не только пользовательский опыт, но и доверие к продукту.
Современные инструменты позволяют проводить миграцию поэтапно и сохранять непрерывный пользовательский опыт — если заниматься этим заранее.
Пять признаков того, что с системой пора прощаться
Есть несколько сигналов, которые показывают, что система упёрлась в потолок:
сервис невозможно нормально дорабатывать
задачи выполняются заметно дольше, чем в других системах
сложно найти разработчиков под стек
высокая текучесть в команде
регулярные сбои и проблемы в работе
Если эти признаки проявляются одновременно, систему либо нужно серьёзно модернизировать, либо постепенно заменять. Даже если внешне она остаётся «той же самой».
Как оценить ресурсы для миграции
Чтобы оценить стоимость изменений, нужен план: что именно модернизируем и каким способом.
Если система замещается полностью, обычно формируют отдельную команду, которая параллельно переписывает функциональность и встраивается в существующие процессы.
Если модернизация идёт поэтапно — изменения выполняются внутри текущей команды и системы.
Такую работу лучше вести как проект: с планированием, расчётами и проектированием. Это снижает риск ошибиться в оценках и выйти за рамки бюджета.
Как защитить бюджет на миграцию
Самый рабочий аргумент для руководства — экономическое обоснование. Нужно показать, сколько денег компания потеряет на горизонте нескольких лет, если оставить систему без изменений: из-за сбоев, медленной разработки и ограничений роста.
Если расчёты показывают, что модернизация не даёт экономического эффекта, от неё действительно можно отказаться. Это тоже рациональное решение.
Заключение
Legacy — нормальное состояние зрелой IT-системы. Системы с длинной историей могут стабильно работать и развиваться, если ими заниматься осознанно.
Крайности не работают: ни полное переписывание системы с нуля, ни отказ от изменений. Постепенная модернизация позволяет снижать риски, сохранять пользовательский опыт и не останавливать бизнес.
Ключевые выводы:
поддержка legacy краткосрочно дешевле, но без модернизации тормозит развитие
постепенное замещение работает надёжнее, чем big bang
для защиты бюджета важны расчёты, а не лозунги
Полную версию подкаста с Константином Густовым можно посмотреть по ссылке — там больше деталей о работе с legacy-системами и реальных архитектурных кейсов из практики MANGO OFFICE.
