Есть такие проекты, в которые страшно заходить в код.
Открываешь файлы — и чувствуешь, как внутри умирает маленький разработчик.
Логика размазана по шаблонам.
Функции по 500 строк.
Комментарии в стиле «ничего не трогать, работает».
Обновления ядра переносят через перекрестное знамение.
Владелец бизнеса в этот момент говорит:
«Нам бы тут чуть-чуть доработать… только аккуратно, чтобы всё не развалилось».
И вот главный вопрос: допатчить ещё одну «мелочь» или уже признать, что проще переписать часть проекта нормально?
Давайте разберусь, как я принимаю такие решения на живых Битрикс-сайтах, а не в учебных примерах.
Как выглядит проект, который «проще не трогать»
Если у вас совпадает хотя бы половина — да, вы про свой сайт читаете.
- Любая правка — как русская рулетка.
Поправили текст — отвалился фильтр. Добавили поле — перестала работать корзина. - Никто не хочет брать проект.
Одни говорят «дорого», другие «это вообще надо переписывать», третьи пропадают после первого ознакомления. - Обновлять страшно.
Версии PHP старые, обновления 1С-Битрикс не ставили годами, потому что «а вдруг всё рухнет». - Код — музей костылей.
Правки ядра, копипаста, функции с названиями new_new_function_2, «временные решения» трёхлетней давности. - Любая задача превращается в «ну… минимум 20 часов», даже если речь про вроде бы простую штуку.
Если вы всё это терпите годами — вы не экономите, вы просто платите налог на технический долг.
Почему так вообще случилось
Не потому что «Битрикс плохой».
А потому что:
- проект собирали в режиме «надо вчера, денег мало, потом приведём в порядок»;
- менялись подрядчики, каждый делал по-своему, никто не отвечал за целостность;
- бизнес рос, требования росли, а фундамент никто не укреплял;
- любые доработки делали точечно, без пересмотра архитектуры.
В результате сайт как дом, к которому по чуть-чуть пристраивали комнаты, балконы, сараи, и всё это держится на удаче и одной несчастной несущей стене.
Когда ещё можно «жить на доработках»
Иногда переписывать пока рано.
Я смотрю на проект и задаю себе несколько вопросов:
- Что сейчас реально болит бизнесу?
Прямо болит — заявки, деньги, критичные процессы. А не «когда-нибудь пригодится». - Как часто приходится вносить изменения?
Если доработки 1–2 раза в год — один подход. Если вы живёте на постоянных релизах — совсем другой. - Сколько стоит очередная «мелкая правка» — по времени и нервам?
Если каждый раз это маленькая операция на открытом сердце, это тревожный звоночек.
Когда оставаться на доработках ещё имеет смысл:
- сайт в целом стабилен, падает не каждый месяц;
- доработки редкие и небольшие;
- планов на агрессивный рост функционала нет;
- вы объективно не готовы сейчас инвестировать в большой пересмотр.
Тогда я честно говорю:
окей, делаем точечный ремонт, но без иллюзий — тут не строится будущее на 5 лет вперёд.
Когда выгоднее переписать отдельные модули
Не весь сайт целиком, а конкретные куски. Такое решение я предлагаю, когда:
- Есть один «адский узел», который ломается постоянно.
Например: оформление заказа, интеграция с 1С, расчёт доставки. Остальное живёт терпимо. - Этот узел тормозит развитие всего проекта.
Любая новая фича цепляется за него, а он — сплошной хаос. - Править старое уже дороже, чем собрать новый модуль рядом.
Когда разработчику нужно 10 часов, чтобы понять, как вообще устроено, и ещё 10 — чтобы аккуратно подкрутить.
Что я делаю в таких случаях:
- выделяю проблемный кусок: функционально и технически;
- описываю, что он должен делать на человеческом языке (без «так исторически сложилось»);
- проектирую новый модуль/компоненты с чистым кодом, нормальными настройками, документацией;
- аккуратно переключаю трафик: сначала тестовый стенд, потом ограниченная часть пользователей, потом все.
В итоге у вас получается гибрид: старый проект, внутри которого появляются островки нормальной архитектуры. И уже от них можно планомерно очищать остальной хаос.
Когда пора признавать: «рефакторинг, а не ещё один костыль»
Вот здесь начинается самое интересное. Я обычно говорю «нам нужен рефакторинг», если:
- Любая задача по срокам = «неизвестно».
Потому что никто не знает, что где выстрелит. - Новые разработчики не могут въехать в проект за разумное время.
Если человеку с опытом нужно 2–3 недели, чтобы просто перестать теряться — это уже диагноз. - Баги лезут даже там, где никто ничего не трогал.
Откатили одно, сломалось другое. Это признак того, что система уже вразнос. - Техдолг дороже фич.
Вы платите не за развитие, а за поддержание «чтобы хоть не падало».
В этот момент честнее сесть и сказать:
«Окей, нам нужно перебрать фундамент, а не красить фасад каждый месяц».
Как это выглядит на практике:
- Определяем критичные зоны: что приносит деньги (продажа, заявки, интеграции), а что просто «для красоты».
- Начинаем с ядра:
протягиваем нормальные сущности, выносим бизнес-логику из шаблонов в понятные классы/модули. - Параллельно выкидываем самый дикий legacy: правки ядра, дублирующийся код, мёртвые ветки.
Да, это уже не «пара часов правок».
Но и результат другой: проект перестаёт быть миной замедленного действия.
«Переписать всё с нуля» — почти всегда плохая идея
Иногда приходят с фразой:
«Слушай, давай просто всё снесём и напишем новый сайт, сколько можно мучиться».
Звучит красиво, но на практике:
- вы теряете все накопленные интеграции и нюансы бизнес-процессов;
- параллельно приходится поддерживать старый сайт, пока новый дописывают;
- сроки и бюджет растут, потому что «по ходу дела решили ещё кое-что улучшить».
Полный перепис — это крайний вариант. Я рассматриваю его, только если:
- текущий проект реально невозможно безопасно развивать: всё завязано на правки ядра, старые версии, сервер из 2010-х и т.д.;
- бизнес-процесс сильно изменился, и старую схему проще выкинуть, чем ломать под новые реалии;
- вы готовы жить какое-то время в режиме «старый сайт + новый сайт параллельно» и честно вкладываться в это.
Во всех остальных случаях выгоднее идти эволюцией:
фокусно переписывать куски, вычищать техдолг и постепенно приводить проект в состояние, когда его не страшно трогать.
Как я подхожу к таким «тяжёлым» проектам
Я не бегу сразу переписывать всё подряд. Сначала я:
- Делаю технический аудит.
Смотрю архитектуру, модули, интеграции, качество кода, версии PHP/Битрикс, окружение. - Перевожу это на язык бизнеса.
Не «у вас тут DI и SOLID страдают», а:
- где вы теряете деньги;
- где высокие риски падения;
- где правки стоят дороже, чем должны.
3. Рисую карту действий.
Прямо по уровням:
- что сделать срочно, чтобы сайт перестал жить в режиме «на волоске»;
- что делать поэтапно: какие части кода/модулей выгодно переписать;
- от чего пока можно отказаться, потому что это не даёт никакого выхлопа.
4. И только потом решаю с клиентом:
где мы чуть дорабатываем, где переписываем кусок, а где закладываем планомерный рефакторинг.
Если сейчас любая правка на вашем Битрикс-сайте вызывает мысль «только бы не сломать», это не «особенность платформы».
Это просто накопившийся техдолг, который либо вы контролируете, либо он контролирует вас.
Главное — перестать делать вид, что «ещё одна маленькая доработка» чудесным образом решит проблему, которая годами строилась на костылях.