Как вы решаете, когда рефакторить, а когда переписывать систему с нуля?

Question

Accepted Answer

По умолчанию — **рефакторинг**. Переписывание оправдано только тогда, когда существующая система больше не может развиваться под требования при приемлемой стоимости, и вы можете продолжать доставлять ценность по ходу. Большинство порывов «нам нужен rewrite» на деле — неуправляемая проблема tech debt, которую инкрементальный рефакторинг решает с куда меньшим риском.

## Как я об этом рассуждаю

- **Жизнеспособна ли всё ещё ядровая архитектура?** Если модель данных, границы и среда выполнения растягиваются под новые требования — рефакторим. Если фундаментальные допущения неверны (неправильная парадигма хранения, нет способа масштабироваться, конец жизни языка/платформы), rewrite становится реальным кандидатом.
- **Какова частота изменений?** Код, который редко меняется, не должен быть красивым. Концентрируйте усилия там, где команда работает ежедневно.
- **Понимаем ли мы текущее поведение?** Rewrite выбрасывает годы закодированного знания о краевых случаях. Если нет ни тестов, ни спецификации, rewrite заново внесёт старые баги.

## Фреймворк решения

| Сигнал | Склонять к рефакторингу | Склонять к rewrite |
| --- | --- | --- |
| Архитектура соответствует требованиям | Да | Нет |
| Покрытие тестами/спецификацией | Низкое или высокое | Достаточное, чтобы проверить паритет |
| Можно выпускать инкрементально | Да | Тяжело, big-bang |
| Команда понимает код | Да | Нет, и оригинальные авторы ушли |

## Компромиссы

- **Рефакторинг:** ниже риск, непрерывная доставка, но медленно на по-настоящему гнилом фундаменте.
- **Rewrite:** чистый лист, но вы платите **налог заморозки фич**, несёте **стоимость двойной поддержки** и рискуете классической ловушкой переусложнения второй системы.
- Предпочитайте срединный путь **strangler-fig**: поднимаете новую систему рядом со старой, перенаправляете трафик инкрементально, удаляете старое по кусочку. Это даёт выгоды rewrite при риске уровня рефакторинга.

## Подводные камни

- Переписывать ради **эстетики или резюме**, а не бизнес-стоимости.
- Недооценивать скрытое поведение; всегда сначала характеризуйте текущее поведение тестами.
- Многоквартальный big-bang rewrite, который ничего не выпускает, — и импульс, и доверие рушатся.

## Почему это важно

Выбор «рефакторинг или rewrite» — одно из самых высокорычажных решений Tech Lead. Ошибитесь в сторону rewrite — и можете заморозить доставку на год и всё равно провалиться; ошибитесь в сторону рефакторинга — и медленно теряете скорость. Подача этого как решения о стоимости и риске, а не о вкусе, — то, что отличает senior-суждение от предпочтения.

Сигнал	Склонять к рефакторингу	Склонять к rewrite
Архитектура соответствует требованиям	Да	Нет
Покрытие тестами/спецификацией	Низкое или высокое	Достаточное, чтобы проверить паритет
Можно выпускать инкрементально	Да	Тяжело, big-bang
Команда понимает код	Да	Нет, и оригинальные авторы ушли