Сопровождение или рефакторинг: когда постоянные мелкие правки уже невыгодны

Порог технического долга, повторяющиеся регрессии, стоимость каждой новой правки и ограничения архитектуры.

Старый сайт не обязательно выбрасывать. Иногда выгоднее сохранить URL, данные и работающие интеграции, меняя проблемные слои постепенно. В других случаях чистая миграция дешевле спасения legacy.

На что смотреть, кроме цены

Рефакторинг я бы начинал с инвентаризации: что уже работает, откуда приходит трафик, какие интеграции завязаны на старый код и какие изменения стали дорогими.

• Разделить быстрые фиксы, рефакторинг и переписывание.
• Менять небольшими этапами с тестами.
• Разделить косметические и архитектурные проблемы.
• Зафиксировать симптомы человеческим языком.

Когда достаточно простого решения

Простой вариант нормален, когда задача локальная, зависимости понятны и результат можно проверить одним-двумя сценариями. Не каждая проблема требует нового сайта или большой переделки.

Когда нужен системный вариант

Более глубокая работа нужна, когда дефект повторяется в шаблоне, затрагивает много URL, ограничивает SEO, рекламу, аналитику или делает каждую следующую правку непропорционально дорогой.

Рефакторинг нужен не ради красоты кода, а когда архитектура повышает стоимость изменений, вызывает регрессии, нагрузку или мешает бизнесу развивать продукт.

Что сильнее всего влияет на стоимость и срок

• переписывать без измеримой проблемы
• править production без staging
• менять URL без SEO-карты
• проверять после релиза только главную

Самая дорогая ошибка — начать с полного переписывания, не сохранив URL, аналитику, формы, данные и рабочие сценарии.

Как бы я принимал решение

Я бы сравнивал варианты по тому, что именно изменится, как это проверят и что останется управляемым после завершения работ.

• PHP/JS ошибки
• нагрузка
• время типовой правки
• частота регрессий