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
· 23.05
Legacy не проблема значит для тебя? с 1С ты просто наверняка еще не сталкивался 🤭 Legacy в моем понимании - невозможность делать realtime хуки/вызовы во всем бэкенде.
ответить
коммент удалён
· 23.05
Почему же — для меня это проблема подхода :)
ответить
ответ удалён