Код-ревью Битрикс: как проверить изменения и принять работу

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

Что решает код-ревью на Битриксе и где его границы

Код-ревью на Битриксе отвечает на три практических вопроса. Первый: делает ли изменение то, что просили в задаче. Второй: не создаёт ли оно новых рисков — для безопасности, для совместимости с ядром и сторонними модулями, для дальнейшей поддержки. Третий: можно ли это выпускать сейчас или нужно вернуть автору на доработку.

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

Когда ревью особенно нужно:

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

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

Какие исходные данные нужны до старта ревью

Ревью начинается со сбора контекста. Без понимания задачи проверяющий оценивает стиль вместо смысла.

Минимальный пакет для небольшой доработки

• Постановка задачи: что должно измениться для пользователя или для бизнес-процесса.
• Критерии приёмки: по каким признакам мы поймём, что задача решена.
• Изменение в виде diff или отдельной ветки в системе контроля версий.
• Список затронутых компонентов, шаблонов, модулей и настроек.
• Описание тестового стенда, где изменение можно проверить без риска для рабочего сайта.
• Тестовые данные: учётные записи, товары, заказы, значения свойств, на которых проверяется сценарий.

Что делать, если данных нет

Если постановка задачи потерялась, а изменение уже написано, ревью всё равно возможно, но его результат будет слабее. В этом случае проверяющий восстанавливает ожидаемое поведение по коду и по логике сайта, а спорные места выносит отдельным списком вопросов автору. Такой список — тоже полезный артефакт: он показывает, где требования не зафиксированы и где решение принималось «по интуиции».

Отдельно уточните, кто владелец изменения. Если правку делал подрядчик, а ревью выполняет другая команда, заранее договоритесь о формате замечаний и о том, кто и в какие сроки их закрывает. О том, как выстроить такую работу, есть отдельный материал про то, Битрикс-разработчик в аренду — как организовать работу.

Как связать замечания с требованиями и проверками

Главная ценность ревью — не количество найденных придирок, а связь каждого замечания с конкретным требованием или правилом. Формулировка «так некрасиво» бесполезна: автор не знает, что менять. Формулировка «поле не проходит проверку на стороне сервера, поэтому в заказ можно записать произвольное значение» указывает на риск и способ проверки.

Рабочий формат комментария содержит четыре части:

• что именно не так и в каком месте изменения;
• почему это важно — к какому требованию, правилу или риску относится;
• что предлагается сделать;
• как проверить, что после правки проблема ушла.

Приоритеты замечаний

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

Если блокирующих замечаний нет, ревью завершается решением «можно выпускать». Это тоже результат, и его стоит зафиксировать, а не оставлять в переписке.

Безопасность, совместимость и поддержка: что смотреть в первую очередь

Эти три направления дают большинство серьёзных находок.

Безопасность

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

Разработчик стороннего решения отвечает за своё решение. Ревью не может гарантировать отсутствие уязвимостей во всём проекте. Поэтому в отчёте честнее указать, что проверено, а что осталось за границами проверки.

Совместимость

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

Поддержка

Код читают люди, чаще всего не его автор. Дублирование логики, «магические» значения без пояснений и отсутствие описания сложных мест замедляют следующие правки. Это не блокирующие замечания, но именно они определяют, сколько будет стоить следующая доработка.

Таблица: как выбрать формат ревью под задачу

Формат ревью зависит от риска и от объёма изменения. Ниже — ориентиры для типовых ситуаций.

Таблица помогает договориться о глубине проверки до её начала. Если ситуация не подходит ни под одну строку, ориентируйтесь на ближайшую по риску и добавьте свои критерии.

Как организовать процесс ревью в команде

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

Базовые правила, которые работают:

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

Ревью внутри команды и ревью силами подрядчика

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

Учебный пример: ревью доработки оформления заказа

Ниже — учебный пример. Компания, состав заказа и количество объектов условны, это не реальный проект.

Входные условия

Условный интернет-магазин на Битриксе. Задача: добавить в оформление заказа дополнительное поле «Комментарий к доставке» и передавать его значение в учётную систему. Изменение подготовил внешний исполнитель, оно лежит в отдельной ветке. Есть постановка задачи, критерии приёмки и тестовый стенд с копией каталога и несколькими тестовыми заказами.

Действия проверяющего

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

Найденные замечания

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

Наблюдаемый результат и проверка

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

Чек-лист ревью кода Битрикс

Этот список удобно прикладывать к каждой проверке. Он не заменяет постановку задачи, а дополняет её.

• Изменение соответствует постановке задачи и критериям приёмки.
• Diff обозримый: понятно, какие файлы и модули затронуты.
• Пользовательский ввод проверяется, а не принимается как есть.
• Права доступа учитываются: изменение не расширяет возможности лишним ролям.
• Ошибки внешних сервисов обрабатываются, данные не теряются молча.
• Вывод данных в письмах и на страницах не ломает разметку.
• Логика не продублирована без необходимости.
• Сложные места сопровождаются пояснением.
• Изменение не опирается на устаревшие механизмы платформы.
• Есть план возврата: как откатить изменение, если что-то пойдёт не так.
• Проверка выполнена на тестовом стенде на подготовленных данных.
• Замечания разделены на блокирующие, важные и улучшения.
• Решение о выпуске зафиксировано письменно.

Как проверить результат и принять работу

Приёмка — это отдельный шаг, и он не совпадает с ревью. Ревью отвечает на вопрос «можно ли выпускать», приёмка — на вопрос «работает ли это так, как нужно бизнесу».

Порядок действий:

• Сначала копия: изменение проверяется на тестовом стенде, максимально похожем на рабочий сайт.
• Затем резервирование: перед выпуском делается резервная копия того, что меняется.
• Потом тест по сценариям из критериев приёмки, включая неудачные варианты.
• И только затем выпуск, с готовым планом возврата.

Принимает работу тот, кто отвечает за процесс, а не только тот, кто писал код. В приёмке участвует владелец задачи: он подтверждает, что поведение сайта совпадает с ожиданием. Если критерии приёмки не зафиксированы заранее, их формулируют до выпуска, чтобы избежать споров.

Типичные ошибки и ограничения

Ошибки повторяются из проекта в проект.

• Ревью ради галочки: проверяющий смотрит только оформление и пропускает логику.
• Слишком крупное изменение: в большом diff теряются реальные проблемы.
• Нет критериев приёмки, поэтому непонятно, что считать успехом.
• Ревью после выпуска: замечания находятся, когда риск уже реализовался.
• Споры о стиле вместо разбора рисков.
• Проверка сразу на рабочем сайте, без копии и плана возврата.
• Уверенность, что ревью гарантирует отсутствие уязвимостей. Это не так: проверка всегда ограничена объёмом изменения и квалификацией проверяющего.

Ограничения стоит проговаривать заранее. Ревью не заменяет тестирование, не заменяет обновление платформы и не снимает ответственность с автора изменения.

Что подготовить для оценки и следующий шаг

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

Следующий шаг после ревью — не «исправить всё», а закрыть блокирующие замечания, выпустить изменение по плану и вернуться к важным замечаниям отдельной задачей. Если ревью выявило системные проблемы — устаревшие модули, отсутствие тестового стенда, размытые требования, — их разумно вынести в отдельный план работ, а не пытаться решить внутри одной правки.