Как вы проводите рефакторинг большого legacy-кода и убеждаете руководство в его необходимости?

Рефакторинг legacy-проекта — постепенный, поэтапный процесс. Обычно я начинаю с участков кода, которые чаще всего изменяются или вызывают проблемы. Покрываю ключевые части автоматическими тестами (если их нет), чтобы иметь страховку при изменениях. Затем мелкими шагами переписываю код: выделяю функции, разбиваю слишком большие методы, устраняю дублирование, вводя общие модули, улучшаю читаемость (именование, структура). Важно каждый шаг проверять тестами, избегая изменения внешнего поведения. Чтобы убедить менеджмент/заказчика, делаю акцент на выгодах: снижение количества ошибок, упрощение внедрения новых функций, уменьшение расходов на поддержку. Можно привести недавние случаи, когда из-за "сложности и запутанности" мы долго исправляли баг или медленно внедряли изменения — показать, что рефакторинг окупится в будущем ускорением разработки и повысит качество. Часто практикуется рефакторинг при разработке новых фич (refactor by need): объясняю, что без улучшения существующего кода внедрение новой функции займёт гораздо больше времени или будет ненадёжным. Демонстрируя конкретные показатели (например, "после рефакторинга время на добавление аналогичной функциональности сократилось вдвое"), можно заручиться поддержкой руководства.