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

Желание рефакторить есть у всех, но прежде чем трогать код, спросите: где болит?

Когда я только начинал делать приложения, каждые несколько месяцев я попадал в цикл: добавление новой фичи занимало вечность, исправление бага требовало погружения в запутанный код. Я хлопал по столу и говорил «рефакторинг». Через две недели новый модуль выходил в релиз — и тут же падал на устройствах пользователей, после чего ещё две недели уходили на исправление регрессий. А исходная боль уменьшалась лишь на 60%.

С тех пор я понял одну вещь: грязный код сам по себе — не повод для рефакторинга. Повод — боль в бизнесе.

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

Какую боль вы чувствуете?

Вот несколько типичных сценариев, каждый требует своей реакции:

1. Экспоненциальный рост стоимости инкрементальных фич

Замерьте реальное время на последние пять небольших фич (например, добавить опцию в настройках, изменить сортировку). Если среднее время выросло в 3 раза и более по сравнению с началом проекта, и каждое изменение затрагивает 5+ файлов или классов, архитектура вас тормозит. Но надо отличать: это плохие границы модулей или просто неаккуратный стиль? Первое требует рефакторинга, второе — правил и линтинга.

2. Изменение A обязательно ломает B

Это сильная связанность. Если было два случая, когда изменение платёжного процесса ломало логин, значит, границы неверны. Даже если фичи сдаются вовремя, нужно в первую очередь расцепить зависимости.

3. Новички тратят больше времени на понимание кода, чем на понимание бизнеса

Маленькие команды редко нанимают, но когда нанимают, по лицу новичка видно всё. Если ему нужно несколько дней, чтобы разобраться в навигации и наследовании классов, прежде чем понять продукт, в архитектуре не хватает ясности.

4. Время сборки мешает работе

Если для небольшого изменения интерфейса нужно ждать 2 минуты, фокус команды разбивается. Но медленная сборка — не всегда проблема архитектуры; это может быть управление зависимостями или недостаточная модульность. Изолируйте модули, прежде чем думать о полном рефакторинге.

Простая матрица решений

Я использую пять вопросов. Чем больше «да», тем выше срочность:

1. Среднее время доработки модуля > 2,5× от исторического среднего?
2. Было ли 2+ межмодульных регрессионных бага за последний месяц?
3. Только один человек в команде может понять и поддерживать этот код?
4. Есть ли чёткая потребность в фиче, которая блокируется связанностью кода?
5. Стал ли процесс сборки/тестирования узким местом в повседневной разработке?

Если 3+ ответа «да» — стоит задуматься о рефакторинге. Если 1–2 — я рекомендую локальные улучшения или добавление тестов, а не масштабные изменения.

Постепенный рефакторинг — единственный путь для маленьких команд

Я наступал на грабли достаточно раз, чтобы знать: «большой взрыв» — ловушка. Вот мой подход:

Шаг 1: Нарисуйте ров. Напишите интеграционные тесты для ключевых путей модуля, который собираетесь трогать. Даже простой UI smoke-тест лучше, чем нырять в рефакторинг вслепую.

Шаг 2: Извлекайте, а не переписывайте. Выделите наиболее изменчивую подфункцию в отдельный модуль, сохранив интерфейс. Например, у меня логика рекомендаций была вшита в Activity. Я вынес её в отдельный Presenter/ViewModel с тем же публичным API. Все 20 точек вызова остались нетронутыми — риск минимален.

Шаг 3: Заменяйте партиями. Не рефакторите весь модуль сразу. Отсортируйте подкомпоненты по частоте изменений — самые изменяемые получают приоритет. Код, который почти не трогали, может никогда не понадобиться переписывать.

Шаг 4: Серый релиз. Используйте feature flag, чтобы новый код попал только на часть пользователей. Если crash rate растёт — моментально откатывайтесь.

Остерегайтесь ложной боли

Иногда кажется, что код грязный, но на самом деле проблема в частых изменениях требований, а не в архитектуре. Если продукт всё ещё в режиме поиска PMF и каждую неделю меняет направление, грязный код — это нормально. Рефакторинг на этом этапе — строительство замка на песке.

Ещё одна ложная боль: «код другого разработчика ужасен». Каждый пишет плохой код, но если вы можете его прочитать, понять и тесты покрывают — он рабочий. Спросите себя: если бы это написали вы сами, вы бы всё равно хотели рефакторить?

Гипотетический пример

Представьте, я делаю приложение для заметок. MVP — один Activity с множеством Fragment'ов, сетевые запросы внутри Fragment'ов. Через полгода пользователей стало больше, появились запросы на теги, шаринг, офлайн. Изменение одного Fragment'а ломает другие, потому что утилитарный класс сильно связан.

Я замерил последнюю задачу (добавить фильтр по тегам): с 4 часов стало 10. Изменение затронуло 8 файлов, 3 из которых были не связаны по смыслу, но переиспользовали сетевой callback.

Матрица решений: ① да (2,5×), ② да (были инциденты), ③ нет (оба разработчика понимали код), ④ да (офлайн-фича застряла), ⑤ нет (сборка норм).

Три «да» — я решил рефакторить. Но только сетевой и хранилище. Перешёл с сырых HTTP-запросов на Retrofit + Repository, выделил локальную БД. Слой UI изменил лишь точки вызова. Рефакторинг занял две недели, третья — серый релиз. Crash rate остался стабилен, скорость разработки последующих фич восстановилась примерно на 60%.

Если бы я решил переписать весь UI, это заняло бы ещё месяц и несло бы гораздо больше рисков.

Что после рефакторинга?

Многие думают, что рефакторинг — финиш. Нет. Без code review и принятых конвенций код вернётся в прежнее состояние через полгода. Маленькие команды могут обойтись без формальных ревью, но введите два правила в PR: изменения не более 400 строк и наличие хотя бы базового теста.

И ещё: не обещайте мгновенного ускорения после рефакторинга. Оставьте 1–2 итерации на адаптацию команды и регрессионное тестирование.

В завершение

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

Если вы сейчас колеблетесь из-за грязного кода, откройте историю коммитов и посчитайте реальные затраты. Если данные говорят, что болит — делайте локальный разрез. Если нет — продолжайте бежать.

PaxLee