Что сломается в конфигурации 1С, если я удалю процедуру, регистр, константу или реквизит?

Разработчик собирается удалить процедуру общего модуля, регистр или константу, а «Поиск ссылок» показывает только часть мест. Я написала инструмент, который строит граф зависимостей по выгрузке конфигурации, и проверила его на семи изменениях с заранее записанным ручным ответом. Потом сделала те же изменения в копиях выгрузки и загрузила их в платформу, с расширенной проверкой модулей и без неё.

Стенд

Это одна небольшая конфигурация. Она не позволяет судить о скорости или полноте на УТ 11 или ERP, где объектов на порядки больше.

Что строит инструмент

Инструмент читает выгрузку «в файлы» и записывает связи «кто что использует». Узлы графа: процедуры, объекты метаданных, реквизиты, значения перечислений, формы. Каждая связь хранит файл, строку, тип и уверенность. Уверенность «точно» означает связь, которая прямо написана в тексте или XML. «По имени» означает совпадение строки или имени свойства; такая связь может оказаться ложной.

На выгрузке стенда получилось 1688 связей: 1480 точных и 208 по имени.

Запрос выглядит так:

1

python impact.py stand/src proc:ТоварыУчет.Движение --depth 3

Результат на глубине 1 для этой процедуры:

Глубина 2 добавляет УчетСервер.Пересчитать, глубина 3 доходит до обработчиков документов: 28 записей, обработка проведения и отмены проведения у каждого из 14 документов. Это число я сверила поиском по тексту: вызов УчетСервер.Пересчитать встречается в модулях объектов 28 раз.

Рядом с графом инструмент печатает предупреждения о динамических конструкциях. В этой выгрузке их 35: 17 раз Метаданные() у переменной, 12 раз имя объекта дописывается к тексту запроса, 4 раза менеджер выбирается по имени из переменной, 2 раза перебор коллекции метаданных. Вызовов Выполнить или Вычислить со строкой кода в выгрузке нет; что инструмент делает с таким кодом, показано в разделе «Пределы».

Семь изменений и ручной ответ

Изменения выбирала заранее, чтобы часть из них была простой, а часть опиралась на динамику. Для каждого записала список позиций, которые затрагивает изменение. Позиция - пара «файл, процедура», для XML - файл. Configuration.xml не считала: он меняется при любом добавлении или удалении объекта.

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

Что нашёл граф

Подсчёт на глубине 1, то есть прямое использование:

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

Где граф ошибся

Имя регистра хранится в списке

Модуль ДвиженияУчета хранит имена регистров списком строк и дальше обращается к ним по имени:

1
2
3

Функция Регистры() Экспорт
    Результат = Новый Структура;
    Для Каждого Имя Из СтрРазделить("ТоварыНаСкладах,РезервыТоваров,ЗаказыКлиентов,ЗаказыПоставщикам,РасчетыСКлиентами,РасчетыСПоставщиками,ДенежныеСредства,Продажи", ",") Цикл

1
2

        Если ТипРегистра = "Накопления" Тогда
            Набор = РегистрыНакопления[Группа.ИмяРегистра].СоздатьНаборЗаписей();

Строка со списком попала в граф как связь «по имени»: в Регистры найдены все восемь регистров. Процедуры Записать и СтарыеРегистраторы берут имя из результата Регистры() и своего имени регистра в тексте не содержат. На глубине 1 граф их пропустил (S3 и S3b). Они появляются на глубине 2 как вызывающие Регистры, и при глубине 2 S3 находит все 23 позиции. Точность при этом падает до 92%: в список попадают вызывающие процедуры УчетСервер.Пересчитать и ОтчетыСервер.Сформировать, которых в прямом ручном ответе нет.

Имя регистра передано параметром

В ЗаказыУчет процедура ДвижениеЗаказа получает имя регистра аргументом и передаёт его дальше:

1
2

Процедура ДвижениеЗаказа(Состояние, Событие, ИмяРегистра, Заказ, Товар, Количество, Сумма, ЭтоПриход)
    СостояниеУчета.ДобавитьДвижение(Состояние, ИмяРегистра, Событие.Ссылка, Событие.Дата,

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

Одноимённый отчёт и ключ состояния

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

Для строки без типа определить, что она называет: регистр или отчёт, инструмент не может. Он помечает такую связь как «по имени», и читателю остаётся решить самому.

Перебор реквизитов в цикле

Для S5 граф нашёл форму, привязанную к реквизиту через DataPath, и две процедуры, где написано .НулеваяЦенаПодтверждена. Четвёртую позицию он не увидел:

1
2
3
4
5
6

Функция Нормализовать(Документ) Экспорт
    Мета = Документ.Метаданные();
    Данные = Новый Структура;
    Для Каждого Реквизит Из Мета.Реквизиты Цикл
        Данные.Вставить(Реквизит.Имя, Документ[Реквизит.Имя]);
    КонецЦикла;

Здесь реквизит не назван ни одной строкой, его имя берётся из метаданных во время работы. Если переименовать реквизит, Нормализовать продолжит работать, а в ТоварыУчет.СводТоваров обращение Событие.Данные.НулеваяЦенаПодтверждена сломается. Граф покажет вторую процедуру и не покажет первую.

Выгрузка, сделанная самой платформой

Выгрузка стенда лежит в репозитории готовой. Чтобы проверить, что граф к ней не привязан, я загрузила её в базу и выгрузила обратно командой DESIGNER /DumpConfigToFiles (код 0, 20,4 с). Платформа записала 270 файлов вместо 293: 24 пустых модуля в выгрузку не попали, зато появился ConfigDumpInfo.xml.

Те же семь запросов дали на этой выгрузке 66 найденных позиций из 72, верных 63: полнота 88%, точность 95%. Всё отличие связано с одной ролью. В выгрузке платформы у роли «Администратор» нет перечня объектов, потому что права заданы по умолчанию. Правок в этой роли при удалении регистра или константы не будет, и граф её не называет. В ручном ответе, составленном для stand/src, эта роль есть. Остальные результаты не изменились.

Что сказала платформа

Каждое из семи изменений я внесла в копию выгрузки, создала новую файловую базу, загрузила выгрузку через /LoadConfigFromFiles и запустила /CheckModules -ThinClient -Server -ExternalConnection два раза: обычный и с ключом -ExtendedModulesCheck. Если загрузка останавливалась на XML (S3, S3b, S5, S7), я вручную убирала из XML ссылки на удалённое или переименованное (записи движений документов, права ролей, привязки полей форм) и повторяла прогон, чтобы проверка дошла до BSL. Для контроля прогнала выгрузку без изменений и переименование ТоварыУчет.Остаток: эту функцию зовут три процедуры своего модуля и одна процедура ЗаказыУчет.

Что из этого следует:

1. Обычный режим находит вызов удалённой процедуры только внутри её модуля. Между модулями он не увидел два вызова в S1 и семь процедур в S2. В прошлой проверке висячих вызовов на той же выгрузке картина была такой же: без ключа платформа нашла 13 вызовов из 69, с ключом 64.
2. Ключ добавляет сообщения «Возможно ошибочный метод» и «Возможно ошибочное свойство». В S1, S2, S4 и S6 число сообщений совпало с числом обращений в BSL (2, 8, 4 и 4), а набор модулей совпал с набором модулей в моём ручном ответе. Процедуру и строку платформа с этим ключом не называет, только модуль и имя. Ложных сообщений на выгрузке без изменений нет.
3. Ни один режим не читает строки и тексты запросов. После ручной чистки XML удалённые регистры (S3 и S3b) и переименованные реквизиты (S5 и S7) прошли без сообщений, хотя в BSL осталось шесть процедур с Продажи, девять с ЗаказыКлиентов и три с НулеваяЦенаПодтверждена.
4. Структуру XML платформа проверяет жёстко: пока в документах оставалась запись движений по удалённому регистру, загрузка завершалась кодом 1 и проверка модулей не запускалась. Сообщения не называют документ, и в S3 к ним добавлено ещё 18 строк «Ни один из документов не является регистратором для регистра» про соседние регистры. После ручной чистки XML исчезли и они.
5. Для удалённой константы загрузка вывела три строки «Неизвестный объект метаданных - Constant.НаименованиеОрганизации» и завершилась кодом 0. После удаления константы это имя осталось только в Rights.xml трёх ролей (Администратор, Оператор, Чтение), но файлы ролей в сообщениях не названы.

Граф и платформа рядом

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

Для S1, S2 и S4 платформа с ключом называет те же модули, что и граф. Граф добавляет процедуры и строки, вызывающую цепочку (в S1 до 28 обработчиков документов), роли и подсистемы: в S6 три роли с правом на константу платформа не назвала. Платформа добавляет то, чего граф не умеет: проверку собранной конфигурации после изменения, то есть загрузку XML и синтаксис.

Граф запускается до правки за 0,83 с без базы и лицензии. Полный прогон платформы с создаваемой базой и двумя проверками занимал в моих запусках от 21 до 145 с; на компьютере параллельно работали другие программы, поэтому эти времена годятся только как порядок величины.

Поиск реквизита по имени: пример «Склад»

Реквизит документа можно искать только по имени свойства, типов в BSL инструмент не знает. Как это выглядит, показал S7: переименование ПродажаТовара.Склад.

Платформа при загрузке назвала три файла форм: форму объекта, форму списка и форму выбора. Две последние используют колонку Список.Склад, и мой инструмент поначалу эти формы не нашёл: он понимал только Объект.Склад. Я добавила разбор колонок списка, и теперь граф называет те же три формы с уверенностью «точно». После моей ручной правки привязок полей в этих формах загрузка прошла, а проверка модулей в обоих режимах не вывела ни одного сообщения.

По имени в BSL граф вернул ещё 20 записей. Элемент с именем «Склад» есть в описании 13 объектов: 9 документов, 3 регистров накопления и 1 регистра сведений. Из 20 записей 10 относятся к процедурам общих модулей и 10 к модулям форм отчётов. Какие из 20 записей касаются именно документа «Продажа товара», по списку не определить: нужна ручная проверка каждой. Поэтому S7 в подсчёт полноты и точности не входит. Платформа по BSL промолчала.

Для реквизита с редким именем поиск по имени работает хорошо: у НулеваяЦенаПодтверждена он вернул две процедуры, обе по делу. Для общего слова результат это длинный список кандидатов.

Пределы

Инструмент не видит:

• Код, собранный в строке и выполненный через Выполнить или Вычислить. В выгрузке стенда такого кода нет. В тесте на искусственном примере инструмент выдаёт предупреждение и не добавляет вызов в граф.
• Имя объекта, составленное из частей. Связь появляется, только если строка с этим именем стоит где-то рядом.
• Реквизиты, к которым обращаются через переменную без типа или перебором (Документ[Реквизит.Имя]).
• Имя регистра или процедуры, переданное параметром в другую процедуру.
• Расширения конфигурации, перехваты, общие реквизиты, параметры сеанса, регламентные задания, HTTP- и веб-сервисы, макеты, схемы компоновки. Эти части выгрузки не разбираются.
• Роли с правами по умолчанию. В выгрузке платформы у роли «Администратор» нет перечня объектов, и граф такую роль не называет.
• Подписки на события: разбор написан по формату XML и проверен на искусственном примере. В выгрузке «Нано-УТ» подписок нет, поэтому на рабочей конфигурации этот код не испытан.
• Совместимость изменения. Если поменять тип параметра или порядок аргументов, инструмент назовёт вызывающие места, а оценивать их не будет.

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

Что проверить у себя

1. Выгрузите конфигурацию в файлы: 1cv8.exe DESIGNER /F <база> /DumpConfigToFiles <каталог>.
2. Запросите граф для объекта, который собираетесь менять: python impact.py <каталог> meta:Вид.Имя --depth 2 --warnings.
3. Пройдите глазами записи «по имени» и предупреждения о динамике, которые относятся к процедурам из списка.
4. Внесите изменение в копию выгрузки, создайте новую файловую базу (CREATEINFOBASE File=...), загрузите копию через /LoadConfigFromFiles и запустите /CheckModules -ThinClient -Server -ExternalConnection два раза: без ключа и с -ExtendedModulesCheck.
5. Сравните сообщения платформы со списком графа. Расхождения проверьте вручную: именно там скрыта динамика.

Файл к статье

В архиве impact-18-3-companion.zip находятся: impact.py, evaluate.py с ручным ответом, platform_experiment.py и compare_platform.py для опыта на платформе, выгрузка стенда stand/src, тесты с искусственной выгрузкой, README и журналы запусков. Тесты работают без платформы 1С. Из корня распакованного архива:

1
2
3

python -m unittest discover -s tests -v
python evaluate.py stand/src --lists
python impact.py stand/src meta:AccumulationRegister.Продажи --depth 2

В тестах 14 проверок: 13 на искусственной выгрузке и одна сверяет цифры этой статьи на выгрузке стенда; в моём прогоне все проходят. Опыт с платформой запускается командой python platform_experiment.py stand\src work S1 S2 S3 и требует установленную платформу 8.3.27 и свободную лицензию для Конфигуратора. Если у вас другой каталог платформы, задайте переменную ONEC_BIN.

Итог

Граф зависимостей по выгрузке хорошо работает там, где связь написана в тексте: вызов между модулями, значение перечисления, константа, запрос с именем объекта. Он дал 66 верных позиций из 72 и 3 лишних, а промахи сосредоточились там, где имя прячется в строке, параметре или цикле. Платформа без ключа проверила структуру XML и вызовы внутри модуля, а удаление функции общего модуля, значения перечисления и константы для неё осталось незамеченным. С ключом -ExtendedModulesCheck она назвала модули для этих трёх видов изменений, но не процедуры и строки, и промолчала про регистры в строках и про реквизиты в коде.

Практический порядок получается такой: сначала запросить граф и пройти глазами список, включая записи «по имени» и предупреждения о динамике; затем внести изменение, загрузить выгрузку в платформу и запустить /CheckModules с ключом и без него. Если граф и платформа ничего не нашли, это не доказательство отсутствия связей: шесть пропусков остались у графа в S3, S3b и S5, а платформа пропустила регистры и реквизиты целиком.

Выводы относятся к одной небольшой учебной конфигурации, версии платформы 8.3.27.2130 и ручной разметке, которую составляла я сама. На УТ 11 и ERP, на расширениях и на коде с Выполнить инструмент не проверялся.

 

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

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

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

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