Кто старое помянет: ловим новые нарушения архитектурных правил 1С

Команда проекта 1С из нескольких разработчиков придерживается договорённостей об устройстве конфигурации: прикладной код обращается к БСП только через программный интерфейс, модули продаж не вызывают склад напрямую, регистр остатков читают только модули склада. Договорённости существуют устно и нарушаются при первой срочной доработке. Проверять их после каждого коммита вручную невозможно, а в типовой конфигурации уже накоплены сотни старых нарушений, и разбирать их перед вводом проверки команда не станет. Для этого я написала arch_gate.py: договорённости записываются правилами в JSON, базовая линия запоминает существующие нарушения, а проверка при сборке сообщает только о новых и возвращает код для остановки сборки. Данные инструмент берёт из XML-выгрузки конфигурации или из графа Analyzer 1C через REST.

Чтобы выяснить, что из этого доступно в Analyzer 1C и как построить проверку, я изучила руководство и REST Analyzer 1C 2.7.65, записала правила для учебной «Нано-УТ 2.0» и типовой УТ 11.5 и сняла базовые линии обеих конфигураций. На УТ 11.5 проверка отделяет 1776 старых нарушений и сообщает только о новых. На «Нано-УТ» для проверки заложены пять новых нарушений и два сдвига строк рядом со старыми.

Стенд

Что умеет Analyzer 1C

Источники: руководство пользователя версии 2.7.65 (102 страницы), описание MCP-сервера (10 страниц) и описание REST (GET /openapi.json, 200 путей). Каждая из рассматриваемых возможностей затем проверена вызовом API на загруженной «Нано-УТ», чтобы не пересказывать руководство без проверки.

Встроенные проверки «рисков» есть: горячие точки, «модули-монстры», мёртвые экспортные процедуры. Способа добавить собственное правило в изученных документах и интерфейсах я не нашла. Отдельное замечание: показатель «вызовов» на панели (53 на «Нано-УТ») не совпадает с числом рёбер графа (185 между модулями и 112 внутри), и что он подсчитывает, руководство не объясняет. Далее числа берутся только из таблиц графа.

Вывод из таблицы: Analyzer 1C через исследованные интерфейсы предоставляет данные об устройстве конфигурации. Проверка договорённостей команды по этим данным выполняется отдельным инструментом arch_gate, которому нужны правила, базовая линия и код возврата для сборки.

Граф «кто вызывает» в Analyzer 1C: продажи вызывают склад напрямую, старое нарушение из базовой линии

Загрузка конфигураций

«Нано-УТ 2.0» (293 файла) загрузилась через POST /api/conf/upload и POST /api/reload за 3,3 секунды, пик памяти контейнера 0,17 ГБ.

С УТ 11.5 загрузка прошла иначе. Архив выгрузки 834 МБ, 48 158 файлов. Analyzer в начале журнала предупредил, что для конфигураций масштаба ERP рекомендует 16–32 ГБ памяти и что при её нехватке загрузка оборвётся без сообщения об ошибке. Загрузка выполнена для проверки этого предупреждения на имеющемся стенде.

Через 28 минут 22 секунды Analyzer отметил загрузку как оборванную, пик памяти контейнера 3,08 ГиБ из 3,78. Система в списке не появилась. Docker на стенде получил 3,78 ГиБ из 7,9 ГБ памяти машины; с большим лимитом опыт не повторялся, поэтому для УТ 11.5 далее работает только разбор выгрузки. До опыта в Analyzer была загружена другая система. После него она возвращена из того же архива, контрольная сумма и цифры панели сверены.

Правила и базовая линия

Договорённость записывается одним предложением, и из него получается правило. Группы модулей задаются подсистемой, маской имени или списком. Так выглядит часть правил для УТ 11.5:

1
2
3
4
5
6
7
8
9
10
11
12
13

"groups": {
  "БСП": [{"subsystem": "СтандартныеПодсистемы"}],
  "Прикладные": [{"rest_of": ["БСП"]}],
  "Склад": [{"subsystem": "Склад"}, {"subsystem": "СкладБазовая"}]
},
"rules": [
  {"id": "U2", "type": "forbid_call", "from": "Прикладные", "to": "БСП",
   "regions": ["СлужебныйПрограммныйИнтерфейс"],
   "title": "Прикладной код не вызывает СлужебныйПрограммныйИнтерфейс БСП"},
  {"id": "U4", "type": "query_table_only",
   "tables": ["AccumulationRegister.ТоварыНаСкладах"], "allow": ["Склад"],
   "title": "Регистр ТоварыНаСкладах читают запросами только модули склада"}
]

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

Команда baseline записывает все нарушения, какие есть сейчас. Отпечаток каждого состоит из правила, вызывающей процедуры и вызываемой процедуры; для запросов из правила, модуля и таблицы; для ролей из роли, объекта и права. Номера строки в отпечатке нет, он хранится отдельно как подсказка для поиска. Команда check печатает новые нарушения и возвращает код 1, если они есть, или 0, если новых нет и все правила выполнены. Если правило пришлось пропустить, потому что в данных Analyzer нет областей, проверка сообщает об этом, сохраняет список в check.json и возвращает код 2. Старые нарушения пропущенного правила исправленными не считаются. Если после снятия базовой линии изменился rules.json, check об этом предупредит.

УТ 11.5: сколько нарушений уже есть в типовой

Для U1–U3 ориентиром служат разделы модуля из стандарта 1С «Структура модуля»: открытый интерфейс, интерфейс библиотеки и внутренняя реализация подсистемы. Группы и граница второго уровня заданы мной для этого опыта; U4–U6 также выбраны для этого опыта как ограничения на запросы и права и универсальными требованиями 1С к типовой УТ не являются.

Разбор прошёл 12 289 модулей, 220 187 процедур и нашёл 321 397 вызовов вида Модуль.Процедура(; у 8078 вызываемая процедура не нашлась: не было модуля или нужной процедуры в нём.

Отчёт по УТ 11.5: нарушения по шести правилам против базовой линии

Для проверки чисел таблицы взята выборка в 55 находок предварительного разбора: по десять на правила U1–U4 и U6 и все пять по U5. К каждой в сохранённом разборе приведена цитата кода: 50 настоящих, 5 спорных, 0 ложных. После исправлений парсера новую независимую выборку я не делала, поэтому эти оценки нельзя механически переносить на все 1776 итоговых находок. Все спорные относятся к U3: вызов идёт между вложенными подсистемами одного раздела, и считать ли это «другой подсистемой», решает команда. В правиле U3 границей служит второй уровень дерева подсистем; при другом уровне число будет иным, 1113 относится ко второму уровню.

Исправлять всю историю перед вводом проверки означало бы разобрать больше полутора тысяч находок в коде поставщика. Базовая линия заменяет вопрос «когда будут исправлены все находки» вопросом «появились ли новые нарушения после этого коммита».

Пять новых нарушений: что обнаружила проверка

На копии выгрузки «Нано-УТ» я заложила изменения и записала их список до прогона проверки.

Базовая линия неизменённой конфигурации содержала 9 нарушений. После правок их стало 14, и check напечатал ровно пять новых с файлом и строкой каждого, исправленных 0, код возврата 1. Сдвиги строк S1 и S2 ложных срабатываний не дали. Случай P5 объясняет, почему в отпечаток входит процедура: новое нарушение той же пары модулей возникло в другой процедуре и не было скрыто старым.

check против базовой линии: пять новых нарушений и код возврата 1

Затем изменённая копия загружена в Analyzer 1C, и та же проверка выполнена по его графу: получены те же пять отпечатков. На исходной «Нано-УТ» обе базовые линии дали 9 одинаковых нарушений и 185 межмодульных рёбер, на изменённой копии 188 из 188. Analyzer видит ещё 112 вызовов внутри одного модуля. Десять из них я сверила с кодом: во всех случаях процедура вызывает соседнюю по короткому имени, а проверка такие вызовы по построению не учитывает.

Время

На учебной конфигурации команды из выгрузки укладывались в секунду. На УТ 11.5 прогон без кэша занял минуты. Ключ --cache сохраняет разбор неизменённых модулей между запусками; необходимость его применения определяется бюджетом времени сборки.

Пределы

• Разбор выгрузки сравнивался с графом Analyzer 1C на учебной конфигурации в 81 модуль. На УТ 11.5 числа получены только своим разбором: в Analyzer Community при 3,78 ГиБ памяти она не загрузилась. Поведение при 16 ГБ я не проверяла.
• Правила «Нано-УТ» составлены под её устройство: общие модули там не входят в подсистемы, поэтому слои заданы масками имён.
• Выборка в 55 находок из 1776 характеризует качество разбора на этих примерах. Исправления разбора после неё (вложенные подсистемы, строка запроса) проверены полным пересчётом базовой линии, новая выборка не разбиралась.
• Проверка видит вызовы вида Модуль.Процедура( и Справочники.Имя.Процедура(. Вызовы через переменные, Выполнить и внутри модуля в неё не попадают. Запросы ищутся по тексту строк со словом ВЫБРАТЬ.
• После переименования вызывающей процедуры старое нарушение выглядит новым.
• Формат EDT, расширения, MCP Analyzer 1C, загрузка из git и работа в CI на Linux не проверялись.

Что проверить в конфигурации проекта

1. Запишите четыре-шесть договорённостей команды по одному предложению. Каждое должно называть, кто кого не вызывает, кто читает таблицу или какая роль не получает права.
2. Выгрузите конфигурацию в XML и снимите baseline. Прочитайте первые десять находок каждого правила вручную: так видно, правильно ли заданы группы.
3. Если правило о границе подсистем дало сотни находок, проверьте другой уровень дерева подсистем и определите, какая граница соответствует договорённости команды.
4. Положите rules.json и baseline.json рядом с конфигурацией в репозиторий и добавьте в сборку check --cache.
5. Если в проекте используется Analyzer 1C, загрузите конфигурацию и сравните базовые линии двух источников командой compare. Для типовой конфигурации сначала проверьте, сколько памяти выделено Docker.

Файлы к статье

Инструмент arch-std-28-3-tool.zip. arch_gate.py с командами baseline, check, report и compare, модуль чтения REST Analyzer 1C, 92 теста и README с форматом правил, кодами возврата и пределами. Тесты работают на фрагментах настоящей выгрузки «Нано-УТ» и сохранённых ответах Analyzer 1C, сеть им не нужна. Запуск из чистой распаковки:

1

python -X utf8 -m unittest discover -s tests

Тесты из чистой распаковки архива: 92 теста, OK

Архив к статье arch-std-28-3-companion.zip. Правила опыта для «Нано-УТ» и УТ 11.5 с пояснением каждого; таблица возможностей Analyzer 1C со ссылками на страницы руководства и пути API; отчёты baseline, check и report из опыта; разбор выборки 55 находок УТ 11.5 с цитатами кода; заполненный чек-лист «как ввести архитектурный стандарт»; команды загрузки в Analyzer через REST и скрипты стенда; расширенная PDF-версия статьи.

Расширенная PDF-копия статьи (35 страниц) входит в тот же архив. В ней полный текст статьи и десять приложений: заполненный чек-лист введения архитектурного стандарта, команды повторения опыта по шагам, правила опыта для обеих конфигураций с пояснениями, таблица возможностей Analyzer 1C с источниками, загрузка конфигураций в Analyzer 1C, сравнение своего разбора с графом Analyzer на «Нано-УТ», заложенные нарушения и результат check, отчёты report по «Нано-УТ» и УТ 11.5, сохранённый разбор 55 находок и журналы прогонов. Она нужна, чтобы прочитать статью без сайта и проверить приведённые числа по первичным данным.

Итог

Analyzer 1C 2.7.65 строит граф конфигурации: вызовы, читатели таблиц, права ролей, подсистемы. Готовых проверок правил команды и CLI для них в исследованной поставке я не нашла; REST при этом доступен для вызова из внешнего сценария. Базовая линия в исследованной версии относится к сравнению снимков конфигурации, и на этом стенде Community этот API ответил HTTP 402. На изменённой «Нано-УТ» граф и разбор выгрузки совпали по 188 межмодульным рёбрам, на исходной копии по 9 нарушениям. Загрузка УТ 11.5 при 3,78 ГиБ памяти оборвалась; нехватка памяти названа возможной причиной.

Проверяемый стандарт сложился из правил в JSON, базовой линии старых нарушений и проверки, которая блокирует новые нарушения, а о неполноте проверки сообщает отдельным кодом. На УТ 11.5 базовая линия отделяет 1776 нарушений типовой конфигурации. На «Нано-УТ» проверка нашла все пять заложенных нарушений и на сдвиг строк не отреагировала.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S