В процессе рефакторинга или масштабного обновления конфигурации часто возникает задача: найти все места в программном коде, где используются предопределенные элементы метаданных. Сложность заключается в том, что обращение может быть реализовано множеством способов: через точку, через функцию ПредопределенноеЗначение(), внутри текстов запросов или даже через поиск по уникальному идентификатору (GUID). В рамках данной статьи мы подробно разберем, как автоматизировать этот процесс, какие инструменты использовать и как интегрировать поиск в пайплайны CI/CD (например, через Jenkins).
Стандартный «Глобальный поиск» в Конфигураторе 1С отлично справляется с разовыми задачами, но он практически бесполезен, если нам нужно автоматизировать процесс или исключить ложные срабатывания (например, когда имя предопределенного элемента совпадает с именем реквизита или табличной части). Проанализируем ситуацию: просто искать строку Справочники.ИмяСправочника.ИмяЭлемента недостаточно, так как разработчики могли использовать конструкцию ПредопределенноеЗначение("Справочник.ИмяСправочника.ИмяЭлемента") или обращаться к элементу в запросе через ЗНАЧЕНИЕ(...).
Прежде чем приступать к поиску в текстах модулей, нам необходимо получить точный список всех предопределенных элементов, существующих в конфигурации. Использование метода ПолучитьИменаПредопределенных() полезно, но этот метод работает с данными базы. Если в базе элементов еще нет, а в метаданных они уже заведены, лучше обратиться напрямую к объекту метаданных. Разберем, как это сделать программно:
Для Каждого СправочникИзМетаданных Из Метаданные.Справочники Цикл
ИмяСправочника = СправочникИзМетаданных.Имя;
Для Каждого ПредопределенныйЭлемент Из СправочникИзМетаданных.Предопределенные Цикл
ИмяЭлемента = ПредопределенныйЭлемент.Имя;
// Здесь мы формируем массив или соответствие для дальнейшего поиска
Сообщить("Найдено предопределенное имя: " + ИмяСправочника + "." + ИмяЭлемента);
КонецЦикла;
КонецЦикла;
Этот подход позволяет нам составить полный реестр имен. На основе этого реестра мы можем построить более точные регулярные выражения для поиска в выгруженных файлах конфигурации.
Для автоматизации (например, в Jenkins) наиболее эффективным способом является выгрузка конфигурации в текстовые файлы. Рассмотрим этот процесс по шагам:
/DumpConfigToFiles..bsl (тексты модулей) и .xml (описания форм и метаданных).Важно учитывать структуру файлов. Обращения в коде будут выглядеть как текст, но предопределенные элементы также могут быть жестко привязаны в схемах компоновки данных (СКД) или настройках отчетов. Проанализируем пример регулярного выражения для поиска конструкции ЗНАЧЕНИЕ в запросах:
ЗНАЧЕНИЕ\(Справочник\.[A-zА-я0-9_]+\.[A-zА-я0-9_]+\)
Если задача требует высокого качества анализа без «наколенных» скриптов, следует рассмотреть среду 1C:EDT (Enterprise Development Tools). В отличие от Конфигуратора, EDT строит полный семантический индекс проекта. Рассмотрим подробнее механизм Find Usages:
Если вы выберете предопределенный элемент в дереве метаданных EDT и вызовете команду «Найти ссылки», среда покажет вам не просто совпадения строк, а именно логические обращения в коде. Это работает даже в сложных случаях, где текстовый поиск может ошибиться.
Для целей автоматизации (CI/CD) идеально подходит BSL Language Server (BSLLS). Выясним, почему это решение является стандартом в крупной разработке:
Иногда обращения к предопределенным элементам формируются динамически, например: ПредопределенноеЗначение("Справочник." + ИмяОбъекта + "." + ИмяЭлемента). Статический анализ такие случаи может пропустить. Разберем, как можно использовать возможности платформы для обнаружения таких вызовов в тестовой базе:
Мы можем создать расширение, которое перехватывает вызовы в критических узлах или использует журнал регистрации. Однако более надежным способом будет анализ общего модуля СтандартныеПодсистемыСервер, а именно процедуры ВосстановитьПредопределенныеЭлементы. Проанализируем ее содержимое, чтобы понять, как БСП работает с обновлением этих данных — это часто дает подсказки о том, какие элементы реально используются в логике конфигурации.
Когда конфигурация весит несколько гигабайт в распакованном виде, обычный поиск может занять часы. Профессиональные разработчики используют утилиту Ripgrep (rg). Посмотрим на пример команды для Jenkins-скрипта, которая мгновенно найдет все упоминания справочника «Номенклатура» в контексте предопределенных данных:
rg "Справочник\.Номенклатура\." --type-add 'bsl:*.bsl' -t bsl
Эта утилита работает на порядок быстрее стандартных средств поиска Windows или встроенных средств многих IDE, поддерживая при этом корректную работу с кодировками 1С (UTF-8 без BOM).
Мы рассмотрели несколько подходов к поиску обращений. Выбор метода зависит от ваших целей:
Помните, что предопределенные элементы — это связь метаданных и данных, поэтому их поиск требует внимательного отношения как к коду модулей (BSL), так и к описаниям метаданных и запросам.