Удивительно, но прошлый пост про рефакторинг вызвал у вас бурю эмоций — и это здорово. Значит, тема живая и болит у многих. Читатели накидали вопросы и замечания, и я хочу на них честно ответить — без красивых обёрток и без позиции «разработчик всегда прав».

Про «рефакторинг на пустом месте»

Меня поправили насчёт фразы, что рефакторинг на пустом месте не рождается. Увы, рождается — и я сам не раз был его инициатором. Чаще всего это выглядит так: разработчику стыдно за какой-то кусок кода, или хочется попробовать новую технологию, и он начинает придумывать проблемы, натягивая сову на глобус. А потом бежит к менеджеру с горящими глазами и пеной у рта: «Нам срочно надо всё переделать!»

Знакомо? Тогда вы точно видели посты в духе «Как продать рефакторинг руководителю?». Я к ним отношусь скептически. Сама постановка задачи «продать» напоминает мне «Волка с Уолл‑стрит»: там тоже очень убедительно впаривали клиентам то, что им не нужно.

Если вы руководитель (даже не технический), вы и так знаете боли своего проекта: где теряются деньги, где самые большие затраты, где всё постоянно ломается. Вряд ли разработчик расскажет вам что-то новое про эти места. Вы и так понимаете, что хотите «купить». А вам пытаются продать совсем другое.

При этом я не отрицаю, что бывают реальные технические проблемы, на которые долго закрывали глаза. Но даже не будучи технарём, по паре фраз можно понять ценность доработки. Такой рефакторинг не нужно «продавать» — он сам себя продаёт.

Яркий пример: в посте про нашу стартовую точку я рассказывал, что наша кодовая база была написана на версии SDK, которую Apple отказывалась принимать в App Store уже через полгода. Это грозило полной остановкой релизов. Тут не нужно было придумывать тысячу аргументов: остановка релизов — это понятный и очень дорогой риск для бизнеса. Ресурсы на рефакторинг выделили без лишних вопросов. Если бы не выделили — я бы не стал упорно «продавать» эту задачу, а искал бы другой путь или вообще смирился с оценкой бизнеса.

Что делать, если поддержка фреймворка заканчивается, а новая версия — совсем другая?

Ещё меня спросили: «Что делаете, если заканчивается поддержка текущей версии фреймворка, а новая кардинально отличается: рефакторите или выбрасываете и пишете с нуля?»

Мой ответ простой (и я уже упоминал его раньше): в большинстве случаев мы… просто не обновляемся. Потому что «чтобы что»?

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

В нашем случае ситуацию дополнительно фиксирует специфика отрасли: есть Великий и Ужасный Регулятор, который жёстко ограничивает обновления публичных библиотек после определённой даты, которую нельзя называть. Хочешь обновиться? Нельзя. И знаете, я даже благодарен этому правилу: оно снимает огромное количество споров и бессмысленных хотелок разработчиков. Безопасность и стабильность тут важнее «красивого кода».

Рефакторинг MVP: переделывать или выбрасывать?

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

Честно? Сейчас я не готов уверенно встать на одну из сторон: плохо помню, кто и чем обосновывал эту идею, и хочу сначала сам для себя всё разложить по полочкам. Так что эту тему я отложу на отдельный пост — сделаю нормальную ретроспективу и расскажу, что же говорит теория. (Идея высказывается Ф.Бруксом в его ставшим уже классическим труде «Мифический человеки-месяц». Не читал, не осуждаю ☺️ ).