Легаси: рефакторинг, замена модулями или переписать с нуля

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

Почему всё время хочется переписать

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

Джоэл Спольски разобрал эту ловушку в статье «Things You Should Never Do». Netscape решила переписать браузер с нуля, и между версиями 4.0 и 6.0 прошло почти три года. Всё это время компания не выпускала ничего нового, а рынок занимали конкуренты.

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

Четыре варианта, из которых выбираем

Коротко напомним варианты, подробнее о каждом в статье «Легаси: что это такое и что делать бизнесу».

• Поддерживать как есть. Стабильность, мониторинг, обновления безопасности. Код почти не меняется.
• Рефакторинг по частям. Улучшаем код там, где его всё равно трогаем: покрываем тестами, упрощаем, документируем.
• Замена модулями. Новые части пишутся рядом со старой системой и постепенно забирают её функции.
• Переписать с нуля. Новая система разрабатывается параллельно и в какой-то день заменяет старую целиком.

Пять вопросов, которые решают выбор

Решение принимается не по тому, насколько код неприятен, а по ответам на пять вопросов о системе и бизнесе.

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

Рефакторинг или переписать: сравнение по деньгам и рискам

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

Как рефакторить легаси, не ломая работающее

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

1. Сначала мониторинг. Прежде чем менять код, нужно видеть, работает ли система: ошибки, время ответа, ключевые сценарии вроде оформления заказа. Иначе о поломке расскажут клиенты.
2. Характеризующие тесты. Майкл Фэзерс предлагает фиксировать тестами то, как код работает сейчас, даже если это поведение кажется странным. Тест не проверяет, правильно ли считается скидка, он проверяет, что после правки она считается так же, как до неё.
3. Маленькие шаги. Одна правка, одна проверка, одна выкладка. Большие изменения в легаси почти всегда заканчиваются откатом.
4. Только там, где трогаем. Рефакторить всё подряд бессмысленно. Улучшаем ту часть, в которой и так нужно делать доработку для бизнеса.
5. Документация по ходу. Каждое найденное бизнес-правило записывается. Через полгода у вас есть описание системы, которого не было.

Замена модулями на практике

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

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

Когда переписать с нуля действительно правильно

Переписывание не всегда ошибка. Оно оправдано, если совпадает несколько условий:

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

Даже в этом случае полезно идти этапами: сначала переписать часть, запустить её рядом со старой, и только потом браться за остальное.

Как принять решение за 2-3 недели

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

Аудит удобен ещё и тем, что его делает команда без конфликта интересов. Отчёт остаётся у вас, и по нему можно работать с кем угодно.

Частые вопросы

Что такое рефакторинг легаси кода?

Это улучшение внутреннего устройства старого кода без изменения того, что он делает для пользователей: упрощение, разбиение на части, покрытие тестами. Для бизнеса результат такой: доработки становятся быстрее и дешевле, а сбоев меньше.

Сколько стоит переписать систему с нуля?

Обычно больше, чем кажется на старте: к стоимости разработки добавляется поддержка старой системы на всё время переезда, перенос данных и исправление забытых бизнес-правил после запуска. Сравнивать стоит полную стоимость обоих вариантов на горизонте 1-2 лет.

Можно ли совмещать рефакторинг и новые функции?

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

Сколько длится замена системы модулями?

Зависит от размера. Первый модуль обычно уходит в работу через 1-3 месяца, а полный переезд платформы среднего размера занимает от нескольких месяцев до года. Переезд Дари Крю с no-code на собственный код занял 2,5 месяца.

С чего начать, если решение пока не принято?

С аудита и мониторинга. Мониторинг снижает риски уже сейчас, а аудит даёт факты для решения. Как подготовиться к смене команды, читайте в статье про работу с легаси-кодом и передачу проекта.