Автоматизированная проверка конфигураций… и пара слов о стандартах разработки

Большое спасибо Максиму Дерюшеву за существенные дополнения и замечания, которые позволили сделать эту публикацию лучше

• Базовая информация об АПК

• Настройка подключения к проверяемой базе и проверок по умолчанию

• Проведение проверок

• Результат проверки

• Отчеты АПК

• Правила проверки конфигураций

• Фильтрация объектов при проведении проверок

• Подведение итогов

В последнее время все чаще стали появляться публикации, нацеленные на выработку и поддержание качества разработки. На упорядочивание не только работы пользователей с результатами труда разработчиков, но и труда самих разработчиков 1С. Примерами могут служить как выступления на последних конференциях Инфостарт, так и ряд вебинаров,  затрагивающих в том числе вопросы автоматизированного тестирования, код-ревью, применения инструментов, популярных в других ИТ-сферах. Часть хороших материалов есть в открытом доступе: 

Открытый инструментарий счастливого 1С-ника

Friday's Club 16.12.2016

Пост-вебинар "Разработка через автоматизацию, в помощь типовому 1С-нику"

Разработка через автоматизацию, в помощь типовому 1С-нику

BDD в 1С

Разработка на 1С по промышленным стандартам

Действительно, сложность конфигураций 1С с каждым годом увеличивается, команды растут, выходят продукты, содержащие более 5 000 000 строк кода. Без упорядочивания потоков кода работать становится сложно. И речь не только о поддержании минимального порядка - префиксации новых объектов,  соглашений о комментариях или  раскидывании объектов по подсистемам. С ростом команд и усложнением конфигураций становится понятна необходимость придерживаться стандартов в более широком их понимании.

А чтобы не оставаться сапожниками без сапог, хорошо иметь для этих целей подходящие инструменты. На конференциях и вебинарах, в том числе перечисленных выше, предлагаются интересные инструменты. В то же время достаточно малоизвестная конфигурация от самой фирмы 1С тоже заслуживает внимания. Как вы уже поняли из названия публикации, продукт этот называется “Автоматизированная проверка конфигураций”. Он бесплатен, доступен каждому пользователю (формально для использования требуется доступ к ИТС), достаточно прост в использовании, но пока что не очень распространен.

Отчасти это объясняется тем, что фирма 1С сама активно продвигает идею соблюдения стандартов и использования подходящих для этого инструментов только среди разработчиков тиражных решений через сертификацию “1С:Совместимо”. Влияние идеи соблюдения стандартов и чистоты кода в отношении широких масс разработчиков, не занимающихся тиражными решениями, чувствуется гораздо слабее.  Даже ознакомление с основными стандартами разработки находится под условным замком - наличием доступа к ИТС  (информация устарела, в настоящее время, на 2018-2019 год, доступ открыт без регистрации):

https://its.1c.ru/db/v8std

Базовая информация об АПК

Конфигурация АПК предназначена для автоматического поиска ошибок и отклонений от стандартов в конфигурациях. Ее применение рекомендовано фирмой 1С еще с 2009 года, причем не только в фирмах-разработчиках тиражных решений, но и для прочих компаний, в которых производится доработка и адаптация типовых решений:

https://1c.ru/news/info.jsp?id=10018

Первое впечатление о конфигурации может дать страница на сайте 1С:

http://v8.1c.ru/acc/

На ней описаны основные  возможности этого инструмента и сказано, что он помогает:

• соблюдать типовые стандарты разработки и выполнять платформенные проверки конфигурации

• создавать и соблюдать собственные правила проверки конфигурации

• соблюдать стандарты, требуемые для получения статуса 1С:Совместимо

• выполнять проверки по расписанию

• проверять орфографические ошибки

• присваивать выявленным ошибкам конфигурации различные статусы, в том числе отмечать их как “особенности” не требующие исправления

• выполнять рассылку сообщений об ошибках ответственным сотрудникам и собственно назначение ответственных за различные объекты

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

• упомянута даже возможность интеграции с СППР

Другим источником общей информации может служить публикация в интернет-журнале PCMagazine:

Часть 1 ,  Часть 2

Помимо этих обзорных материалов, информации в сети по АПК и ее применению почти нет. Хорошей новостью является то, что в поставку самой конфигурации включено руководство пользователя в формате PDF. Некоторые вопросы раскрыты в руководстве не так подробно, как хотелось бы. Но все же руководство есть и позволяет научиться выполнять основные приемы при работе с конфигурацией.

Для того, чтобы не повторять руководство пользователя здесь будет рассмотрен пример применения АПК для проверки типовой конфигурации, а не демо-конфигурации из поставки АПК. Также попробуем рассмотреть детали работы, о которых в руководстве не сказано.

Начнем с нуля. Загрузить последнюю версию АПК можно по следующей ссылке:

https://releases.1c.ru/project/ACC

На момент публикации этой статьи последним релизом является 1.1.12.26 от 30.01.17, но сначала она писалась для версии 1.1.11.16, поэтому часть скриншотов и замечаний будет относится к этой версии. Для работы с АПК 1.1 потребуется платформа версии не ниже 8.3.6. После установки поставки конфигурации в списке шаблонов конфигураций появляются три новых пункта:

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

Второй шаблон  “Автоматизированная проверка конфигурации (демо)” после разворачивания содержит загруженную информацию о демо базе  (находящейся в третьем шаблоне). Его можно использовать, чтобы посмотреть как работают отчеты и стандартные проверки. Лучше всего работу с этой базой изучать вооружившись руководством пользователя из поставки, так как примеры в руководстве рассчитаны именно на эту демо-базу:

АПК работает таким образом, что при выполнении новых проверок загружает информацию из проверяемой конфигурации через COM-соединение. Для этого ей нужна существующая файловая “подопытная” база. Поэтому если есть желание не только ознакомиться с интерфейсом демо-базы, но провести полный цикл с работы с проверяемой базой, то имеет смысл также развернуть еще одну файловую базу из третьего шаблона “Демонстрационная конфигурация для тестирования”.

В этом случае получим две базы данных - одна демонстрационная АПК с уже загруженной информацией о проверяемой Демо-базе и сама проверяемая Демо-база, позволяющая быстро ознакомиться с процессом подключения и проведения новых проверок.

Отмечу, что после экспериментов с демо-базами чистую базу АПК можно и не разворачивать. Проверки рабочих конфигураций можно выполнять на той же конфигурации что и проверки демо-базы. В АПК можно загрузить информацию о любом количестве проверяемых баз.

Вообще принцип работы АПК похож на работу “Конвертации данных”.  Работа в конфигураторе АПК не требуется (хотя, как станет понятно далее, без нее вряд ли получится обойтись совсем). Информация о структуре проверяемых конфигураций загружается в пользовательском режиме. В нем же задаются и алгоритмы проверок конфигурации в виде кода на языке 1С:Предприятия, который затем самой системой исполняется с помощью оператора “Выполнить”. В коде можно и нужно применять встроенные в АПК (не платформенные) методы - процедуры и функции, которые выполняют работу с автоматически создаваемыми объектами. Объекты необходимые для проведения проверки конфигурации создаются самой системой и становятся доступны в коде обработчиков проверок. Подробное описание этих методов, объектов и обработчиков можно получить из 6-ой главы "Руководства пользователя".

Конфигурация АПК почти полностью построена на справочниках, регистрах сведений и обработках.  В общем если вы знакомы с “Конвертацией данных” то принципы работы с АПК будут понятны. Более того, если не возникнет явной необходимости в собственных алгоритмах проверок, то сначала можно будет ограничиться стандартными проверками и не изучать встроенные методы и программные объекты системы. Тогда почти всю настройку можно сделать мышкой и кажется, что для многих задач этого будет достаточно.

Настройка подключения к проверяемой базе и проверок по умолчанию

После запуска демо базы перед нами предстает такой интерфейс:

Предназначение разделов с точки зрения разработчиков АПК можно прочитать в руководстве. Мы же пойдем по порядку и сначала добавим новую конфигурацию. Нажмем на кнопку “Новая конфигурация”. Система предложит заполнить параметры подключения. Фактически открывается форма элемента справочника “Конфигурации” :

Наименование и полное наименование - это произвольные текстовые поля, только чувство прекрасного и длина поля может ограничить вас в том, что будет в них указано. А вот дальше ограничения более жесткие. Нужно указать полный путь к исполняемому файлу платформы 1С. В более ранних версиях АПК дополнительно нужно указать версию платформы с которой идет работа. Напомню, что АПК может проверять конфигурации только на платформе версии 8.3.6 и выше.

Информация от разработчиков:

Если будет указан путь к платформе ниже, то при COM-соединении будет выдана ошибка. Причина в следующем. В связи с развитием платформы и новых проверок АПК собираются сведения (свойства метаданных), появившиеся только в платформе 8.3.6 или выше. Таким образом, при проверке на версии, например, 8.2 при сборе таких сведений, естественно, будет выдана ошибка. А так как эти новые проверки, как правило, являются приоритетными, то выставлен запрет на запуск проверки ниже, чем 8.3.6. В обратном случае (если клиенту принципиальная версия платформы ниже), то предполагается, что для проверки своей конфигурации он может воспользоваться предыдущими версиями АПК.

Далее нужно указать путь к демо-базе и параметры подключения к ней. Под демо-базой в данном случае понимается не что иное,  как специально выделенная файловая база, которая содержит в себе проверяемую конфигурацию. Возможностей для подключения SQL базы в АПК нет. При желании это можно доработать, но большого смысла в этом нет. Во первых выполняется просто проверка конфигурации, а не юнит-тестирование или нагрузочное тестирование. В этом случае даже для крупных конфигураций вроде ERP 2 достаточно просто пустой файловой базы, содержащей актуальную конфигурацию. Во вторых, в соответствии со стандартами 1С любая конфигурация должна быть рассчитана на работу не только с SQL-базой но и на работу в файловом варианте.  

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

Замечу также, что СППР как и АПК требует файловой базы для загрузки информации о конфигурации. Поэтому если вы решили вести разработку с применением технологий, предлагаемых 1С, с применением АПК и СППР, то для обоих этих систем будет достаточно создать одну файловую базу, при необходимости подключив ее к хранилищу конфигураций и настроив автоматическое обновление конфигурации из хранилища перед загрузкой данных.

Выбор между режимами “Конфигурация” и “Библиотека” определяет жесткость проверок. Для режима “Библиотека” проверки жестче. Библиотека - это конфигурация встраиваемая в другие, а значит она должна удовлетворять определенным правилам и “думать не только о себе”.  Если навести курсор на оба варианта переключателя, то выплывет подсказка с описанием различий проверки. В частности, для библиотеки будут проверены все выбранные требования. Для конфигурации не проверяются требования из группы "Разработка и использование библиотек" вне зависимости от того, выбраны они или нет. Данная группа требований содержит очень долговременные правила проверки, предназначенные действительно только для библиотек.

Важный момент для версии 1.1.11.16 и более ранних версий АПК (в верии 1.1.12.26 эта ошибка устранена).  После того, как настройки заданы и элемент справочника “Конфигурации” записан, можно проверить подключение. Но в первый раз система может выдать ошибку об отсутствии подключения.

Это обманчивое сообщение. Если пути и пользователи заданы правильно просто нужно предварительно записать элемент этого справочника и только потом проверять подключение. Тогда система отчитается об успешном подключении. Проверка подключения к большой базе, например ERP может занимать до 1-2 минут:

Фактически сейчас мы создали новый элемент справочника "Конфигурации". Теперь открыть его можно разными способами:

• Через меню “Настройки” -> “Конфигурации”

•  В разделе “Проверки” нажать “Выбрать конфигурацию”

•  Или просто открыть справочник “Конфигурации” через меню “Операции”

Вернемся к окну настройки конфигураций.

На второй вкладке “Проверяемые требования” можно настроить то, какие проверки мы хотим выполнять над нашей конфигурацией. Доступны два предопределенных варианта : “Полная проверка”  - проверка на соответствие системе стандартов https://its.1c.ru/db/v8std  и контроль орфографии , а также  “1С:Совместимо” - проверка на соотвествие стандартам 1С:Совместимо   http://1c.ru/rus/products/1c/predpr/compat/soft/requirements.htm

Также можно настроить произвольный набор проверяемых требований, после этого вбить в поле “Вариант проверки” произвольное представление варианта и сохранить его под этим наименованием по кнопке “Сохранить вариант”. Варианты сохраняются в привязке к конфигурациям, то есть ту же настройку нельзя будет автоматически применить к другим элементам справочника "Конфигурации":

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

Список проверок достаточно объемный. Каждое требование - это стандарт разработки, придерживаясь которого можно сделать наши продукты лучше. Но возможность отключать отдельные требования или их группы тоже не лишняя. Например на большинстве предприятий можно ограничиться вариантом “Полная проверка” (орфография + система стандартов) и не делать проверок на “1С:Совместимо”. Или контролировать хотя бы орфографию, так как не бывает такого, чтобы разработка годами велась без единой орфографической ошибки. 

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

Информация от разработчиков:

Есть смысл подробнее рассказать, что такое группа "Система стандартов", и чем она отличается от двух других групп. Итак, начнем с группы "1С:Совместимо". Как уже было ранее написано, это обязательный набор стандартов для получения определенного статуса для своей конфигурации. Грубо говоря, это - костяк, которому обязательно должны соответствовать все конфигурации без исключения. К слову, данная группа стандартов не проверяет конфигурацию на орфографические ошибки…

Далее "Орфография" - группа стандартов, которая проверяет конфигурацию только на орфографические ошибки. Каждый уважающий себя разработчик может проверить свою конфигурацию на орфографию. В этой группе собраны все правила проверки, отслеживающие орфографию в текстах модулей, метаданных (имя, синоним, комментарий), элементах форм, макетах, в общем, везде, где можно проверить текст. "Из коробки" проверяется только русский текст, но как верно замечено в комментариях, для других языков можно загрузить свои словари и даже заменить ими идущий в поставке конфигурации.

А теперь про группу "Система стандартов". Она является самой глобальной и содержит в себе проверки двух остальных предопределенных групп требований, а также дополнительные специализированные проверки. Для клиентов ошибки этой группы являются скорее рекомендациями, хотя для типовых конфигураций большинство ошибок, конечно, обязательны к исправлению. Т.о. если какой-либо стандарт описан в группе "1С:Совместимо" или "Орфография", он без сомнения будет также описан и в группе "Система стандартов", однако, может быть, более подробно и с более глубокими проверками.

На вкладке "Исключения из проверки"  настраивается различная фильтрация. Например можно настроить проверки так, чтобы проверялись только добавленные вами в типовую конфигурацию объекты с определенным префиксом вроде “мф_СуперТаможеннаяДекларация”.

Или, если вы ведете разработку с добавлением всех измененных или добавленных объектов в определенную подсистему для разработки, то проверку имеет смысл выполнять только в рамках этой подсистемы, а неизменные объекты типовой конфигурации находящиеся на “замке” обходить стороной.  Если необходимо временно исключить какой-либо настроенный фильтр при проведении проверок не нужно удалять его. Достаточно снять флаг использования (вторая колонка):

Функция фильтрации очень полезная и с ней имеет смысл поэксперементировать, что и сделаем далее.  Сразу скажу, что разрешающие проверки вроде "Включать подсистему" и "Включать с префиксом" работают по "ИЛИ". То есть объект попадет в проверку если он будет удовлетворять одному либо другому условию. Это не всегда удобно. К счастью, изменить подобное поведение очень просто. Подробнее этот вопрос будет рассмотрен в разделе посвященному фильтрации, как и вопрос влияния фильтров на время проведения проверок

В версии АПК 1.1.11.16 и более ранних версиях настройки фильтрации были разделены на две вкладки - “Фильтры сбора требований” и “Исключения при сборе данных”, но смысл был тот же самый:

Также в форме настройки можно задать необходимость проведения проверок по расписанию:

Это настройка не для работы через регламентное задание. Для запуска проверки по расписанию требуется чтобы АПК была запущена в пользовательском режиме и работала. При старте системы в модуле обычного приложения вызывается метод ПриНачалеРаботыСистемы() где подключается обработчик ожидания ЗапускПроверкиПоРасписанию(),   который и выполняет проверку по расписанию. Если есть желание запускать проверку регламентным заданием систему придется доработать. Если заглянуть в конфигурацию АПК то можно увидеть что в ней есть всего два регламентных задания и оба они не связаны с проверками по расписанию:

Информация от разработчиков:

Объяснение очень простое. Если АПК развернута в SQL-варианте , то при указании пути к конфигурации (точнее, демо-базе) на клиенте, проверка попросту не запустится, т.к. регламентное задание всегда работает на сервере. В файловом варианте АПК, безусловно, больше бы подошло регламентное задание, а не обработчик ожидания.

Расписание - это не последняя из возможных вкладок. Если включить в системе интеграцию с “Системой проектирования прикладных решений”, то появится еще одна вкладка “Интеграция с СППР”, позволяющая настроить автоматическую регистрацию ошибок в СППР.  Настройка интеграции на уровне системы выполняется в форме констант (“Операции” - “Константы”).

Функционал интеграции с СППР предназначался разработчиками АПК для внутреннего использования в фирме 1С (об этом сказано в "Руководстве пользователя", стр.28). Однако уверен, что для тех компаний, которые в своей работе уже используют СППР или планируют ее использовать, этот функционал будет интересен. Его можно взять за образец для реализации своего механизма интеграции или разобраться с ним и использовать "из коробки":

При этом возможно как подключение АПК к веб-сервису поднятому со стороны СППР, так и наоборот, можно в СППР настроить подключение к веб-сервису поднятому на стороне АПК:

Проведение проверок

После проведенных настроек подключения и выбора проводимых проверок можно переходить  к выполнению проверок.

Для проведения новой проверки необходимо сначала сделать проверяемую конфигурацию текущей. Все новые проверки производятся над “текущей конфигурацией”. Для этого в разделе “Проверки” необходимо нажать “Выбрать конфигурацию” и затем выбрать элемент справочника конфигурации, который будет назначен “текущим”.

При нажатии на кнопку “Новая проверка” система предложит два варианта - провести проверку заново выполнив подключение к проверяемой конфигурации, заново собрав данные, либо провести проверку ранее собранных данных.

Возможность проводить проверки по ранее собранным данным позволяет поэтапно выполнять длительные проверки. Например сначала можно собрать данные о конфигурации и выполнить проверку с фильтрацией по части подсистем. Затем включить фильтры по другим подсистемам и вторую проверку делать уже по ранее собранным данных, что позволит выполнить ее значительно быстрее.

Информация от разработчиков:

Здесь надо также сказать, что теперь состав собираемых данных напрямую зависит от выбранных требований. Например, выбрано одно требование "Орфография в текстах модулей". Если открыть карточку самого требования и перейти на вкладку "Этапы проверки", то можно увидеть, что выбран только 1 флажок "Заполнить сведения о модулях":

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

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

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

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

Нажимая на кнопку “Далее” можно переопределить все настройки , которые описывались в предыдущем разделе этой публикации, включая проводимые проверки. Правда следует учитывать что если не выбрать ни одной проверки на соответствующем шаге, то система посчитает, что нужно выполнить ВСЕ проверки, а не просто подключиться и загрузить информацию об объектах из проверяемой базы:

Поэтому если целью запуска является не полная проверка, а обновление структуры конфигурации или тестовый прогон АПК и ознакомление с процессом, то снимать все флажки на этом шаге не следует. В первый раз целесообразно отметить только какой-нибудь один элемент, например - “Платформенная проверка конфигурации” в следующей ветке:

В этом случае список шагов проверки будет примерно следующим:

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

На последнем шаге можно также установить фильтры на проверяемые объекты. Правда, если это первая проверка конфигурации, то в АПК еще не будет информации о структуре конфигурации. В этом случае дерево конфигурации на этом шаге будет пустым, но его можно загрузить кнопкой "Прочитать структуру конфигурации" прямо из этого же окна:

Теперь остается нажать кнопку “Выполнить проверку”. Начнется процесс проведения проверок. С миганием окон 1С и выводом лога процесса в окно сообщений. Вывод лога сделан очень неудобно. Окно проверки висит модально и если заранее не подумать о том, чтобы окно сообщений было видно, то о происходящем нельзя будет ничего узнать пока процесс не закончится:

Поэтому если у вас небольшое разрешение экрана, то лучше сразу озаботиться тем, чтобы сдвинуть модальное окно запуска проверки таким образом, чтобы окно сообщений было видно.

На одном из этапов проверки система обновляет содержимое справочника “Структура конфигурации”, содержащего дерево (иерархию) объектов метаданных как в конфигураторе. Данные о конкретном объекте будут обновлены если этот объект изменился или был включен в дополнительную подсистему. Элемент справочника будет помечен на удаление если соответствующий объект конфигурации был удален. Будут созданы новые элементы для новых объектов конфигурации:  

Также, при каждой проверке со сбором данных, обновляется содержимое регистров "ЗначенияСвойствОбъектов" и "ЗначенияСоставныхСвойствОбъектов", хранящих свойства объектов, модули, содержимое макетов, элементы форм и т.д. При проверке по ранее собранным данным эти сведения остаются прежними.

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

Выгрузка происходит без иерархии - все файлы в одну папку:

Информация от разработчиков:

Итак, что и когда собирается (при проверке со сбором данных):

• Структура конфигурации - вообще всегда, какие бы требования ни были выбраны.
• Сбор происходит путем запуска внешней обработки из общего макета "ЗагрузчикСтруктурыМетаданных" в предприятии в толстом клиенте. Обработка в предприятии работает с объектом платформы "Метаданные" и пишет данные во внешний файл, который потом передается и разбирается в АПК.

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

• Сбор сведений о метаданных (повторюсь, это свойства объектов метаданных, а не сама структура) происходит путем запуска внешней обработки из общего макета "ЗагрузчикСведенийОМетаданных".
• Сбор сведений о формах (а точнее, об элементах форм) - с помощью обработки из макета "ЗагрузчикСведенийОФормах".
• Сбор сведений о формах из XML происходит путем анализа XML-файла формы из выгрузки конфигурации в файлы XML. Собирается вся информация, которую не удалось получить из предприятия на предыдущем этапе.
• Сбор сведений о модулях - путем чтения текстов модулей из файлов выгрузки XML.
• Сбор сведений о ролях (а точнее, сбор прав каждой роли для каждого объекта) - из файлов ролей выгрузки XML.
• Сбор сведений о макетах - с помощью обработки из макета "ЗагрузчикСведенийОМакетах".
• Сбор сведений о справке - путем чтения файлов справки из файлов выгрузки XML.

Платформенная проверка конфигурации - пакетный запуск демобазы в режиме конфигуратора с ключами платформенной проверки. Также указывается файл с логом проверки. Затем он разбирается в АПК, из него получаются ошибки платформенной проверки, которые хранятся в отдельном регистре "ОшибкиПроверкиКонфигурации".

Таким образом, если выбрано хотя бы одно требование с флажком сбора сведений о формах из XML, ролях, модулях или справке, то проверяемая база будет выгружена в файлы XML. Если ни одно из этих действий не требуется, что выгрузки не будет.

Ранее все действия производились последовательно. Сначала запускался сбор структуры, затем выгрузка в XML, затем платформенная проверка, затем сбор свойств метаданных, модулей, форм и т.д., что сильно замедляло проверку (сбор данных) крупных конфигураций.

В АПК 1.1.12 было добавлено копирование исходной базы во временный каталог и выявлены самые долговременные этапы сбора данных, что позволило распараллелить сбор данных при проверке. Таким образом на текущий момент сбор структуры конфигурации, платформенная проверка, выгрузка в XML и очистка регистров выполняются параллельно. Остальные этапы занимают незначительное время, даже для ERP. В результате введения параллельности сбора информации удалось ускорить проверку ERP как минимум на пару часов.

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

Если в модуле объекта или формы будет попытка обратиться к необъявленной переменной или недоступному из контекста модуля объекту, то система либо остановится в процессе проверки с ошибкой (будет висеть окно в открывшейся проверяемой базе) , либо АПК отловит эту ошибку и покажет ее в отчетах. Если АПК остановится в процессе проверки из-за такой ошибки, то это конечно не очень удобно. Но с другой стороны наличие ошибок компиляции модулей - это критическая ошибка программистов и лучше если она будет обнаружена с помощью АПК таким образом, чем попадет в продуктив и сообщение о ней поступит от пользователей!

В процессе полной проверки (или ее аналога по количеству правил и объектов) система застревает на проверке объекта №1 никак не сообщая о прогрессе:

Такой статус с сообщением о том, что проверяется объект №1 из 77 тысяч висит на протяжении 5-10 часов и кажется что АПК зависла. На самом деле процесс идет, убедиться в этом можно посмотрев на загрузку процессора в диспетчере задач или вызвав остановку из конфигуратора (если запуск АПК производился из него). Причины долгой проверки Объекта №1 , а именно самой конфигурации, следующие:

1) В рамках этого шага собирается и кэшируется информация, используемая далее при проведении проверок отдельных объектов. Благодаря этому проверка остальных объектов выполняется быстрее.

2) Большинство проверок, затрагивающих все объекты конфигурации сразу, выполняется именно в рамках этого шага.  Таких проверок много, около 90. Но наиболее длительных, занимающих большую часть времени, всего пара. Это например "Поиск неиспользуемых служебных экспортных методов". Очевидно, что нельзя сделать вывод о том, используется или не используется метод отдельного объекта, проверив только один этот объект или какую-то отдельную подсистему. Такой вывод можно сделать только проанализировав вызовы методов в рамках всей конфигурации. И очевидно, что обход всей конфигурации оптимально делать один раз, при проверке "Объекта №1", а не множество раз, при проверке отдельных документов и справочников. Другим примером длительной проверки является "Контроль наличия общего модуля, подсистемы, метода и контроль состава параметров". 

Если отключить две указанные проверки и платформенную проверку конфигурации, то проверка даже такой конфигурации как ERP может занять не более получаса. Но наверное не стоит экономить время и жертвовать качеством. Лучше решить этот вопрос организационно и делать проверки заблаговременно.

Привожу пример - начало и окончание лога выполнения проверки, который показывает что полностью процесс на ERP 2.1 и АПК 1.1.11.16 занимает порядка 15 часов (естественно цифра сильно зависит от производительности компьютера, также скорость проверки на АПК 1.1.12 значительно выше и при тех же условиях занимает около 10 часов):

[08.01.2017 13:57:12]: Выполняется проверка подключения к информационной базе через COM-соединение

[08.01.2017 13:58:22]: Начало сбора сведений о структуре метаданных конфигурации

[08.01.2017 14:12:04]: Начало выгрузки конфигурации в файлы XML

[08.01.2017 14:25:24]: Начало очистки сведений о метаданных

[08.01.2017 14:27:56]: Начало сбора сведений о ролях конфигурации

[08.01.2017 16:25:49]: Собраны и записаны сведения о ролях конфигурации

[08.01.2017 16:51:39]: Собраны сведения о метаданных конфигурации

[08.01.2017 18:26:05]: Платформенная проверка конфигурации завершена

[08.01.2017 18:26:05]: Начало тестирования объектов конфигурации

[08.01.2017 19:15:55]: Начало сбора сведений о формах конфигурации из файлов XML

[08.01.2017 19:47:20]: Стартовала проверка конфигурации

……...ЗДЕСЬ СООБЩЕНИЯ НАЧИНАЮТ ВЫВОДИТЬСЯ В СТРОКУ СОСТОЯНИЯ…..

[09.01.2017 5:19:37]: Выполнена проверка конфигурации

Результат проверки

Что получаем в результате выполнения первой проверки? Во первых, заполняется справочник версий конфигурации (справочник “Версии” подчинен справочнику “Конфигурации”). В нем появляется элемент, соответствующий версии проверяемой конфигурации. Также обновляется информация о версии в форме элемента справочника "Конфигурации":

Во вторых, создается документ типа “Проверка конфигурации” , в котором указывается этот элемент справочника “Версии” и другие параметры проверок - состав проверяемых требований, состав проверяемых объектов и “Журнал проверки” в который дублируется лог, выводимый ранее в окно сообщений:

В третьих, обновляются данные о структуре конфигурации:

Структура конфигурации - это иерархический справочник с иерархией элементов, подчиненный справочнику “Версии”, то есть при проверке конфигурации новой версии произойдет создание нового элемента справочника “Версии” и загрузка новой структуры метаданных уже в привязке к этой версии.

И в четвертых, заполняется регистр “Найденные ошибки”, который собственно и содержит информацию о том, какие ошибки были обнаружены в процессе проверки и является основой для отчетов АПК:

Для этого регистра не создана форма списка. Свалку в этом общем котле регистра можно буквально за несколько минут привести в порядок. Например добавить управляемую форму, в пользовательском режиме или сразу в конфигураторе вывести владельца объектов (элементов справочника "СтруктураКонфигурации"), к которым привязаны ошибки. Этими владельцами будут версии конфигураций.

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

Каждая запись этого регистра - это найденное несоответствие стандартам, орфографическая или другая ошибка.  Открыв какую либо из них можно убедиться, что даже такие надежные и проверенные годами системы,  как ERP 2.1 ;)) содержат опечатки и ошибки. Причем довольно большое их количество:

Хотелось бы чтобы мы воспринимали факт наличия таких ошибок в ERP не как индульгенцию на их наличие в наших разработках, а как лишнее доказательство того, что их можно и нужно выявлять и устранять. Особенно при наличии подходящих инструментов. Потому что выглядят они некрасиво и это как раз то, что видят наши пользователи. В блоге 1С на Хабре отмечается, что разработчики ERP 2 используют АПК для проверки конфигурации, но видимо ограничивают список проверок наиболее важными с их точки зрения правилами, обеспечивающими приемлемое соотношение скорости разработки и качества продукта. Мы же можем при разработке своих продуктов повышать планку качества и захватывать в том числе это направление.

Также будет полезно знать, что собранные данные о текстах модулей, блоках модулей и других свойствах объектов конфигурации помещается в регистры “Значения составных свойств объектов” и "Значения свойств объектов". Записи хранятся в привязке все к тем же объектам, подчиненным версиям и конфигурациям:  

Тексты модулей увидеть прямо из форм регистра не получится, они все упакованы в хранилища значений. 

Но для просмотра текстов модулей, уже разбитых на составляющие части, и других свойств объектов конфигурации в АПК есть замечательный инструмент! Это обработка "Просмотр свойств объектов конфигурации", открываемая через меню "Настройка":

Отчеты АПК

Информацию о найденных ошибках в виде отчетов позволяют получить сразу два раздела системы. Раздел "Ошибки":

Он строится на базе отчета НайденныеОшибки:

И раздел “Отчеты”

Он строится на базе отчета “Результаты работы”:

На самом деле в конфигурации АПК всего два основных объекта “Отчет”. Но у них довольно много различных макетов СКД:

Все они базируются на анализе регистра сведений "НайденныеОшибки". Раздел “Отчеты” предназначен для получения сводной информации по ошибкам, у него статистическая направленность, в то время как раздел “Ошибки” - для получения детальной информации по ошибкам и управления ими. В разделе “Ошибки” управление возможно как с помощью специальной командной панели, так и через контекстное меню:

При использовании файловой базы АПК и 32-разрядной платформы 1С наблюдается проблема. Если не установить достаточное количество фильтров, то  при анализе ошибок большой конфигурации можно получить сообщение о нехватке памяти. В случае ERP 2.x такое сообщение будет появляться постоянно. Происходит эта ошибка обычно уже на этапе вывода данных в табличный документ. В общем стоит ставить фильтры. В быстрые отборы вынесены всего несколько из них. Остальные можно установить по команде “Настройка отчета”.

Здесь мешает то, что отчеты начинают формироваться сразу после выбора варианта. Это сильно мешает работе и наводит на мысль о необходимости доработки конфигурации АПК вплоть до написания собственных отчетов: хочется и отборы накладывать до их формирования, и чтобы настройки отчетов сохранялись, и чтобы на управляемой форме они были. Благо на основе всего одного регистра сведений это сделать не сложно.

Замечу, что при использовании 64-разрядной версии 1С или sql-ной базы АПК ошибка с нехваткой памяти не наблюдается.

После первого взгляда на отчеты, кажется, что АПК слишком придирчива к проверяемой конфигурации. Например требует задания правильных синонимов даже для макетов печатных форм, воспринимает как ошибку слова “логистических”, “допоставить”, “подотчетниками” и т.д. Но во первых, большая часть найденных ошибок действительно требует исправления! Во вторых, выбор проверяемых правил предоставлен пользователю, его можно сделать как при настройке проверяемой конфигурации, так и при выполнении проверки. В третьих, каждое из правил можно при желании доработать, заменить своим, либо настроить фильтрацию в отчетах таким образом, чтобы видеть только интересующую информацию.

И наконец, в системе имеются и другие возможности настройки. Например регистр сведений “ВерныеСлова” (изначально пустой). Он участвует в проверке правописания, в частности методе Проверка.ПроверитьПравописание().  Слова, которые мы считаем верными в него можно внести вручную  или загрузить из текстового файла, в котором каждое слово находится в отдельной строке. Образец такого txt-файла можно выгрузить из общего макета “СловарьВерныхСлов”. Но загружать этот файл в регистр не нужно. По умолчанию система итак берет верные слова из этого макета и дополняет его данными из регистра. Также в системе существует обработка "Актуализация словаря". Очень подробно и понятно ее применение описано в руководстве пользователя (см. главу 4.6).

В общем, если покажется, что система слишком строга к нашим конфигурациям, то можно ее подкрутить в нужных местах и “задобрить” ))

Наиболее интересными отчетами являются “Ошибки по требованиям” в разделе “Ошибки”, который выводит данные в группировке , соответствующей структуре справочника “Требования”:

и “Анализ ошибок” в разделе “Отчеты”, который выводит сводные данные на основе классификации “1С:Совместимо” , “Обязательно к исполнению” и “Рекомендация”:

Правила проверки конфигураций

Создание собственных правил на конкретных примерах здесь рассмотрено не будет. Сначала нужно самому лучше разобраться в этом вопросе. В руководстве пользователя из поставки АПК созданию новых правил посвящена достаточно объемная Глава 5   -  это сквозной пример в виде целых 30-ти страниц увлекательного текста и иллюстраций ))

Пройдемся по правилам обзорно.  Находятся они в одноименном справочнике системы:

Навигация по левому дереву неудобная - выбор элемента для отображения его состава в правой части осуществляется двойным кликом. Поэтому выделенный элемент вовсе не всегда совпадает с тем, чей состав отображается справа.

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

Вверху расположены три полезные кнопки. “Показать стандарты” ведет в соответствующий раздел сайта 1С с описанием стандарта, ссылка открывается в браузере. “Открыть требования” открывает соответствующий правилу элемент справочника “Требования”, и команда “Открыть отладку” запускает обработку “ОтладчикПравилПроверки”.  Как она работает в руководстве пользователя умалчивается, но очевидно, что инструменты отладки либо имеются, либо есть наработки для них, которые можно развивать.

Алгоритм правила можно менять, как и создавать новые правила и группы правил.  При необходимости писать свои алгоритмы придется изучать встроенные методы и программные объекты. Этому посвящен соответствующий раздел “Синтаксис правил проверки” 6-ой главы PDF-руководства пользователя. Также можно использовать алгоритмы существующих правил в качестве примеров и образцов для копирования.

Встроенная справка по программе катастрофически скудна. Вернее сказать она отсутствует, поэтому описание встроенных методов получить из нее не удастся.

Фильтрация объектов при проведении проверок

В завершение посмотрим как ведет себя АПК 1.1 при проведении проверки с наложенными фильтрами. Действительно ли они помогают сократить время проверки и уменьшить объемы информации в отчетах. Проверим как фильтрацию по префиксу, так и по подсистеме.

В этом разделе будет больше “зарывания в код”, чем рассказа о возможностях АПК. Если на данном этапе это не является вашей целью - этот раздел можно пропустить.

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

апк_Документ_1_1 , апк_Документ_1_2  и новый_Документ_1_3   отнесем к подсистеме апк_Подсистема_1

апк_Документ_2_1 , апк_Документ_2_2  и новый_Документ_2_3   отнесем к подсистеме апк_Подсистема_2

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

Добавим два фильтра сбора сведений - на префикс апк_  и на подсистему апк_Подсистема_2  (скриншот сделан на версии АПК 1.1.11.16):

В результате проверки ожидаем увидеть появление ошибок и отчетов по ошибкам, касающихся только документов, подходящих под фильтры (как будет показано ниже, фильтры применяются по "ИЛИ"). Также хотелось бы получить ускорение процесса проверки, со скидкой на то, что часть операций и проверок выполняется независимо от количества проверяемых объектов.

Запустим проверку. Спустя пару часов базовых проверок (включая платформенную) увидим, что количество объектов для дальнейших проверок - это уже не пугающие 77 736 , а всего 65:

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

Однако выигрыша во времени проверки от фильтров почти не получим. В данном примере полная проверка вместо 15 часов заняла 10 , то есть ускорилась всего на 30%. В разделе "Проведение проверок" уже дано объяснение причинам такого поведения. Теперь разберемся почему так происходит на уровне кода и заодно глубже поймем как работают алгоритмы фильтрации и обхода элементов структуры конфигурации при проверках. 

В отчетах видно что помимо информации о документах также собирается информация о корневом элементе конфигурации в рамках проведения общих проверок. И при проведении проверок сложно не заметить, что именно сообщение о  проверке этого объекта №1 висит в строке состояния почти все 10 часов (на версии 1.1.11.16). При этом система сообщает о предстоящей проверки 65 объектов, хотя нам нужны максимум 6-8 из них. Остановим процесс в отладчике в то время, когда в строке состояния висит сообщения “Проверяется объект №1” и посмотрим, какие модули подвергаются проверкам. Можно увидеть, что на первом этапе проверки система все также анализирует все объекты, включая например зарплатные общие модули, которые точно не включены в нашу новую подсистему:

Но ведь мы не требовали от системы собирать данные об общих модулях. Что же представляют из себя те самые 65 объектов, которые будет проверять система?

Получить их список можно поднявшись по стеку вызовов к методу  ПроверитьОбъекты() в модуле объекта документа “ПроверкаВерсии”. Из него также можно получить информацию, что для проверки выбираются ВСЕ объекты из справочника СтруктураКонфигурации по которым были собраны данные, или система считает, что данные были собраны:

Вот эти объекты:

Самих объектов меньше чем 65, система просто посчитала не только наши документы, но и их реквизиты. Но можно заметить, что корневой элемент иерархии справочника СтруктураКонфигурации попал в этот список самым первым. И мы видели, что именно процесс его проверки занимает так много времени.

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

• Фильтрация работает только на этапе сбора данных. В процессе самой проверки фильтры уже не играют никакой роли. И это логично, ведь алгоритмы задаются в пользовательском режиме. АПК лишь передает им на проверку элементы справочника СтруктураКонфигурации, если считает, что по ним собраны данные.

• Несмотря на фильтры, наложенные нами для проверок, АПК собирает информацию о модулях ВСЕХ объектов конфигурации. Данные о модулях применяются АПК при проведении общих для всей конфигурации проверок. Ниже будет продемонстрировано, что произойдет если отключить такие проверки.

• Часть общих объектов будет присутствовать в списке на проверку в любом случае, независимо от наших фильтров. В том числе и верхний корневой объект - сама конфигурация. Опять же, это необходимо для проведения "общих" проверок. Поскольку конфигурация, попавшая в список, по прежнему проверяется по тем же правилам что и раньше, и общие модули, их тексты  и некоторые другие данные не подвергались фильтрации при сборе данных, то самая длительная  многочасовая проверка объекта №1 по прежнему будет выполняться. Радикального ускорения процесса от применения фильтров получить не удастся. 

• Система решила проверять не только документы удовлетворяющие обоим нашим фильтрам, а удовлетворяющие любому из них. На проверку будут отправлены и те объекты, которые начинаются с префикса апк_   и те объекты, которые входят в подсистему апк_Подсистема2, включая документ новый_Документ_2_3. Из перечня проверяемых объектов пропал только документ новый_Документ_1_3, не подходящий ни под один фильтр. Результат станет понятен, если заглянуть в функцию фильтрации. Разрешающие фильтры работают по “ИЛИ” , а не по “И”. Если это необходимо изменить, то опять же придется внести небольшие изменения в этот метод:

Теперь попробуем “поиграть” с кодом и посмотреть, что было бы, если бы фильтрация работала не только на этапе сбора данных, но и на этапе проверки. Создадим для этого еще один элемент справочника Конфигурации с теми же фильтрами:

Искусственно в коде метода ПроверитьОбъекты() документа ПроверкаВерсии пропустим первый элемент выборки при обходе результата запроса. То есть пропустим корневой элемент справочника СтруктураКонфигурации:

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

В этом случае от старта процесса до его завершения проходит всего 50 минут вместо 10 часов:

[11.01.2017 20:51:37]: Создан документ Проверка версии 8 от 11.01.2017 20:51:37

………………..

[11.01.2017 21:10:21]: Начало выгрузки конфигурации в файлы XML

[11.01.2017 21:19:48]: Выгрузка конфигурации в файлы XML завершена

………………..

[11.01.2017 21:34:10]: Стартовала проверка конфигурации

[11.01.2017 21:39:16]: Выполнена проверка конфигурации

Теперь отчет:

Видно что больше не выводится корневой элемент. Но кроме того в отчете отображается 9 строк вместо 10, касающиеся каждого документа. Пропали строки, сообщающие о неиспользуемых экспортных методах в модулях менеджеров документов. То есть часть ошибок действительно выявляется только если в процессе проверки задействован корневой элемент справочника СтруктураКонфигурации. Иначе соответствующие правила проверки просто не отрабатывают. Это ошибки, при выявлении которых по логике должна проверяться взаимосвязь объекта со всеми остальными объектами конфигурации. 

Таким образом, если мы хотим радикально ускорить проверки при применении фильтров, то это нужно делать либо путем отключения наиболее длительных общих проверок, требующих обхода всех модулей (это можно сделать в настройках), либо путем разработки собственных альтернативных правил проверки.

Итог:

• Инструмент “Автоматическое тестирование конфигураций” действительно позволяет будучи однажды настроенным находить ошибки в конфигурациях в автоматическом режиме. АПК дает возможность найти грубые ошибки в конфигурации, исправить орфографию, привести в соответствие ко вполне разумным и обоснованным стандартам разработки от фирмы 1С.

• АПК не может стать полной заменой другим инструментам повышения качества кода, таким как код-ревью. Она не позволяет отследить наличие излишней копи-пасты (дублирования кода), нескольких серверных вызовов там, где их можно упаковать в один, или проверить наличие простейших признаков неоптимальности запроса. Но позволяет значительно уменьшить необходимость в визуальном контроле  и стать хорошей отправной точкой для применения других инструментов и практик. А при необходимости написать свои проверки, которые решают больше задач чем те, что есть “из коробки”.

• Несмотря на нехватку информации по нему, освоение этого инструмента для начала использования на практике не сложное. Наличие руководства пользователя, а теперь и этой статьи, могут дать хороший старт для пошагового освоения. Сама конфигурация АПК достаточно простая и легко дорабатывается, по крайней мере в плане интерфейса. Дорабатывать действительно есть что. Для комфортного и эффективного использования нашим “танкам” всегда нужен напильник ))

• Разработка своих правил проверки требует освоения “встроенного языка” АПК, точнее встроенных процедур и функций, сделать это можно воспользовавшись руководством пользователя и существующими правилами.

• Даже простейшие операции, требующие сбора данных из таких конфигураций как ERP, занимают у АПК  более 20 минут. Поэтому, для разработки и отладки своих правил проверки следует либо создавать свои небольшие демо-конфигурации и демо-базы, в которых некоторые модули будут это правило нарушать, либо проводить проверки по ранее собранным данным. Оба приема помогут ускорить процесс отладки новых правил.

• В конфигурации есть инструменты для отладки новых и существующих правил. Для работы с ними необходимо разбираться с кодом конфигурации АПК , смотреть как создаются объекты и в каком контексте выполняются заданные в пользовательском режиме алгоритмы. Но при желании это кажется вполне возможным, подходы должны быть аналогичны тем, что мы применяем в “Конвертации данных”.