Анализ влияния изменений

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

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

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

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

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

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

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

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

• кто зависит от объекта (обход вверх) — кто на него ссылается, вызывает, перехватывает;
• от чего зависит сам объект (обход вниз) — что он использует и от чего зависит его работа;
• сразу в обе стороны, если нужна полная картина.

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

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

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

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

Что это даёт

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

Механизм устройства самих вызовов — «кто кого зовёт» как отдельная карта — разобран в статье про граф вызовов. Анализ влияния использует ту же основу, но отвечает именно на вопрос «что заденет изменение», а не просто перечисляет связи.

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

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

Что дальше

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