Граф вызовов с точностью до модуля

Когда ассистент отвечает на вопрос «кто вызывает эту процедуру», важно не просто найти строчку с похожим именем — важно понять, о какой именно процедуре в каком именно модуле идёт речь. В типовых конфигурациях 1С процедур с одинаковыми именами — десятки, и разбросаны они по разным менеджерам объектов. one-s-mcp строит карту вызовов с точностью до конкретной процедуры и функции, а не по совпадению текста, — и делает это локально, на вашей машине.

Какую боль решает

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

Вторая, более коварная проблема — одноимённые методы. В крупных типовых конфигурациях сплошь и рядом встречаются процедуры с одинаковым названием в разных модулях: своя ЗаполнитьПоУмолчанию() у справочника «Номенклатура», своя — у справочника «Контрагенты», своя — у документа «ЗаказПокупателя». Обычный текстовый поиск по имени метода не различает эти методы между собой — он находит все вхождения строки «ЗаполнитьПоУмолчанию» по всей конфигурации, не разбирая, к какому объекту какой вызов относится. В итоге либо ассистент, либо сам разработчик рискует сделать ложный вывод: «эта функция вызывается отсюда» — хотя на самом деле вызывается совсем другая функция с тем же именем из другого модуля. Чем крупнее типовая, тем больше таких «однофамильцев» и тем дороже обходится ошибка: доработка, сделанная по неверному следу, может задеть не тот участок кода.

Отдельная задача — расследование чужого кода в большой базе. Нужно понять не только «кто зовёт меня», но и «кого зову я» — то есть всю цепочку вызовов конкретной процедуры в обе стороны: обработчики форм, подключаемые команды, подписки на события, вызовы из других модулей. Руками это долгие часы чтения кода и переключения между процедурами по всей конфигурации, особенно если вы видите базу впервые и не знаете, где искать точку входа.

Как это работает

Ассистент видит не только список объектов конфигурации, но и карту их связей: кто кого вызывает, кто кому подчинён, какой документ пишет в какой регистр. Эта карта строится в отдельном модуле — сервере связей метаданных, — который берёт уже разобранную структуру конфигурации (её готовит сервер поиска по коду и метаданным) и складывает все связи в специальную графовую базу прямо на машине клиента. Повторно разбирать XML-выгрузку конфигурации не нужно — граф собирается из уже готовых данных.

Ключевая деталь — как именно строятся связи вызовов. При сборке графа создаётся индекс соответствия «модуль + имя процедуры → конкретная процедура». Вызовы вида РегистрыСведений.Имя.Метод(), Справочники.Имя.Метод(), Отчёты.Имя.Метод() и аналогичные им сопоставляются с менеджер-модулями объектов всех видов — не только справочников и документов, но и регистров, отчётов, обработок, бизнес-процессов и других. Связь между двумя процедурами фиксируется в графе, только если такая процедура действительно существует в этом конкретном модуле, — это отсекает случайные текстовые совпадения и снижает число ложных следов.

Именно поэтому граф различает «однофамильцев»: если в базе есть ЗаполнитьПоУмолчанию() и у справочника «Номенклатура», и у справочника «Контрагенты», ассистент видит это как два разных узла графа с разными связями, а не как одну размытую сущность. Спросите «кто вызывает эту процедуру у справочника Номенклатура» — и в ответе будут только реальные вызовы именно этого метода, без примеси однофамильцев из других модулей. То же самое касается менеджеров отчётов, обработок, бизнес-процессов — резолюция вызовов работает одинаково для всех видов объектов, а не только для справочников и документов.

В граф попадают не только вызовы процедур и функций, но и вся структура конфигурации целиком: объекты, формы, команды, подсистемы, подписки на события, связи документов с регистрами, владение подчинённых справочников, перехваты процедур типовой из расширений (&Перед/&После/&Вместо). Обход графа можно делать «от объекта» — что заденет правка справочника или документа целиком, — а можно «от процедуры»: вся цепочка вызовов от конкретной функции, включая обработчики форм, команды и перехваты расширений. Каждый шаг в ответе помечен происхождением связи и уровнем уверенности, так что видно не только сам факт связи, но и откуда она взялась — это не безликий список совпадений, а прослеживаемая цепочка.

На практике это выглядит как обычный вопрос ассистенту в диалоге: «кто вызывает функцию РассчитатьСкидку в модуле объекта документа ЗаказПокупателя» или «покажи всю цепочку вызовов от процедуры ОбработкаПроведения этого документа». Ассистент обходит граф и отвечает конкретными именами модулей и процедур — без «где-то в конфигурации есть похожая функция».

Собирается всё локально, во встроенной графовой базе. Структура вашей конфигурации не покидает машину — это особенно важно, если работа ведётся с базой под NDA. После каждой переиндексации структуры граф пересобирается заново без обращения к нейросети, а на крупных типовых конфигурациях (например, на полной «Бухгалтерии») сборка укладывается в минуты — связи загружаются массово, нативным способом, а не вставляются по одной.

Что это даёт

• Ассистент не путает однофамильцев. В базе с десятками процедур ОбработкаПроведения() или ПриЗаписи() в разных модулях ответ на вопрос «кто вызывает эту функцию» относится строго к нужной процедуре нужного объекта, а не ко всем совпадениям по имени.
• Расследование чужого кода занимает минуты, а не часы. Вопросы «кто меня вызывает» и «кого вызываю я» по конкретной процедуре — это точный обход графа, а не ручной просмотр «Поиска ссылок» и не текстовый grep по конфигурации.
• Видны перехваты из расширений. Граф знает, где какое расширение перехватывает процедуру типовой (&Перед/&После/&Вместо) — при доработке базы с расширениями меньше сюрпризов.
• Быстрые точные справки по структуре. Состав подсистемы, подписки на конкретное событие, цепочка владения подчинённого справочника, какие документы пишут в регистр и по каким регистрам пишет документ — всё это простые точные обходы по готовому графу, без ручного копания в метаданных и без риска что-то упустить.
• Работает на боевых типовых, а не только на демо-базах. Раньше сборка графа на крупных конфигурациях (вроде полной «Бухгалтерии») упиралась в медленную вставку миллионов связей и могла занимать часы — сейчас, после перехода на массовую нативную загрузку связей, сборка укладывается в минуты. Это значит, что граф реально применим к боевой базе, а не только к учебному примеру на пять объектов.
• Меньше ручной рутины при рефакторинге. То, что раньше делалось через «Поиск ссылок на объект» в конфигураторе плюс ручное чтение кода найденных модулей, теперь укладывается в один вопрос ассистенту на естественном языке.

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

Честно об ограничениях

Сборка карты связей — видимая операция, а не невидимый фон: у неё свой прогресс, при закрытии окна приложение её дожидается, а не бросает на полпути. Если сборка всё-таки сорвалась, это видно в карточке базы, и рядом стоит кнопка «пересобрать». Устаревший граф помечается как устаревший, а на пустом — модуль честно отказывает, вместо того чтобы отвечать «связей нет». Разница здесь принципиальная: пустой ответ и «нечего показать» — не одно и то же, а вывод «на это никто не ссылается, можно менять» не должен оказаться ловушкой. Если роль, подписку или подсистему прочитать не удалось, это тоже называется прямо.

Граф вызовов не всесилен — у него есть один системный пробел. Если имя процедуры или объекта вычисляется динамически, в переменной, и вызывается через «Выполнить» или «Вычислить», такую связь граф установить не может в принципе: на этапе сборки графа неизвестно, какая именно строка окажется в переменной во время выполнения. Это редкий, но встречающийся в 1С паттерн, и его стоит держать в уме при расследовании.

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

Ещё важно понимать, о чём граф — а о чём нет. Он про структуру конфигурации: какие объекты, модули и процедуры существуют и как они связаны между собой. Он не про данные — какие записи лежат в справочниках и документах конкретной базы, граф не хранит и не показывает.

Источником для графа служит XML-выгрузка конфигурации — та же, которую приложение готовит при индексации. Граф не читает .cf-файл и не подключается напрямую к боевому кластеру.

Что дальше

Хотите увидеть, как ассистент отвечает на вопросы «кто вызывает» и «кого вызывает» по вашей собственной конфигурации, без единого ложного однофамильца? Скачайте one-s-mcp и подключите его к базе. Полный список того, что умеет ассистент, — на странице Все возможности.