Добавить в корзинуПозвонить
Найти в Дзене

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

Каждый раз, когда я открываю чужой (или свой годовалой давности) проект, рука тянется сказать: «да тут проще переписать с нуля». Это почти всегда ловушка. Перепись — это месяцы без новых фич, риск всё сломать и потеря того опыта, что уже зашит в код в виде багфиксов и костылей, про которые ты уже не помнишь, зачем они там. Но иногда переписывать действительно надо. Чтобы не угадывать, я гоняю задачу через 3 вопроса. 1. Что именно болит — код или моё к нему отношение? Если код просто «некрасивый», «не модный», «не на том фреймворке» — это не повод. Это повод сходить выспаться. Если болит конкретно, например, падает прод, на правку одной строки уходит 4 часа, новый разработчик уходит после недели онбординга — есть предмет разговора. Правило: одно конкретное измеримое «больно» = можно обсуждать. Эстетика = нет. 2. Какой процент логики мы реально хотим оставить? Если бо́льшая часть бизнес-логики остаётся как есть, а боль в архитектуре, слое данных или фронте — это рефакторинг, иногда жё

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

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

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

Но иногда переписывать действительно надо. Чтобы не угадывать, я гоняю задачу через 3 вопроса.

1. Что именно болит — код или моё к нему отношение?

Если код просто «некрасивый», «не модный», «не на том фреймворке» — это не повод. Это повод сходить выспаться. Если болит конкретно, например, падает прод, на правку одной строки уходит 4 часа, новый разработчик уходит после недели онбординга — есть предмет разговора.

Правило: одно конкретное измеримое «больно» = можно обсуждать. Эстетика = нет.

2. Какой процент логики мы реально хотим оставить?

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

Моя личная эвристика (не наука): если оставляем меньше трети логики — перепись честнее, чем мучить рефакторингом.

3. Готов ли бизнес 2–6 месяцев платить за то, что снаружи ничего не меняется?

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

Алгоритм:

Болит конкретно + меняется ядро + бизнес даёт окно, то переписывать.

В остальных случаях — чинить и рефакторить.