Переписывать или чинить: 3 вопроса, которые закрывают спор

Каждый раз, когда я открываю чужой (или свой годовалой давности) проект, рука тянется сказать: «да тут проще переписать с нуля».

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

1. Что именно болит — код или моё к нему отношение? Если код просто «некрасивый», «не модный», «не на том фреймворке» — это не повод. Это повод сходить выспаться. Если болит конкретно, например, падает прод, на правку одной строки уходит 4 часа, новый разработчик уходит после недели онбординга — есть предмет разговора. Правило: одно конкретное измеримое «больно» = можно обсуждать. Эстетика = нет.

2. Какой процент логики мы реально хотим оставить? Если бо́льшая часть бизнес-логики остаётся как есть, а боль в архитектуре, слое данных или фронте — это рефакторинг, иногда жёсткий, но рефакторинг. Если меняется сам домен, бизнес-модель, ядро — да, перепись, потому что код заточен под старую модель и будет ей сопротивляться. Моя личная эвристика (не наука): если оставляем меньше трети логики — перепись честнее, чем мучить рефакторингом.

3. Готов ли бизнес 2–6 месяцев платить за то, что снаружи ничего не меняется? Главный вопрос, и его всегда задают последним. Перепись — это пауза в новых фичах. Конкуренты не паузят. Клиенты не паузят. Если у бизнеса нет такого окна — придётся чинить, как бы ни хотелось переписать.

Алгоритм: Болит конкретно + меняется ядро + бизнес даёт окно, то переписывать. В остальных случаях — чинить и рефакторить.