Содержание
Легаси (от англ. legacy, «наследство») это код или целая система, которые достались компании от прошлых разработчиков. На практике это значит, что система работает и приносит деньги, но целиком её никто не понимает, и любое изменение пугает. Легаси в программировании не равно «плохой код». Чаще это код, у которого не осталось хозяина, и с ним можно работать, не останавливая продажи.
Что такое легаси простыми словами
Слово пришло из английского: legacy значит «наследство». В разработке так называют код, который вы получили от кого-то и продолжаете использовать. Его написала прошлая команда, уволившийся программист, пропавший подрядчик или вы сами пять лет назад, и с тех пор многое забылось.
Майкл Фэзерс, автор книги «Эффективная работа с унаследованным кодом», дал инженерное определение: легаси это код без тестов. Если нельзя быстро проверить, что после правки всё работает как раньше, любое изменение превращается в лотерею.
Для бизнеса удобнее третье определение: легаси это система, которая приносит деньги, но которую страшно трогать. Каталог интернет-магазина на Битриксе 2016 года, самописный личный кабинет на старом PHP, биллинг, в котором «разбирается только Сергей». Пока такая система работает, о ней не думают. Проблемы начинаются, когда нужно что-то поменять.
Легаси-код, legacy-код и унаследованный код означают одно и то же. В русском языке прижилась калька «легаси», реже говорят «наследие» или «унаследованная система».
Признаки легаси в вашей системе
Возраст сам по себе ничего не значит. Сервис 2012 года с тестами, документацией и командой, которая его знает, легаси не является. А проект прошлого года, автор которого уволился, вполне может им быть. Проверьте свою систему по восьми признакам.
Если совпало три и больше, вы живёте с легаси, даже если так его не называете. При этом каждый признак закрывается отдельно и без остановки бизнеса. Мониторинг включается за день, документация пишется по ходу работы, тесты появляются там, где код всё равно меняют.
Откуда берётся легаси
Плохие программисты тут почти ни при чём. Легаси создают обычные решения, каждое из которых в своё время было разумным.
- Сроки. Запуститься нужно было к сезону, тесты и документацию отложили «на потом».
- Смена людей. Автор ушёл, знания ушли вместе с ним. Новые разработчики правят точечно и боятся лезть глубже.
- Подрядчики. Каждый дописывал своё в своём стиле. Через три смены команды в коде четыре способа сделать одно и то же.
- Время. CMS, фреймворк или версия PHP перестали получать обновления, а переход откладывали годами.
- Рост. Система задумывалась под 100 заказов в день, а их уже 5 000. Архитектура держится на заплатках.
Легаси нормальное состояние любой живой системы. Если продукт прожил пять лет и приносит деньги, часть его кода неизбежно стала наследством. Поэтому важнее другой вопрос: управляете ли вы им.
Чем легаси опасно для бизнеса
Разработчики жалуются на легаси, потому что с ним неприятно работать. Собственнику важнее другое: легаси медленно превращается в расходы, которых нет в бюджете.
| Риск | Как выглядит | Во что обходится |
|---|---|---|
| Дорогие доработки | Простая задача занимает неделю: сначала нужно понять, что сломается | Каждая новая функция стоит дороже и выходит позже |
| Долгие простои | Сайт упал, а где искать причину, никто не знает | Часы, а иногда дни без заказов и заявок |
| Один человек знает всё | Только один разработчик понимает биллинг или обмен с 1С | Он заболел или ушёл, и система осталась без хозяина |
| Безопасность | Старые версии PHP, CMS и библиотек без исправлений | Взлом, утечка данных, претензии платёжного провайдера |
| Потолок роста | Новая интеграция или нагрузка не ложится на старую архитектуру | Упущенные продажи и отложенные планы |
Эти расходы видны и в цифрах. По исследованию Stripe The Developer Coefficient, разработчики тратят в среднем 17,3 часа из 41-часовой рабочей недели на отладку, исправление ошибок и переделку старого кода. Это больше 40% оплаченного времени, которое не превращается в новые функции.
Что делать с легаси: четыре стратегии
Вариантов всего четыре. Выбирать между ними стоит по деньгам и рискам. То, насколько код неприятен разработчикам, тут плохой советчик.
- Поддерживать как есть. Система стабильна, меняется редко, бизнес-логика не растёт. Хватит мониторинга, бэкапов, обновлений безопасности и команды, которая разберётся при сбое.
- Рефакторить по частям. Код рабочий, но каждая доработка даётся тяжело. Улучшаем ту часть, которую всё равно трогаем: покрываем тестами, упрощаем, документируем.
- Заменять модулями. Архитектура не тянет рост. Новые части пишутся рядом со старой системой и постепенно забирают её функции, пока старое не получится выключить. Мартин Фаулер назвал этот подход «душащей смоковницей» (strangler fig).
- Переписать с нуля. Оправдано редко: когда платформа умерла, а бизнес-логика маленькая и понятная. В остальных случаях это самый дорогой путь. Месяцами вы платите за новую систему, которая ещё ничего не зарабатывает, а старая продолжает требовать денег.
Как выбрать между рефакторингом и переписыванием, подробно разобрали в статье «Легаси-система: поддерживать, рефакторить или переписать».
С чего начать: первые 30 дней
Даже если решение о будущем системы ещё не принято, есть шаги, которые снижают риски сразу.
- Соберите доступы. Репозитории, серверы, домен, хостинг, базы данных, платёжные шлюзы, почта для уведомлений. Всё должно принадлежать компании, а не подрядчику или сотруднику. Что именно забрать при смене команды, собрали в чек-листе передачи проекта.
- Включите мониторинг и бэкапы. Вы должны узнавать о сбое раньше клиентов и иметь копию, из которой можно восстановиться. Как это устроить, рассказали в статье про мониторинг доступности сайта.
- Составьте карту системы. Из каких частей она состоит, как они связаны, какие внешние сервисы используются, где лежат данные. Это 5-10 страниц, которые экономят месяцы.
- Найдите риски. Устаревшие версии, уязвимости, единственные точки отказа, места, которые знает только один человек. Это задача аудита кода.
- Составьте план. Что чинить сейчас, что через квартал, что можно не трогать. С оценкой стоимости каждого шага.
Когда звать внешнюю команду
Своя команда справляется с легаси, пока в ней есть человек, который понимает систему, и время на что-то кроме срочных задач. Внешняя команда нужна, когда:
- автор системы ушёл, а новые разработчики боятся её трогать;
- подрядчик пропал, остались только код и доступы;
- инциденты повторяются, а первопричину никто не ищет;
- нужно решить, развивать систему или переписывать, и хочется взгляда без конфликта интересов.
Мы в ИнТерраТех работаем именно с такими системами: подключаемся к чужому коду, разбираемся, как он устроен, и берём на поддержку. Первый шаг всегда технический аудит: на выходе карта системы, риски с приоритетами и план работ. Отчёт остаётся у вас, даже если дальше вы пойдёте с ним к другой команде. Если система нужна в рабочем состоянии уже сейчас, подключаемся на поддержку по SLA со сроками реакции в договоре.
Частые вопросы
Легаси это плохо?
Нет. Легаси значит, что система прожила достаточно долго, чтобы приносить деньги. Плохо, когда им не управляют: нет мониторинга, документации и человека, который понимает систему целиком.
Чем легаси отличается от технического долга?
Технический долг это конкретные компромиссы в коде, которые придётся исправлять: временные решения, пропущенные тесты, устаревшие библиотеки. Легаси шире: это состояние системы, в которой долг накопился, а знания о ней потеряны. Подробнее в статье «Технический долг: когда он начинает стоить денег».
Можно ли просто переписать легаси с нуля?
Можно, но это самый рискованный вариант. Новая система месяцами не приносит денег, а старую всё это время нужно поддерживать. Обычно выгоднее постепенно заменять самые проблемные части и оставлять остальное работать.
Сколько времени нужно, чтобы разобраться в легаси-системе?
Зависит от размера: от нескольких дней для сайта на CMS до нескольких недель для платформы из нескольких систем. Платформу из 8 систем и 100+ репозиториев мы разобрали за 3 недели. Срок и состав аудита стоит фиксировать до старта.
Легаси-код и legacy-код это одно и то же?
Да. «Легаси» это русская запись английского legacy. Ещё говорят «унаследованный код» или «наследие».
