Итоги

НЕ ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Аналитику Тестировщику Архитектору Инженеру

Эта страница собирает раздел «Легаси-код» в одну картину. Если отдельная тема кажется туманной — откройте указанную главу или оглавление. Итоги удобно перечитать после статей 1–4 и перед чек-листом.

---

Главная мысль раздела

Легаси — нормальное состояние зрелых систем. Банки, госуслуги, ERP и крупные интернет-сервисы живут на коде, которому 10–20 лет. Проблема для новичка обычно в другом: неопределённость — вы не знаете, что сломается от одной строчки.

Хорошая новость: с легаси работают системно — понять → безопасно менять → модернизировать по плану. «Героизм» (ночной фикс без тестов) иногда спасает дедлайн, но увеличивает страх перед следующей правкой.

---

Главные определения

Легаси как наследие

Наследие (legacy) — код, конфигурация, база, процессы, которые вы или ваша команда не создавали (или создавали давно и забыли). Риски:

• устаревший стек (язык без поддержки, старая ОС);
• потеря знаний (автор уволился, документации нет);
• скрытые бизнес-правила («так исторически»);
• безопасность и комплаенс (старые библиотеки с CVE).

Легаси по Фезерсу

Майкл Фезерс в книге Working Effectively with Legacy Code называет легаси код без автотестов, которые дают уверенность при изменении. Для него главный риск — регресс: вы «починили» одно, сломали другое, и узнали об этом от пользователей.

Оба смысла вместе

На практике старое и без тестов часто идут рядом — это самый дорогой для сопровождения вариант. Но бывает и молодой код без тестов (уже легаси по Фезерсу) и старый код с хорошими тестами (управляемое наследие).

---

Как узнать, с чем имеете дело

Типы помогают выбрать первый шаг, а не ярлык «всё плохо».

Тип	Признаки	Что это значит для новичка	Первый ответ
Управляемое	есть границы модулей, тесты на критичных путях, воспроизводимый деплой	Можно учиться и править по книжке Фезерса	эволюция, локальный рефакторинг (3)
Тихое	в проде редко падает, но в команде боятся менять	Риск скрытый — инцидент «внезапный»	карта зависимостей, characterization-тесты (2, 3)
Кричащее	частые сбои, ручные обходы, «знаем обходной путь»	Техдолг уже бьёт по бизнесу	наблюдаемость + защитные тесты срочно
Критическое	нет исходников/истории, всё связано со всем	Одна правка = лотерея	реверс, ACL, Strangler или rewrite после оценки (2, 4)

Тихое легаси опасно тем, что менеджмент видит «всё работает» и не выделяет время на тесты — пока не случится крупный сбой.

---

Три опоры работы

Раздел построен как три навыка, которые дополняют друг друга.

1. Понять (статья 2)

Прежде чем менять, нужна модель в голове (и в документе):

• откуда пришёл код (git log, старые тикеты);
• кого спросить (поддержка, бывший автор);
• какие диаграммы нарисовать (компоненты, последовательность вызовов);
• что делать, если есть только .jar или бинарник (декомпиляция, логи).

Ошибка новичка: сразу «улучшать» непонятный метод. Лучше: зафиксировать поведение тестом, потом рефакторить.

2. Безопасно менять (статья 3)

Инструменты Фезерса:

• characterization tests — «как работает сейчас»;
• швы (seams) — точки подмены зависимостей в тесте;
• Sprout / Wrap — добавить новое рядом, не ломая старое;
• Mikado — разорвать клубок зависимостей мелкими шагами.

Ошибка новичка: один PR на 3000 строк «привёл в порядок». Лучше: серия маленьких PR с зелёным CI.

3. Модернизировать осознанно (статья 4)

Когда меняется архитектура целиком:

• Strangler Fig — выносить функции в новые сервисы по частям;
• Anti-Corruption Layer — не тащить модель легаси в новый код;
• clean room — новая реализация по спецификации, без копипасты старых исходников;
• rewrite — только при жёстких критериях (тупик стека, лицензия, потеря знаний).

---

Правила для команды (с пояснениями)

1. Сначала тест на поведение, потом рефакторинг.
   Тест — страховка. Без неё «красивый» рефакторинг может изменить сумму заказа.

2. Сначала гипотеза и фиксация в доке — потом правка.
   Запишите: «думаем, скидка считается здесь». Если ошиблись — дешевле, чем неделя отладки в проде.

3. Маленькие PR с понятным риском лучше месяца в одной ветке.
   Ревьюеру проще; откат проще; blame в git понятнее.

4. Уважать работающий код.
   «Странный» if может быть требованием закона или контрактом с партнёром. Спросите, прежде чем удалять.

5. Переписывание с нуля — исключение.
   По умолчанию — Strangler и постепенный вынос. Rewrite требует бюджета на два контура (старое + новое) параллельно.

6. Фиксировать решения (ADR).
   «Почему вынесли биллинг в сервис X» — подарок себе через год.

---

Мини-словарь раздела

Термин	Кратко
Регресс	Сломалось то, что раньше работало
Characterization test	Тест на текущее поведение, даже если оно «странное»
Seam (шов)	Место, где можно подменить зависимость
Strangler	Постепенная замена старой системы новой
ACL	Адаптер между вашим доменом и легаси
ADR	Architecture Decision Record — запись архитектурного решения
Техдолг	Упрощения в прошлом, за которые платите временем сейчас

---

Куда смотреть дальше

• Чек-лист самопроверки — вопросы перед merge или планом модернизации.
• Strangler Fig — миграция монолита.
• Юнит-тестирование — AAA, изоляция, структура тестов.
• Культура кода — как не усугублять легаси при каждой правке.
• О разделе — полный маршрут по материалам.

Полный маршрут по разделу — на странице о разделе.

---