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

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

Именно для поиска таких случаев я начал делать отдельный Анализатор совместимости расширений 1С.

Почему одного факта «расширение подключилось» недостаточно

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

Самый простой случай — расширение вообще перестало применяться. Это хорошо заметно: 1С сама сообщает об ошибке.

Сложнее, когда расширение применяется, но внутри него осталось обращение к удалённому общему модулю, реквизиту, форме или другому объекту метаданных. Такие проблемы уже приходится искать глубже.

Но есть ещё один класс ошибок.

Например, в расширении заимствована процедура типовой конфигурации и в неё добавлен собственный код:

через &Вставка;

через &ИзменениеИКонтроль;

через другие механизмы расширения;

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

После обновления типовой конфигурации сама процедура может измениться. Она всё ещё существует. Расширение может формально применяться. Код может даже компилироваться.

Но наша вставка уже относится к старой версии процедуры.

Именно такие изменения особенно опасны: формальной ошибки ещё нет, а расширение уже требует ручной проверки.

С чего всё началось

До Анализатора я сделал самостоятельную внешнюю обработку 1C Extension Checker 2.0.

Она запускается непосредственно в 1С и предназначена прежде всего для оперативной проверки базы после обновления.

Checker умеет:

проверять применимость расширений;

выполнять проверку серверной доступности;

проводить безопасный smoke-тест форм;

классифицировать найденные проблемы;

формировать отчёты в TXT, HTML и JSON;

работать без изменения данных информационной базы.

Для быстрой проверки непосредственно в рабочей базе этого достаточно.

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

Для этого и появился Анализатор.

Что делает Анализатор

Идея Анализатора состоит не в том, чтобы ещё раз выполнить обычную проверку конфигурации.

Его задача — сопоставить изменения типовой конфигурации с тем, что используется и изменяется в расширениях.

Упрощённо процесс выглядит так:

1. Есть состояние конфигурации ДО обновления.

2. Есть состояние конфигурации ПОСЛЕ обновления.

3. Анализатор определяет, какие объекты и модули изменились.

4. Затем он смотрит, какие из этих объектов используются расширениями.

5. Для таких мест определяется уровень риска и необходимость ручной адаптации.

То есть основной вопрос уже другой:

Не просто «есть ли ошибка?», а «изменилось ли то место типовой конфигурации, от которого зависит наш код?»

Пример

Допустим, в расширении заимствована процедура типовой конфигурации:

&ИзменениеИКонтроль("НекотораяПроцедура")
Процедура Расш1_НекотораяПроцедура(...)

// типовой код

#Вставка
НашаДополнительнаяЛогика();
#КонецВставки

// типовой код

КонецПроцедуры

В новой версии конфигурации разработчики 1С изменили НекотораяПроцедура.

При обычной проверке возможны два варианта.

Если изменение несовместимо технически — мы получим явную ошибку.

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

Анализатор должен отметить такое место как требующее адаптации: базовая процедура изменилась после обновления, а расширение вмешивается в её работу.

Почему это важнее обычного сравнения файлов

Простой diff показывает, что текст двух модулей отличается.

Но разработчику расширений этого недостаточно.

Если в общем модуле изменилось десять процедур, а расширение использует только одну из них, интересует именно эта одна процедура.

Поэтому задача Анализатора — перейти от сравнения файлов к сравнению на уровне объектов 1С и участков программного кода.

В перспективе результат должен выглядеть примерно так:

объект конфигурации изменён;

модуль изменён;

процедура или функция изменена;

процедура используется расширением;

способ вмешательства расширения;

уровень риска;

причина попадания в отчёт.

Категории результатов

Здесь я сохраняю подход, который уже показал себя в Checker.

Результаты не должны превращаться в длинный список одинаковых сообщений.

Разработчику важнее сразу понимать приоритет.

Поэтому найденные ситуации разделяются по смыслу.

Критично — обнаружена проблема, которая уже мешает нормальной работе или требует обязательного исправления.

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

Предупреждение — потенциально опасная конструкция или зависимость, которая требует внимания.

Не проверено — участок, для которого автоматического вывода недостаточно.

На практике именно категория «Адаптация» может оказаться самой полезной. Она показывает не уже произошедшую аварию, а места, где обновление могло незаметно изменить смысл работы расширения.

Checker и Анализатор — это разные инструменты

Я не стал превращать Checker в огромный комбайн.

1C Extension Checker 2.0 остаётся самостоятельной внешней обработкой .epf, которую можно открыть непосредственно в 1С и быстро проверить текущую базу.

Анализатор — отдельный инструмент для более глубокого анализа изменений между версиями.

У них разные задачи:

Вместе получается двухуровневая схема проверки.

Сначала Анализатор показывает, какие изменения конфигурации потенциально затрагивают расширения.

После установки обновления Checker проверяет уже фактическое состояние информационной базы.

Без LLM на первом этапе

Для первой версии я сознательно не делаю LLM основой анализа.

Определение факта изменения объекта, процедуры, функции, зависимости или вмешательства расширения должно быть детерминированным.

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

LLM здесь имеет смысл использовать позднее как дополнительный слой.

Например, он сможет:

объяснять найденное изменение человеческим языком;

оценивать смысл изменения процедуры;

помогать понять, влияет ли изменение на вставленный код;

предлагать разработчику, что проверить в первую очередь;

формировать краткое заключение по большому отчёту.

Но решение «изменился объект или нет» и базовая карта зависимостей не должны зависеть от ответа нейросети.

Отчёт должен быть полезен разработчику

Цель проекта — не получить ещё один красивый список изменений конфигурации.

После анализа разработчик должен иметь возможность открыть отчёт и сразу увидеть:

1. какое расширение требует внимания;

2. какой объект типовой конфигурации изменился;

3. какая процедура или функция затронута;

4. почему Анализатор считает это место потенциально опасным;

5. что необходимо проверить вручную.

В дальнейшем такой отчёт можно использовать как чек-лист при подготовке расширений к новой версии конфигурации.

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

Что это должно дать на практике

Обычный сценарий обновления сейчас часто выглядит так:

1. обновили тестовую базу;

2. увидели ошибки применения расширений;

3. исправили очевидные проблемы;

4. открыли основные формы;

5. проверили критичные сценарии;

6. надеемся, что ничего менее заметного не пропустили.

С Анализатором между обновлением конфигурации и ручным тестированием появляется ещё один слой контроля.

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

Это не отменяет тестирование.

Но ручная проверка становится направленной.

Текущее состояние проекта

Сейчас Анализатор рассматривается как следующий уровень после уже работающего 1C Extension Checker 2.0.

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

Сам Checker при этом остаётся отдельным законченным инструментом и не требует Анализатора для своей работы.

Анализатор также проектируется как отдельное приложение с GUI и возможностью автоматизировать анализ через командный режим.

Что будет дальше

Анализатор не считаю законченным продуктом.

Он будет дорабатываться по мере проверки на реальных конфигурациях и реальных расширениях.

В ближайших версиях планируется развивать:

более точный анализ изменений процедур и функций;

выявление зависимостей между изменённым типовым кодом и расширениями;

более подробную классификацию причин, по которым требуется адаптация;

снижение ложных срабатываний;

удобную навигацию от результата к конкретному объекту и участку кода;

сохранение и сравнение результатов между версиями;

развитие форматов отчётов;

автоматизацию подготовки данных для анализа;

пакетную проверку нескольких расширений;

дополнительный AI-слой для объяснения сложных изменений, но не вместо детерминированного анализа.

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

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

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