Legacy — это не приговор, а инженерная задача

Слово «legacy» часто вызывает ужас. Но давайте честно: любой код, который вы написали полгода назад — это уже legacy для вас самих.

Работал с системой, где 80% логики было в хранимых процедурах, а документация была старше динозавров. Вместо того чтобы кричать «надо всё переписать!», сделал иначе:

🔍 Шаг 1: Картирование зависимостей Построил граф вызовов между модулями. Оказалось, что «монолит» на самом деле состоит из 3 относительно независимых частей.

📊 Шаг 2: Метрики как аргумент Вместо «тут всё плохо» показал: цикломатическая сложность в некоторых модулях >50, покрытие тестами 0%.

🧪 Шаг 3: Тесты-щит Перед любым рефакторингом — characterization tests. Даже если они тестируют неправильное поведение, они защищают от регрессий.

🔧 Шаг 4: Странгулятор (Strangler Fig) Не переписываю всё сразу. Выделяю один endpoint, делаю его правильно, переключаю трафик, повторяю. Либо горизонтальный рефакторинг, если бизнес-логика сложная, проходит через много контекстов или эндпоинтов много.

Результат: через 3 месяца 80% системы переписано, время разработки новых фич сократилось в 3 раза, никто не выгорел.

💡 Вывод: Legacy — это не проблема кода, это проблема подхода. Системная работа beats героические усилия.

А как вы работаете с legacy? Делитесь подходами!

#LegacyCode #Refactoring #SoftwareEngineering #BestPractices #TechDebt

Legacy — это не приговор, а инженерная задача | Сетка — социальная сеть от hh.ru