Код-ревью 1С:Бухгалтерии перед merge в Git: регламент

📅 Опубликовано 11 августа 2026 г.

Коротко: Регламент код-ревью доработок 1С:Бухгалтерии — это документ на 2–3 страницы, который фиксирует четыре вещи: что обязано быть в pull request, кто и за какой срок его смотрит, по какому чек-листу и при каких условиях ветка попадает в основную. Рабочий минимум — критерии готовности PR, чек-лист по ключевым зонам риска, зафиксированный срок ответа ревьюера и правило «двух глаз» на любые изменения типовых объектов конфигурации.

Ревью нужно не «для качества вообще», а для обновляемости: каждое изменение типового модуля 1С:Бухгалтерии — это будущая ручная работа при обновлении релиза. Ревьюер прежде всего спрашивает: можно ли то же самое сделать расширением?
Регламент без SLA не работает. Если срок реакции ревьюера не зафиксирован, PR висят днями, разработчик уходит на другую задачу, ветки расходятся, и merge превращается в разбор конфликтов.
Чек-лист важнее опыта ревьюера. Формализованный список из 15 пунктов даёт воспроизводимый результат даже у разных проверяющих; «посмотри, там вроде нормально» — не даёт.
Отдельная ветка правил для хотфиксов обязательна. Без неё регламент нарушают в первый же критичный день закрытия периода — и дальше не соблюдают никогда.
Экономика простая: ревью занимает заметную часть времени разработки задачи; если оно предотвращает хотя бы одну ошибку в регламентированном учёте за квартал, оно окупается за счёт несделанных перепроведений и корректировок отчётности.

Зачем код-ревью доработок 1С:Бухгалтерии, если есть тестирование?

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

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

Вторая причина — цена ошибки в учётном контуре. Доработка, которая некорректно формирует движения по счетам или меняет условия отбора в регистре, не падает с ошибкой. Она тихо формирует неправильные проводки, и обнаруживается это на закрытии месяца или, хуже, при сверке с ФНС. Мы подробно разбирали такие сценарии в материале про типичные ошибки закрытия месяца — существенная их часть родом не из бухгалтерии, а из непроверенных доработок.

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

Почему конфигурацию 1С держат в Git и что именно попадает в ревью?

Классическая схема с хранилищем конфигурации (Конфигурация → Хранилище конфигурации → Захват объектов) решает задачу блокировки объектов, но плохо решает задачу параллельной работы: два разработчика не могут одновременно править один объект, а история изменений привязана к объектам, а не к задачам. Git даёт ветки под задачи, изолированную разработку, историю по смыслу и — главное для нашей темы — механизм pull request, где изменение можно обсудить до попадания в основную ветку.

Технически конфигурация выгружается в файлы (через 1С:EDT либо через выгрузку конфигурации в XML-файлы из конфигуратора), и уже эти файлы версионируются. В ревью попадают:

Расширения конфигурации — основной и самый желанный формат доработок 1С:Бухгалтерии;
Изменения снятых с поддержки объектов — самая опасная категория, требует усиленного контроля;
Внешние обработки и отчёты, подключаемые через справочник «Дополнительные отчёты и обработки»;
Правила обмена и настройки синхронизации с другими базами;
Печатные формы, макеты, дополнительные реквизиты и сведения.

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

Что должно быть в pull request, чтобы его вообще взяли в ревью?

Первый раздел регламента — критерии готовности (Definition of Ready). Их смысл в том, чтобы ревьюер не тратил время на возврат заведомо неготовых изменений. Если хотя бы один пункт не выполнен, PR возвращается автору без содержательной проверки — это должно быть прямо написано в документе.

Ссылка на задачу в трекере или на пункт ТЗ. Без номера задачи PR не принимается.
Описание в теле PR: что меняется с точки зрения бухгалтера, а не разработчика. Формат «Раньше при проведении документа X … Теперь …».
Список затронутых объектов метаданных с явной пометкой, какие из них типовые.
Обоснование, если правится типовой объект: почему задача не решается расширением.
Сценарий проверки — последовательность действий в интерфейсе с ожидаемым результатом (какой документ создать, какие реквизиты заполнить, что должно получиться в отчёте).
Скриншоты «до/после» для любых изменений интерфейса и печатных форм.
Отметка о влиянии на закрытие периода и регламентированную отчётность — да/нет, с пояснением.
Ветка собрана и конфигурация открывается без ошибок, синтаксический контроль пройден.

Шаблон регламента код-ревью перед merge: готовые формулировки

Ниже — структура документа, которую можно скопировать и адаптировать. Держите её короткой: регламент длиннее трёх страниц не читают.

1. Область действия

«Настоящий регламент распространяется на все изменения конфигурации 1С:Бухгалтерия предприятия 3.0, расширений, внешних обработок и правил обмена, попадающие в репозиторий buh-main. Изменения, не прошедшие ревью, в основную ветку не принимаются. Настройки, выполняемые в режиме «1С:Предприятие» без изменения метаданных, под регламент не подпадают.»

2. Роли и ответственность

Автор — готовит PR по критериям готовности, отвечает на замечания, вносит правки.
Ревьюер — технический специалист, не участвовавший в разработке. Проверяет по чек-листу, ставит статус «принято» / «требуются правки».
Функциональный согласующий — главный бухгалтер или методолог. Требуется для изменений, влияющих на проводки, налоги и отчётность. Подтверждает бизнес-корректность, а не код.
Владелец репозитория — выполняет merge, следит за соблюдением регламента, ведёт реестр исключений.

3. Требования к ветке и коммитам

«Имя ветки: feature/BUH-123-kratkoe-opisanie или hotfix/BUH-456-.... Один PR — одна задача. Объём изменений в одном PR ограничивается так, чтобы его можно было прочитать за один заход; при превышении задача разбивается. Коммит-сообщение начинается с номера задачи.»

4. Сроки (SLA ревью)

Без сроков регламент мёртв. Минимально достаточная таблица:

Тип изменения	Срок первой реакции	Кто согласует
Расширение, не влияет на проводки	1 рабочий день	1 ревьюер
Изменение типового объекта	1 рабочий день	2 ревьюера
Влияет на проводки, налоги, отчётность	2 рабочих дня	Ревьюер + главбух
Правила обмена, синхронизация	2 рабочих дня	Ревьюер + владелец смежной базы
Хотфикс продуктива	В день обращения	Ревьюер, ретро-ревью в согласованный срок

Если вы работаете с внешним подрядчиком, эти сроки логично вынести в договорное приложение — механика та же, что и в соглашении об уровне сервиса с подрядчиком 1С: измеримый срок, зона ответственности, последствия нарушения.

5. Правила merge

Merge выполняет не автор изменения.
Обязательны: минимум одно одобрение, закрытые обсуждения, отсутствие конфликтов, зелёная сборка.
Прямые коммиты в основную ветку запрещены технически, а не «на словах» — через защиту ветки в Git-платформе.
После merge автор проверяет результат на тестовом контуре и закрывает задачу.

6. Исключения и хотфиксы

«В случае остановки критичного процесса (невозможность провести документы, сдать отчётность, отгрузить товар) допускается сокращённая процедура: одно устное согласование с владельцем репозитория, немедленный merge, оформление PR и полноценное ревью — в течение 3 рабочих дней. Каждый случай фиксируется в реестре исключений с указанием причины.» Реестр — важнее самого исключения: если за месяц в нём десять записей, проблема не в регламенте, а в качестве планирования.

7. Работа с распределённой командой

Если разработчики на удалёнке или это фрилансеры, добавьте раздел про доступы, часовые пояса и каналы коммуникации. Здесь удобно опереться на уже готовые формулировки из регламента удалённой работы с 1С — про доступ к базам, копии данных и запрет выгрузки боевых баз на личные устройства.

Что проверять: чек-лист ревьюера доработки 1С:Бухгалтерии

Чек-лист — сердце регламента. Он должен быть коротким настолько, чтобы им реально пользовались. Группируем по зонам риска.

Обновляемость (главный блок для типовой конфигурации)

Задача решена расширением? Если нет — есть ли письменное обоснование?
Если правится типовой модуль — изменения локализованы и помечены комментарием с номером задачи?
Использованы ли программные точки расширения (подписки на события, механизмы дополнительных реквизитов, дополнительные обработчики), а не копирование типовых процедур целиком?
Не дублируется ли типовой функционал, который уже есть в конфигурации в настройках?

Корректность учётных данных

Меняются ли движения по регистрам бухгалтерии и накопления? Приложен ли пример проводок до/после?
Учтена ли многофирменность, обособленные подразделения, разные системы налогообложения?
Корректно ли обрабатываются даты и границы периодов (закрытый период, дата запрета редактирования)?
Что происходит при перепроведении и при отмене проведения документа?

Производительность и данные

Нет ли запросов в цикле и обращений к базе внутри обработки каждой строки?
Нет ли соединений с виртуальными таблицами и подзапросами в условиях соединения?
Корректно ли обрабатываются пустые значения — через ЕСТЬNULL, а не через сравнение с пустой ссылкой постфактум?
Оценён ли объём данных: доработка тестировалась на копии боевой базы или на пустой?

Права, интерфейс, документация

Не расширяются ли молча права пользователей; учтены ли роли и профили групп доступа?
Понятны ли тексты сообщений пользователю: сообщение вида «Ошибка выполнения» — повод вернуть PR.
Есть ли краткая инструкция для бухгалтера и запись в журнале доработок с описанием отката?

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

ВЫБРАТЬ
    ХозрасчетныйОстатки.Субконто1 КАК Контрагент,
    ЕСТЬNULL(ХозрасчетныйОстатки.СуммаОстатокДт, 0) КАК Долг
ИЗ
    РегистрБухгалтерии.Хозрасчетный.Остатки(&ДатаОстатков, Счет = &Счет62) КАК ХозрасчетныйОстатки

Здесь важны две вещи: параметр периода передан явно, а пустые суммы обёрнуты в ЕСТЬNULL. Отсутствие любого из этих элементов — типовое замечание ревью, которое стоит бухгалтерии либо неверных цифр в отчёте, либо получасового ожидания его формирования.

Найдите специалиста для решения этой задачи на koderion.ru