Как пошагово отрефакторить код, нарушающий SOLID?

Рефакторинг к SOLID делают маленькими безопасными шагами под защитой тестов, начиная с места, которое чаще всего меняется, а не переписыванием модуля по учебнику.

Шаги

1. Характеризационные тесты. Зафиксировать текущее поведение, включая странное: снапшоты, golden master. Без них это переписывание наугад.
2. Найти горячую точку. git log --format= --name-only | sort | uniq -c | sort -rn покажет самые часто правящиеся файлы; пересечение с размером и сложностью — кандидаты.
3. Выделить чистые функции (SRP). Extract Function и Extract Class для расчётов и форматирования — самый дешёвый шаг.
4. Разорвать жёсткие зависимости (DIP). new HttpClient() внутри класса превращается в параметр конструктора — сначала со значением по умолчанию, чтобы не трогать вызывающих.
5. Убрать ветвление по типу (OCP). Replace Conditional with Polymorphism или таблица стратегий.
6. Сузить интерфейсы (ISP) по фактическим потребителям.

Правила процесса

• Один коммит — один рефакторинг, без смешивания с фичами: проще ревьюить и откатывать.
• Strangler Fig для крупных модулей: новая реализация растёт рядом, вызовы переключаются постепенно.
• Parallel change (expand → migrate → contract) для публичных API: старый и новый контракт какое-то время живут вместе.
• IDE-рефакторинги (rename, extract, move) надёжнее ручных правок.

Коротко для собеседования

Двигаться маленькими шагами под защитой характеризационных тестов: найти самый часто меняющийся файл, выделить чистые функции, разорвать жёсткие зависимости и убрать ветвления по типу. Останавливаются, когда изменения в этой зоне стали дешёвыми, — цель в скорости правок, а не в идеальной архитектуре.