Legacy-код: что это и когда поддерживать, рефакторить или переписать

Legacy-код (легаси, от англ. legacy — «наследие») — это программный код, который достался команде по наследству: его писали другие люди, в другое время и по другим правилам, а теперь на нём работает бизнес. Речь именно о коде сайтов и информационных систем, а не об одноимённых играх. Легаси-проект — это сайт, интернет-магазин или внутренняя система, где такого кода большинство и любое изменение даётся тяжелее, чем должно.

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

Легаси: что это такое простыми словами

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

Типичные признаки:

• Нет тестов. Проверить, что правка ничего не сломала, можно только руками — и то не всё.
• Нет документации и автора. Знания о том, почему сделано именно так, ушли вместе с разработчиком.
• Устаревший стек. Язык, фреймворк или CMS больше не получают обновлений безопасности.
• Нет нормального процесса. Правки заливаются по FTP прямо на рабочий сервер, git отсутствует или не совпадает с тем, что крутится в продакшене.
• Правленое ядро. Изменения внесены прямо в файлы CMS или сторонних библиотек, поэтому обновить их без потерь нельзя.

Устаревший стек: даты окончания поддержки

Самый объективный признак легаси — платформа, которую разработчики уже не поддерживают. После даты EOL (end of life) новые уязвимости в ней никто не закрывает. Сверьтесь с таблицей:

Отдельные случаи — jQuery-монолиты и Битрикс со старым ядром. У jQuery нет «даты смерти», но проект, где вся логика интерфейса — это тысячи строк обработчиков в одном файле, трудно развивать и почти невозможно покрыть тестами. У 1С-Битрикс обновления ядра приходят только при активной лицензии: если её не продлевали несколько лет, а ядро правили напрямую, сайт застревает на старой версии, которая плохо совместима с актуальным PHP. Как выходить из этого состояния, подробно разобрано в статье про обновление 1С-Битрикс.

Почему бизнес живёт на легаси — и это нормально

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

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

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

Риски легаси-проекта для бизнеса

Легаси становится проблемой, когда его риски начинают стоить дороже, чем работа по их снижению. Четыре основных:

Безопасность

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

Найм и зависимость от людей

Разработчиков на Yii1, AngularJS или самописном фреймворке 2012 года мало, и они дороже. Хуже, когда проект знает один человек: он заболел, уволился или поднял ставку вдвое — и бизнес остаётся с системой, которую никто не может поправить. Это называют «фактор автобуса».

Скорость изменений

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

Инфраструктура

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

Как принять легаси-проект на поддержку: первые шаги

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

1. Доступы. Собрать все: хостинг, SSH, база, домен, DNS, панель CMS, репозиторий, почта, платёжные и сторонние сервисы. Сменить пароли, если прежний подрядчик ушёл. Проверить, на кого оформлены домен и хостинг.
2. Бэкапы. Сделать полную копию файлов и базы и проверить, что из неё реально разворачивается рабочий сайт. Бэкап, из которого не пробовали восстанавливаться, бэкапом не считается.
3. Код под контроль версий. Выгрузить то, что работает на сервере, в git — именно из продакшена, а не из репозитория подрядчика: они часто расходятся.
4. Тестовая копия. Развернуть стенд с теми же версиями PHP и базы, закрытый от индексации и с отключёнными интеграциями, чтобы не слать письма клиентам и заказы в 1С.
5. Мониторинг. Настроить проверку доступности, сбор ошибок и контроль срока SSL и домена. Вы должны узнавать о падении раньше клиентов.
6. Инвентаризация. Описать стек и версии, интеграции, cron-задачи, внешние API, правки ядра, «особые» места, о которых предупреждал прежний разработчик.

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

Поддерживать, рефакторить или переписать: матрица решения

У легаси-проекта три пути. Выбирать между ними стоит не по ощущениям разработчиков («тут всё ужасно»), а по признакам:

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

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

Ловушки «большого переписывания»

Идея «выкинем всё и сделаем правильно» привлекательна, особенно когда её предлагает новый подрядчик. Типичные ловушки:

• Две системы вместо одной. Пока пишется новая версия, старую надо поддерживать и развивать. Бизнес не может заморозить изменения на год, и новая система вечно догоняет старую.
• Потерянная логика. Новые разработчики переносят то, что видно в интерфейсе, и пропускают скрытые правила: округления, исключения для оптовиков, обработку сбоев обмена. Ошибки всплывают после запуска, на реальных заказах.
• Оценка «на глаз». Сроки переписывания почти всегда занижены, потому что объём старой системы никто не измерял. Проект растягивается вдвое, бюджет — тоже.
• Потеря SEO. Меняются адреса страниц, шаблоны, метатеги — и накопленный трафик падает, если миграцию не планировали отдельно.
• Новое легаси. Через три года переписанная система без тестов и документации станет таким же легаси, если не поменять процесс разработки.

Как выбрать подрядчика для легаси-проекта

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

• С какими стеками вы работаете, кроме актуальных? Есть ли опыт с нашей версией PHP, CMS или фреймворка?
• Что вы делаете в первые две недели после приёмки проекта? Хороший ответ — доступы, бэкапы, стенд, мониторинг, аудит; плохой — «сразу начнём править».
• Как вы проверяете, что правка ничего не сломала, если в проекте нет тестов?
• Как документируете то, что узнали о системе? Кому принадлежат эти документы?
• Сколько человек в команде будет знать проект? Что будет, если ваш разработчик уйдёт?
• Как вы фиксируете оценку и что происходит, если в коде нашлись сюрпризы?

Независимое мнение до решения о рефакторинге или переписывании даёт технический аудит кода: по его итогам видно, какие риски критичны, какие плановые и сколько стоит их закрытие. Ориентиры по стоимости: экспресс-аудит небольшого сайта — от 30 000 ₽, полный аудит кода и инфраструктуры — от 60 000 ₽, абонентская поддержка — от 50 000 ₽ в месяц; итоговая цена зависит от объёма кода, числа интеграций и состояния сервера.

Чек-лист первых 30 дней с легаси-проектом

• Все доступы собраны, пароли сменены, домен и хостинг оформлены на компанию
• Полный бэкап снят, восстановление из него проверено на отдельном сервере
• Код с рабочего сервера лежит в git, правки идут только через репозиторий
• Развёрнута тестовая копия, закрытая от индексации, с отключёнными интеграциями
• Настроен мониторинг доступности, ошибок, срока SSL и домена
• Составлена карта системы: стек и версии, интеграции, cron, внешние сервисы, правки ядра
• Проверены версии PHP, CMS и библиотек на EOL и известные уязвимости
• Критичные сценарии (заказ, оплата, формы, обмен с 1С) покрыты хотя бы ручным сценарием проверки или характеризационными тестами
• Риски разделены на «критично / планово / косметика» с оценкой в часах
• Принято решение по матрице: поддерживать, рефакторить по частям или переписывать

Вывод

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