Легаси обычно хотят «переписать». Это приятная фантазия до первого квартала, когда бизнес всё ещё едет на старом монстре, а новый сервис умеет половину сценариев и уже требует поддержки двух миров сразу. Я больше не продаю big rewrite как план по умолчанию — слишком дорого и слишком часто обманывает календарь.
Рабочая стратегия — найти узкое место боли и сделать там остров порядка. Например, вынести расчёт цены за антикоррупционный слой, накрыть тестами текущее поведение и только потом менять внутренности. Снаружи для клиентов ничего не взрывается, а внутри появляется зона, где уже можно дышать.
Остров порядка вместо большого взрыва
На практике маленькая победа выглядит скромно: один модуль с понятными границами, один флажок, один дашборд, один запрет на прямые лезть в чужие таблицы. Зато через месяц у вас есть плацдарм. Без плацдарма любой рефакторинг расползается по репозиторию как плесень и его невозможно откатить кусками.
Важный момент — не улучшать всё, до чего дотянетесь. Форматирование тысяч файлов в том же PR, что и смена схемы БД, — классика, после которой ревью умирает, а bisect превращается в ад. Отделяйте косметику от поведения, даже если руки чешутся «заодно уж». Маленькие победы надо показывать: до/после по времени фичи, ручным правкам, онбордингу. Без видимого эффекта снова попросят «переписать». Веду короткий список честных метрик — не идеальных, но живых.
Документируйте инварианты, которые «все и так знают». В легаси знание сидит в головах людей, которые уже на другом проекте или в другой компании. Запись «этот статус нельзя переводить назад без ручной правки» экономит чужие ночи лучше красивой диаграммы архитектуры.
Фиксируйте странности тестами
Ещё совет с полем: закладывайте время на характеризационные тесты до изменений. Да, они фиксируют странности. Именно странности потом всплывут как «регресс», хотя вы «просто привели к нормальной архитектуре». Странное поведение для бизнеса иногда и есть контракт. Не смешивайте миграцию людей с миграцией кода. Если половина команды деплоит по-старому, остров порядка зарастёт обходами. Сделайте новый путь проще старого — иначе победит привычка.
Не обещайте красивую архитектуру к дате. Обещайте снижение конкретного риска: меньше ручных правок в проде, быстрее онбординг, короче путь новой фичи, меньше падений на известном сценарии. Руководству это понятнее, чем «гексагональный мир к Q3».
И держите список «священных коров» — мест, которые трогать нельзя без пары глаз и плана отката. Это не трусость, а способ не превратить маленькие победы в большой простой.
Когда берётесь за легаси вдвоём, разделите роли: один копает поведение и тесты, второй режет границы модуля. Если оба сразу «улучшают архитектуру», получается шумный PR без понятного инварианта. На практике я ещё ставлю календарный стоп: через две недели должен быть видимый результат в проде или флажок, иначе копание превращается в бесконечный рефакторинг-хобби. Легаси прощает маленькие победы и жестоко наказывает романтику без поставки.