Монитор качества Битрикс: как пройти проверку перед сдачей проекта

Зачем нужен монитор качества

1С-Битрикс — продукт с глубокими настройками: легко упустить домен в многосайтовой схеме, забыть почту тестового контура или оставить редактору слишком много прав. Монитор качества в административном разделе собирает типовые пункты приёмки и помогает до дедлайна найти «дыры»: от мелочей в шапке шаблона до политики доступа к инфоблокам.

Это не замена ТЗ и не гарантия идеального кода — инструмент задаёт рамку «как обычно делают перед сдачей» и экономит время заказчику и интегратору на согласовании.

Как с ним работать

Разумный порядок: сначала пройти блоки, которые влияют на всё остальное — настройки сайтов, шаблоны и права; затем контентные модели (инфоблоки, формы); потом компонентный слой и производительность; в конце — хостинг, резервы, юридические тексты и документация. Для каждого теста можно оставить комментарий: что сделано, что намеренно пропущено по договорённости, ссылка на тикет.

Если проверка автоматизирована и алгоритм не видит файлы в каталоге /local/, типичный совет от вендора — вручную пройти пункты и пометить результат с пояснением, что шаблон лежит в local/templates.

Интеграция дизайна и публичная часть

В блоке про дизайн проверяют, что у каждого сайта осмысленное имя, удалены тестовые домены, согласованы язык и форматы даты, а «URL сервера» и почта отправителя совпадают с ТЗ. Шаблонам нужны человекочитаемые названия, в начале разметки корректная декларация типа документа и язык документа из настроек сайта.

Ожидается, что заголовок страницы и типовые мета-теги выводятся через API приложения (например, $APPLICATION->ShowTitle(), ShowHead()), подключена административная панель ShowPanel(), а «сложная» вёрстка сосредоточена в обрамлении шаблона, а в рабочей области остаётся то, что редактор не сломает из визуального редактора. Имеет смысл заранее описать стили визуального редактора, сниппеты и шаблоны типовых страниц — это снижает количество правок после сдачи.

• Типам меню и свойствам страниц/разделов — говорящие имена; для навигации и карты сайта по возможности стандартные компоненты вроде bitrix:menu, bitrix:breadcrumb, bitrix:main.map.
• Технология «Эрмитаж»: правка контента и параметров компонентов из публичной части должна быть доступна там, где это заложено в проекте.
• Группа контент-редакторов настраивается отдельно: достаточно прав на контент, но не на критичные системные разделы.

Инфоблоки и формы

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

Модули и компоненты

Настройки задействованных модулей (главный модуль, почта, регистрация, сроки хранения событий журнала и т.д.) сверяют с задачами проекта. Для компонентов смотрят на режим кеширования: «Авто + Управляемое» или «Авто» предпочтительнее полного отключения. Кастомные компоненты оценивают так же, как стандартные: есть ли настройки в публичной части, не торчат ли необработанные параметры с дефолтными названиями из демо.

Безопасность и производительность

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

Хостинг и сдача

Ожидается соответствие системным требованиям, доступ к резервному копированию и обновлениям, понятная схема окружений (тест/боевой). К сдаче относятся лицензионные соглашения, политика конфиденциальности при сборе данных, инструкции для администратора и контента, а также описание нестандартных решений из ТЗ.

Практические замечания

Страница полной HTML-карты не всегда нужна с точки зрения дизайна: если в проекте её нет по требованиям, тест по компоненту карты часто помечают как пропущенный с объяснением. Аналогично комментируют осознанные отступления, согласованные с заказчиком.

Итог

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