Legacy codebase — это не просто «старый код». Чаще всего это система, которая приносит бизнесу деньги, но при этом:
- плохо документирована
- тесно связана между модулями
- покрыта тестами частично или не покрыта вовсе
- хранит неожиданные зависимости и «исторические решения»
Главная ошибка при работе с legacy — пытаться «сразу всё переписать». На практике это почти всегда дорого, рискованно и долго. Гораздо эффективнее — снижать хаос постепенно.
Что делать в первую очередь
-
Изучить систему через точки боли
Начинайте не с полного аудита, а с проблемных мест: багов, медленных фич, нестабильных модулей. Так быстрее становится понятно, где технический долг действительно мешает бизнесу. -
Построить карту зависимостей
Нужно выяснить, какие части системы критичны, что от чего зависит, где внешние интеграции, очереди, cron-задачи, общие библиотеки. Без этого любое изменение может задеть неожиданную область. -
Добавлять тесты перед правками
Если модуль нельзя безопасно менять, сначала создают characterization tests — тесты, которые фиксируют текущее поведение системы, даже если оно выглядит странно. Это база для рефакторинга 🛠️
Стратегии выживания в legacy
-
Правило бойскаута
Оставляйте код чуть чище, чем нашли: понятнее имя метода, удалённый дубликат, маленький рефакторинг, комментарий к неочевидной логике. Микроулучшения на дистанции дают большой эффект. -
Изоляция изменений
Не тащите крупный рефакторинг в одну задачу с бизнес-фичей. Лучше минимизировать зону изменений: меньше файлов, меньше побочных эффектов, проще ревью и откат. -
Strangler Pattern
Если системе нужно обновлять серьёзно, не переписывайте всё сразу. Новую логику постепенно выносят в отдельные сервисы или модули, а старую часть заменяют поэтапно. -
Документировать решения по ходу
В legacy особенно полезны короткие ADR, схемы потоков данных, README по модулям. Память команды ненадёжна, а документация снижает bus factor 📚
Как не выгореть
- не стремиться к идеалу
- согласовывать технические улучшения с бизнес-ценностью
- измерять прогресс: меньше инцидентов, быстрее релизы, проще онбординг
- принимать, что «достаточно хорошо» иногда лучше, чем «архитектурно красиво» ⚙️
Когда стоит бить тревогу
Если в проекте:
- любое изменение ломает соседние модули
- нет среды для безопасного тестирования
- знания держатся на 1–2 людях
- сроки всегда съедаются из-за скрытой сложности
— значит, техдолг уже стал управленческой проблемой, а не только инженерной 🚨
Работа с legacy codebase — это не героизм и не война со «старым кодом». Это дисциплина: маленькие безопасные изменения, тесты, наблюдаемость и ясные приоритеты. Именно так сложные системы становятся поддерживаемыми без дорогого хаоса.
👀 Посмотрите подборку каналов про IT — там ещё больше практики, кейсов и инструментов для разработки.