📄 Статьи

Как я работаю с легаси-проектами

«Легаси» — это слово, которое пугает бизнес. Оно звучит как приговор. «У нас легаси, мы ничего не можем сделать». Но на самом деле легаси — это не приговор. Это просто код, который уже написан.

Легаси-проект требует больше времени. Времени, которое уйдёт на анализ существующего кода и базы данных. Это не «посмотрел и понял». Это системная работа.

Проверьте, знакомы ли вам другие симптомы ИТ-хаоса →

1. Что такое легаси на самом деле

Легаси — это система, которая:

Уже работает (как-то).
Написана давно (3, 5, 10 лет назад).
Никто не знает, как она устроена.
Документации нет (или она устарела).
Её боятся трогать.

Легаси — это актив, а не долг. Просто он требует правильного обращения.

2. С чего я начинаю

Я не лезу в код. Сначала я смотрю на систему сверху.

2.1. Я спрашиваю

Что система делает сейчас?
Что она должна делать?
Что в ней работает, а что нет?
Кто её использует?
Какие данные в ней хранятся?

Ответы дают 50% понимания.

2.2. Я ищу разработчика, который знает систему

Если есть разработчик, который работал с этой системой — это золото. Я прошу контакт и связываюсь с ним. Один разговор с человеком, который знает код, экономит недели анализа.

Если есть документация — я прошу её. Даже если она устарела, она даёт понимание того, как система задумывалась.

3. Доступ к коду и данным

Для работы с легаси-проектом мне нужен доступ к копии кода и структуре базы данных. Я не прошу доступ к рабочему серверу. Я прошу копию.

Я прекрасно понимаю, что данные конфиденциальны. Поэтому я сразу снимаю это опасение:

Мне нужен доступ не к рабочему коду, а к его копии.

При необходимости я выдаю инструкцию вашему разработчику:

Как организовать копию на сервере.
Как предоставить доступ мне.
Как исключить доступ к реальным данным.

Всё это детально отражается в NDA-разделе договора. Вы защищены. Я защищён.

4. Что делать, если нет ни разработчика, ни документации

Это худший, но самый частый сценарий.

Система есть. Она работает. Но никто не знает, как она работает. Нет документации. Нет разработчика, который бы помнил, что там написано.

В этом случае переписывание становится очень вероятным сценарием. Особенно если система написана в монолитном стиле, который встречается гораздо чаще, чем микросервисы.

Я не говорю «сразу переписываем». Но я говорю: «Будьте готовы к тому, что это может быть единственным разумным вариантом».

5. Как я принимаю решение

После анализа я принимаю одно из трёх решений:

5.1. Рефакторинг

Если система в целом работает, но есть узкие места — я предлагаю рефакторинг. Мы не переписываем всё, мы улучшаем отдельные части.

Это дёшево, быстро и безопасно.

5.2. Частичная замена

Если система сильно устарела, но её можно заменить по частям — я предлагаю частичную замену. Мы заменяем один модуль за другим. Каждый модуль — отдельный этап.

Это средняя сложность и средняя цена.

5.3. Полное переписывание

Если система не подлежит рефакторингу — я предлагаю полное переписывание. Но только если:

Старая система не поддерживается (нет разработчиков, нет документации, нет тестов).
Требования изменились настолько, что старую систему нельзя адаптировать.
Бизнес готов вложиться в новую систему.

Это дорого, долго и рискованно. Я рекомендую этот вариант только в крайних случаях.