Первым импульсом было переписать всё с нуля. Но реальность проще: у нас есть прод, дедлайны и пользователи, которым неинтересно, насколько «красивый» у нас код. Им важно, чтобы цифры в отчёте были правильными.
Вместо большого переписывания мы пошли через серию узких шагов. Сначала обложили модуль характеризационными тестами: зафиксировали текущее поведение, даже если оно местами странное. Только после этого начали выносить куски логики в отдельные функции.
Три правила, которые сработали
1. Меняем только то, что можем покрыть тестом в этот же день.
2. Каждый PR должен уменьшать связанность, даже если всего на 5%.
3. Если нужна «временная заглушка», создаём задачу на удаление сразу же.
Через шесть недель модуль стал не идеальным, но понятным: функции короче, ответственность разделена, ошибки локализуются быстрее. Время на разбор багов сократилось заметно.
Хороший рефакторинг редко выглядит как подвиг. Чаще это тихая, повторяемая работа.
Самый приятный эффект оказался неожиданным: на ревью стало меньше споров «как правильно», потому что код перестал быть монолитной загадкой. Когда структура ясная, решения обсуждаются по сути, а не на уровне вкуса.