Содержание:

1. Как организовать Code Review в программе 1C:Предприятие
2. Как выбрать инструменты для работы в системе 1С
3. Как определить стандарты учетной системы 1С

В мире 1С-разработки, где часто один программист отвечает за целый блок задач, идея Code Review (обзора или инспекции кода) может показаться избыточной. Однако именно эта практика является одним из самых мощных инструментов для повышения качества продукта, развития команды и снижения долгосрочных затрат на поддержку. Это культурный сдвиг от «моего кода» к «нашему общему коду». Система 1С выигрывает от такого подхода на всех этапах сопровождения.

Как организовать Code Review в программе 1C:Предприятие

Зачем проводить Code Review в команде 1С?

• Обнаружение ошибок на ранней стадии. «Вторая пара глаз» часто замечает логические ошибки, опечатки или неучтенные сценарии, которые автор кода мог пропустить.
• Обмен знаниями. Младшие разработчики учатся у старших, видя их замечания и предложения. Старшие, в свою очередь, могут увидеть свежий подход к решению задачи.
• Соблюдение единых стандартов. Code Review — главный инструмент контроля за тем, чтобы все разработчики писали код в едином, понятном для всей команды стиле.
• Повышение отказоустойчивости команды. Когда код одного разработчика видели и поняли как минимум двое, уход в отпуск или увольнение ключевого сотрудника становится менее болезненным.
• Поиск лучших решений. Часто в ходе обсуждения рождается более оптимальный или элегантный алгоритм, чем был предложен изначально.

Для программы 1С такой процесс помогает поддерживать единый уровень качества разработки.

Как выбрать инструменты для работы в системе 1С

Для эффективного Code Review в 1С-разработке недостаточно просто посмотреть код через плечо коллеги. Нужен системный подход, основанный на современных инструментах.

• Система контроля версий Git. Это фундамент. Code Review проводится не в Конфигураторе, а в веб-интерфейсе систем вроде GitLab, GitHub, Gitea или Bitbucket. Процесс строится вокруг Pull Request или Merge Request — запроса на слияние изменений из ветки разработчика в основную ветку разработки.
• Инструменты для выгрузки конфигурации в текст. Git умеет работать только с текстовыми файлами. Чтобы выгрузить бинарную конфигурацию 1С в понятный для Git формат, используются утилиты, написанные на OneScript (например, precommit-1c). Они раскладывают всю структуру метаданных по папкам и файлам.
• Редактор кода с анализом «на лету». Visual Studio Code с расширением 1C (BSL) становится основным инструментом для написания и анализа кода. Он подсвечивает ошибки и несоответствия стандартам еще до того, как код будет отправлен на ревью.

Такой набор инструментов делает систему учета 1С удобнее для коллективной разработки.

Как определить стандарты учетной системы 1С

Чтобы Code Review не превращался в споры о вкусах («а мне больше нравятся табы, а не пробелы»), команда должна разработать и принять единый стандарт кодирования. Вот ключевые пункты, которые он должен описывать.

1. Именование:

• Переменные: осмысленные, в стиле CamelCase (например, СчетчикЦикла, НайденныйЭлемент). Никаких a, b, x для нетривиальных переменных.
• Процедуры и функции: глагол, отражающий действие (РассчитатьСуммуДокумента, СформироватьПечатнуюФорму).
• Параметры: должны четко отражать суть передаваемых данных (СсылкаНаДокумент, МассивСтрокТаблицы).
• Объекты метаданных: единый стиль. Например, все отчеты по продажам начинаются с префикса «Продажи_».

2. Форматирование:

• Отступы: использовать табуляцию или пробелы? Сколько? (Главное — единообразие.)
• Длина строки: ограничение, например, в 120 символов, чтобы избежать горизонтальной прокрутки.
• Пробелы вокруг операторов: А = Б + В; (с пробелами) выглядит читаемее, чем А=Б+В;.

3. Структура кода:

• Модульность: избегать процедур-«простыней» на 1000 строк. Сложную логику разбивать на небольшие, понятные функции, каждая из которых решает одну подзадачу.
• Комментарии: комментировать не что делает код (это должно быть видно из его названия), а почему он делает это именно так, если логика неочевидна.
• Обработка ошибок: обязательное использование конструкций Попытка … Исключение … КонецПопытки при работе с внешними компонентами, файлами, COM-объектами.

4. Язык запросов:

• Никогда не использовать ВЫБРАТЬ *.
• Всегда перечислять только необходимые поля.
• Использовать осмысленные псевдонимы для таблиц и полей.
• Не использовать запросы в цикле.

Учетная система 1С становится проще в сопровождении при соблюдении единых стандартов.

Как выглядит процесс на практике?

• Задача: разработчик получает задачу и создает под нее отдельную ветку в Git (feature/add-new-report).
• Разработка: он пишет код, используя VS Code для анализа и Конфигуратор для визуальной части и отладки.
• Коммиты: периодически сохраняет свои изменения в локальную ветку (делает коммиты).
• Pull Request: когда задача готова, он отправляет свою ветку на сервер Git и создает Pull Request (или Merge Request) в основную ветку develop. В описании он кратко излагает суть изменений.
• Ревью: другой разработчик (ревьюер) получает уведомление. Он открывает Pull Request в веб-интерфейсе GitLab, GitHub, Gitea или Bitbucket, видит все изменения и может оставлять комментарии к любой строке кода.
• Обсуждение и доработка: автор видит комментарии, отвечает на них или вносит исправления и отправляет новые коммиты в свою ветку.
• Утверждение и слияние: когда все замечания устранены, ревьюер одобряет Pull Request. После этого изменения вливаются в основную ветку.

Программа 1C:Предприятие хорошо интегрируется с таким процессом командной разработки.

Внедрение Code Review — это не однодневный процесс, а инвестиция в зрелость команды и стабильность продукта. Он требует дисциплины, открытости к критике и наличия четких стандартов. Но результат — чистый, предсказуемый и легко поддерживаемый код — многократно окупает все затраченные усилия. Система 1C:Предприятие в сочетании с практикой Code Review помогает сделать разработку более надежной, прозрачной и управляемой.

Специалист компании ООО “Кодерлайн”,

Радченко Степан