Всем привет! Сегодня поговорим о великом и могучем рефакторинге. Все его хотят, все его любят (в душе), но бизнес его не видит. И в этом корень 90% наших внутренних конфликтов.
Суровая правда:
Бизнесу в массе своей все равно, насколько ваш код элегантен. Его не волнуют хитрые паттерны, идеальная обработка ошибок или красота архитектуры. Его KPI - это фичи, которые приносят деньги.
«Сделаем сейчас костыль, а рефакторинг в следующем спринте»? А потом этот «следующий спринт» никогда не наступает. Знакомо?
Так когда же это «потом» наступает?
Рефакторинг нужно делать не когда «есть время», а когда система подает четкий сигнал SOS. Вот пара примеров, когда откладывать уже нельзя:
Пример 1:
Есть метод на 350 строк, который валидировал данные формы. Сначала он проверял email, потом пароль, потом адрес.. С каждой новой фичей в него добавлялось по 5-10 строк. В один день может придти понимание, что добавление валидации для номера телефона потребует изменений в 5 разных местах этого метода и сломает три существующих теста. Это и есть тот самый момент, когда дальнейшее наслаивание кода ведет в пропасть.
Пример 2:
Два независимых модуля
PaymentService и
NotificationService стали неявно зависеть друг от друга через цепочку вызовов в третьем -
UserManager. Чтобы добавить отправку пуш-уведомления об успешном платеже, пришлось лезть в ядро
UserManager, рискуя сломать логику авторизации. Архитектура кричала о необходимости выделить четкий слой коммуникации между сервисами.
Правило трех:
Не рефакторите при первом же несовершенстве, но если вы в третий раз сталкиваетесь с одной и той же проблемой кода, когда добавляете схожую функциональность - это важный сигнал. Пора менять абстракцию. Первый раз - напишите костыль. Второй раз - скопируйте его с болью в душе. Третий раз - остановитесь! Пора выносить общую логику.
Кто видит эти сигналы и что делать?
Чаще всего старшие разработчики или тимлид. Именно он должен обладать достаточной экспертизой и ответственностью, чтобы в момент «вспышки» сказать: «Ребята, стоп. Сейчас мы потратим 2 дня на рефакторинг, иначе через месяц будем тратить 2 недели на каждую новую фичу и тушить пожары».
Объяснить это бизнесу - это отдельный навык. Говорите не о «красивом коде», а о рисках и стоимости:
- «Без этого изменения мы не сможем реализовать запланированную фичу X в срок.».
- «Каждый новый баг в этом модуле сейчас стоит нам 2 дня исследования, а после рефакторинга - 2 часа.»
Вывод:
Многие проекты годами живут на стадии «и так сойдет». Но если вы хотите спать спокойно и не бояться каждого коммита, учитесь ловить моменты «вспышек». Это уже не про красоту, а про выживание кодовой базы.
