АПК 1С — «1С:Автоматизированная проверка конфигураций» — это отдельная конфигурация от фирмы «1С», которая проверяет ваше прикладное решение на соответствие стандартам разработки и техническим требованиям. Работа с ней сводится к трём шагам: описать проверяемую конфигурацию и набор требований, запустить проверку, разобрать отчёт об ошибках. АПК используется и для сертификации «1С:Совместимо», и как регулярный инструмент контроля качества кода в команде.
Ниже — порядок работы с АПК редакции 1.2: какие настройки действительно нужны, как не утонуть в тысячах замечаний на типовой конфигурации и как встроить проверку в процесс разработки.
Зачем нужна автоматизированная проверка конфигураций
Встроенная в конфигуратор «Проверка конфигурации» ловит синтаксические ошибки, битые ссылки и часть логических проблем. Но она ничего не знает о стандартах: о том, что запрос в цикле — плохо, что у общего модуля неправильные флаги, что текст пользователю выводится без НСтр, что форма открывается без указания владельца.
АПК закрывает именно этот слой. Её требования основаны на системе стандартов и методик «1С», и после проверки вы получаете список нарушений с указанием объекта, места в модуле и требования, которое нарушено.
Где это полезно на практике:
- приёмка доработок от подрядчика — объективный список замечаний вместо спора «нормально написано или нет»;
- подготовка к сертификации «1С:Совместимо»;
- контроль качества в команде — регулярная проверка показывает, растёт ли технический долг;
- аудит чужой конфигурации — быстрый срез проблемных мест перед оценкой работ.
Шаг 1. Описываем проверяемую конфигурацию
Конфигурацию добавляют из раздела «Проверки» или из списка конфигураций в настройках. В карточке конфигурации несколько вкладок, по порядку важности:
| Вкладка | Что настраивается |
|---|---|
| Подключения | Путь к исполняемому файлу платформы и её версия, источник проверки, пользователь и пароль |
| Проверяемые требования | Набор требований и тип проверки: «Конфигурация» или «Библиотека» |
| Исключения из проверки | Отборы объектов, которые проверять не нужно |
| Библиотечные конфигурации | Встроенные библиотеки, например БСП |
| Расширения | Какие расширения проверять и в каком сценарии |
| Особенности и причины | Сознательно оставленные ошибки и справочник причин |
| Расписание | Регулярный автоматический запуск |
Источник проверки
Источником может быть файл конфигурации *.cf, выгрузка *.dt, хранилище конфигурации или файловая база. Серверную информационную базу напрямую указать нельзя — сохраните её конфигурацию в cf или подключите хранилище. После заполнения нажмите проверку подключения: ошибки пути к платформе и версии лучше поймать сразу.
Для командной разработки я подключаю хранилище: тогда АПК всегда проверяет актуальное состояние, и не нужно вручную выгружать cf перед каждым запуском.
Требования и тип проверки
Требования можно отметить вручную или выбрать готовый вариант проверки. Тип «Конфигурация» исключает подгруппу требований к разработке библиотек, даже если они отмечены. Тип «Библиотека» выбирают, когда вы разрабатываете библиотеку для встраивания в другие решения.
Для первой проверки большой доработанной конфигурации не включайте всё сразу. Начните с критичных групп — запросы, клиент-серверное взаимодействие, транзакции, безопасность, — иначе отчёт на десятки тысяч строк никто не прочитает.
Библиотеки и расширения
На вкладке «Библиотечные конфигурации» укажите встроенные библиотеки, в первую очередь БСП. Иначе АПК будет выдавать замечания по коду библиотеки, который вы не пишете и не правите.
На вкладке «Расширения» выбирается сценарий:
- Конфигурация (без расширений) — проверяется только основная конфигурация;
- Только расширения — проверяются отмеченные расширения;
- Конфигурация и расширения — и то и другое.
Если ваши доработки живут в расширениях поверх типовой, сценарий «Только расширения» — самый полезный: вы видите замечания именно к своему коду.
Шаг 2. Запускаем проверку
Выбираем конфигурацию и запускаем проверку в одном из режимов:
- Собрать данные и проверить — АПК заново считывает структуру конфигурации из источника. Нужен после любых изменений.
- Перепроверить по ранее собранным данным — быстрый повтор по уже считанной структуре, например после смены набора требований.
Настройки можно взять из карточки конфигурации или задать вручную для разового запуска. Время проверки зависит от размера конфигурации, числа требований и железа: небольшое расширение проверяется за минуты, крупное прикладное решение со всеми требованиями — часами. Для таких случаев удобна вкладка «Расписание»: проверка идёт ночью, утром готов отчёт.
Шаг 3. Разбираем отчёт об ошибках
Отчёт группирует ошибки по требованиям и объектам. С каждой ошибкой можно сделать одно из трёх:
- Исправить в конфигурации и отметить как исправленную.
- Перевести в особенность с указанием причины из справочника — например, «требование заказчика» или «унаследовано от типовой». Особенности не попадают в следующие отчёты.
- Оставить в работе и назначить ответственного.
Я рекомендую не переводить ошибки в особенности без обсуждения: это удобный способ спрятать проблему. Хорошая практика — согласованный список причин на уровне команды и периодический пересмотр особенностей.
Как встроить АПК в процесс разработки
Разовая проверка даёт снимок, регулярная — управляемый процесс. Рабочая схема выглядит так:
- проверка по расписанию по хранилищу или по выгрузке из ветки разработки;
- правило «нет новых критичных ошибок» перед сдачей задачи или релизом;
- особенности только с причиной и с согласования ведущего разработчика;
- динамика количества ошибок по группам — как метрика технического долга.
Если команда ведёт исходники в Git и работает в EDT, рядом с АПК часто используют проверки самой EDT и статический анализ на базе BSL Language Server с выводом в SonarQube. Эти инструменты не заменяют друг друга: АПК ближе к официальным стандартам «1С», статический анализ удобнее встраивается в конвейер сборки. Как выстроить такой конвейер — в разделе DevOps для 1С.
Типичные ошибки при работе с АПК
- Проверка всего подряд на типовой конфигурации. Получается огромный отчёт по типовому коду. Ограничьте проверку своими объектами или расширениями.
- Не указаны библиотеки. Замечания по БСП засоряют отчёт.
- Неверная версия платформы в подключении. Сбор данных падает или проходит некорректно.
- Особенности без причин. Через полгода никто не помнит, почему ошибка была оставлена.
- Проверка раз в год. К этому времени ошибок столько, что исправлять их уже никто не будет.
Если нужно получить объективную картину качества конфигурации перед развитием или сменой подрядчика, это удобно делать в рамках аудита 1С; проверку функциональности после исправлений дополняет тестирование 1С.
Коротко
- АПК проверяет конфигурацию на соответствие стандартам «1С», а не только на синтаксис.
- Источник — cf, dt, хранилище или файловая база; серверную базу проверяют через cf или хранилище.
- Указывайте встроенные библиотеки и выбирайте сценарий проверки расширений, чтобы видеть только свой код.
- Особенности — с причиной и по согласованию, иначе отчёт перестаёт отражать реальность.
- Максимальную пользу АПК даёт при регулярном запуске по расписанию и правиле «без новых критичных ошибок».
