Наследный проект на 1С-Битрикс редко выглядит как «аккуратный продукт». Чаще это слоеный пирог из правок разных лет: быстрые фиксы под акции, интеграции «на коленке», доработки в обход стандартов, десятки кастомных обработчиков, которые живут своей жизнью. В такой ситуации главная ошибка владельца бизнеса — просить «оценку по ТЗ» до того, как стало понятно, что у вас вообще лежит в основе сайта.
Ниже — практичный способ оценить состояние кода, собрать факты для сметы и сделать план доработок так, чтобы вы контролировали сроки, риски и результат, а не «верили в обещания».
Что такое «наследие» в Bitrix и почему оно затягивает сроки
Наследие — это не возраст проекта. Наследие — это отсутствие управляемости. Обычно оно проявляется так:
- Доработки раскиданы по /bitrix/php_interface/, /local/php_interface/, init.php и по компонентам без единой логики.
- Шаблоны компонентов переписаны «внутри» шаблона сайта, а правки в одной странице ломают другую.
- Интеграции с 1С/CRM/службами доставки работают, но никто не может объяснить, где именно логика обмена и кто за нее отвечает.
- Кэш включен «как попало»: где-то все летает, а где-то выключено, потому что «иначе не обновляется корзина».
- Модули и библиотеки обновлять страшно: после обновления «что-то обязательно сломается».
Если это похоже на ваш проект — оценка до аудита будет либо завышенной (под страховку), либо заниженной (под продажу). И оба варианта плохие: в первом вы переплатите, во втором получите бесконечные допработы.
Цель аудита перед доработкой
У аудита не должно быть цели «переписать все». Цель — перевести проект из режима «угадайка» в режим управляемости:
1) понять, где в коде живут бизнес-критичные сценарии (каталог, корзина, оплата, интеграции); 2) оценить риски изменений (что сломаем, если тронем); 3) получить измеримую базу для сметы: объем, приоритеты, зависимости, ограничения.
Быстрый скрининг за 60-90 минут: что можно понять без глубокого погружения
Даже короткий скрининг дает сигнал, насколько проект «тяжелый». Вот что проверяют в первую очередь:
- Версия PHP и Битрикс, режим обновлений, наличие «замороженных» модулей.
- Где живет кастом: /local/ или в /bitrix/ (если много кастома в /bitrix/, почти всегда будет боль).
- Наличие автозагрузки классов, использование неймспейсов, PSR-подхода (хотя бы частично).
- Количество обработчиков событий, агентов, кронов и их критичность.
- Режимы кэширования (компонентный кэш, managed cache, html cache) и «точки отключения».
- Интеграции: 1С, платежи, доставки, CRM, маркетплейсы — где код, где настройки, где логи.
- Логи ошибок (PHP error log), журнал событий Битрикс, состояние мониторинга.
Результат скрининга — не отчет «на 40 страниц», а список гипотез: что выглядит опасным и что надо вскрывать глубже.
Полный аудит кода: артефакты, которые реально помогают оценить работы
Чтобы смета была защищаемой, аудит должен закончиться артефактами. Минимальный набор:
1) Карта системы (System Map)
Короткая схема: фронт, админка, каталог, корзина, платежи, доставка, интеграции, поисковый модуль, импорт/экспорт, фоновые задачи. Для каждого блока: «где код», «где настройки», «кто владелец», «как проверяем».
2) Реестр кастома
Таблица, где перечислено:
- кастомные компоненты и шаблоны;
- обработчики событий (что слушают и что меняют);
- агенты/кроны (что делают и как часто);
- кастомные классы/сервисы;
- изменения ядра (если есть).
Без такого реестра вы не контролируете ни риски, ни обновления.
3) Матрица рисков изменений
Для каждой ключевой зоны: вероятность поломки и цена ошибки (время простоя, потеря заказов, потеря данных). Это помогает решать, где сначала писать тесты/обвязку, а где можно идти быстрее.
4) Дерево зависимостей
Список «если меняем А, затронем B и C». В Bitrix это особенно важно из-за событий, кэша и логики в шаблонах.
5) Набор репродьюсеров
Не «описание словами», а конкретные сценарии:
- как воспроизвести баг;
- на каких данных;
- какой ожидаемый результат;
- какие логи смотреть.
Если репродьюсера нет — оценка почти всегда будет ошибочной.
Как правильно оценивать доработку: не «часами», а пакетами неопределенности
Сильная оценка по доработке сайта на 1С-Битрикс строится не на «вере в разработчика», а на разложении работ по зонам и неопределенности.
Шаг 1. Разбиваем задачу на 3 слоя
1) Внешнее поведение: что видит пользователь/менеджер. 2) Бизнес-логика: правила, ограничения, интеграции. 3) Техслой: где именно в Bitrix это реализовано (компонент, событие, ORM, старый API, сторонний модуль).
Одна и та же «простая правка» на уровне UI может оказаться переписыванием цепочки событий в корзине. Пока вы не нашли место в техслое — оценка будет фантазией.
Шаг 2. Присваиваем каждой задаче класс риска
Практичная шкала:
- A (низкий риск): изолированная правка, понятная точка входа, есть репродьюсер.
- B (средний): затрагивает кэш/шаблоны/несколько компонентов, есть зависимость от данных.
- C (высокий): корзина/оплата/интеграции/права/фоновые задачи, много событий, нет тестов.
Для классов B и C корректная смета должна включать время на «вскрытие» и стабилизацию.
Шаг 3. Добавляем «работы по управляемости»
Если проект наследный, в смету нужно закладывать не только реализацию функции, но и меры, чтобы она не сломала сайт через неделю:
- логирование и понятные ошибки;
- защита от дублей заказов/платежей;
- контроль целостности данных;
- фича-флаги или безопасное включение по группам;
- мониторинг и метрики (хотя бы минимальные).
Это не «лишние хотелки», а страховка от простоя.
Типовые ловушки наследия в 1С-Битрикс
- Кастом внутри /bitrix/
Если разработчики правили ядро или штатные модули, обновления превращаются в лотерею. Правильная стратегия: вынести кастом в /local/, зафиксировать патчи и минимизировать прямые изменения ядра.
- «Логика в шаблоне»
Когда условия и расчеты живут в шаблонах компонентов, любое изменение дизайна становится изменением бизнес-логики. Это самая частая причина, почему «верстка» внезапно стоит как «разработка».
- События как «магия»
Событийная модель удобна, но в наследных проектах она превращается в непредсказуемый каскад: одно событие дергает другое, а точек входа десятки. Без реестра событий оценка всегда будет плавать.
- Интеграции без контрактов
Обмен с 1С/CRM часто держится на договоренностях уровня «так исторически сложилось». В результате:
нет схемы данных;
нет валидации;
нет повторной отправки/идемпотентности;
нет изоляции ошибок.
Доработка в таком месте требует сначала описать контракт, иначе «починили одно — сломали три».
- Кэш, который «то работает, то мешает»
Правильный подход: описать, какие страницы и блоки кэшируются, какие — нет, и по каким триггерам сбрасывается кэш. Иначе любая доработка в каталоге превращается в бесконечные «почему не обновилось».
Что просить у подрядчика до старта работ: конкретный список
Если хотите управлять проектом, просите не «красивые обещания», а результаты в формате артефактов.
1) План аудита: что смотрим, какие ограничения, какие выходные документы. 2) Реестр кастома и точки входа (с привязкой к репозиторию/файлам). 3) Матрица рисков + предложение по стратегии внедрения (поэтапно, с откатом). 4) Пакетная смета: задачи A/B/C с указанием, где есть неопределенность и как она будет снята. 5) План тестирования: что проверяем руками, что автоматизируем, какие контрольные сценарии. 6) План релизов: сколько релизов, как минимизируем простои, как откатываемся. 7) Минимальный SLA на период внедрения (реакция на критические баги).
Если подрядчик не может это дать — он не контролирует наследие, он просто «будет разбираться по ходу».
Как не утонуть: рабочая стратегия доработок на наследном Bitrix
Практика показывает, что лучше всего работает трехконтурный подход.
Контур 1. Стабилизация
Сначала — минимальные меры, чтобы сайт не падал от каждой правки:
- включить базовое логирование;
- собрать репродьюсеры критичных сценариев;
- закрыть «дыры» с дублями заказов/платежей;
- привести в порядок кэш в самых горячих местах.
Контур 2. Доработка функций
Делаем то, что приносит деньги и снижает ручной труд: корзина, оформление, фильтры, личный кабинет, интеграции. Но каждую задачу проводим через классы риска A/B/C и выпускаем поэтапно.
Контур 3. Погашение техдолга
Точечно: выносим логику из шаблонов, структурируем /local/, унифицируем сервисы, документируем интеграции. Это не «переписать все», а убрать причины, которые раздувают стоимость каждой следующей задачи.
Итог: какой результат считать хорошим
Хорошая доработка — это не «мы сделали новую кнопку». Хорошая доработка — когда вы понимаете:
- где находится логика ключевых сценариев;
- что будет затронуто при следующем изменении;
- сколько стоит задача и почему;
- какие риски у релиза и как вы их снижаете.
Если хотите, чтобы проект на 1С-Битрикс развивался без вечных авралов, начинайте не с хотелок, а с диагностики и управляемой сметы. Это дешевле, чем чинить последствия «быстрой» разработки на наследии.
