При обновлении сильно измененных нетиповых конфигураций, особенно при переходе через несколько релизов сразу, разработчики часто сталкиваются с проблемой "битых" ссылок в запросах и синтаксических ошибок в модулях. Ручная проверка каждого измененного объекта — процесс трудоемкий и подверженный человеческому фактору. Рассмотрим способы, как можно автоматизировать этот процесс, начиная от стандартных средств платформы и заканчивая продвинутыми инструментами статического анализа.
Самый простой и доступный метод проверки синтаксиса программных модулей — это использование встроенных возможностей конфигуратора. Мы можем запустить процесс проверки программно, не открывая визуальный интерфейс. Для этого проанализируем возможности командной строки. Пакетный запуск позволяет инициировать синтаксический контроль всей конфигурации и выгрузить результат в текстовый файл.
Рассмотрим пример команды для запуска:
1cv8.exe DESIGNER /F "ПутьКБазе" /N "Логин" /P "Пароль" /CheckConfig /Out "C:\log.txt"
В данном случае параметр /CheckConfig инициирует проверку конфигурации. Однако стоит помнить, что этот метод проверяет только синтаксис языка 1С, но зачастую "пропускает" ошибки в текстах запросов, если они написаны в виде простых строк.
Для более глубокого анализа запросов, которые могут сломаться при удалении или переименовании полей метаданных в новом релизе, воспользуемся объектом СхемаЗапроса. Этот объект предназначен для программного построения и разбора текста запроса. При попытке загрузить некорректный текст в схему, платформа сгенерирует исключение, которое мы можем перехватить.
Разберем алгоритм автоматизированной проверки:
Новый Запрос("...").СхемаЗапроса.Проанализируем пример кода для такой проверки:
Процедура ПроверитьТекстЗапроса(ТекстЗапроса)
Схема = Новый СхемаЗапроса;
Попытка
Схема.УстановитьТекст(ТекстЗапроса);
Сообщить("Запрос корректен");
Исключение
Сообщить("Ошибка в запросе: " + ОписаниеОшибки());
// Здесь можно логировать текст запроса и место его нахождения
КонецПопытки;
КонецПроцедуры
Важно отметить, что такой метод эффективен только для "цельных" запросов. Если запрос собирается динамически через СтрЗаменить или конкатенацию строк, СхемаЗапроса не сможет его распарсить без предварительной подстановки параметров. В таких случаях мы рекомендуем сравнивать поведение запроса в "старой" рабочей базе и "новой" обновленной. Если в обеих базах запрос не парсится — это ожидаемое поведение динамического кода. Если же в старой он был валиден, а в новой вызывает ошибку — мы нашли проблему.
Современный подход к качеству кода подразумевает использование инструментов статического анализа. Одним из самых мощных решений является BSL Language Server, также можно использовать статический анализатор кода проектов на самой платформе 1С. Он позволяет проверять код без необходимости запуска платформы 1С. Рассмотрим преимущества этого подхода:
Проанализируем ситуацию: при обновлении в типовом решении был удален реквизит, который использовался в вашем доработанном модуле. Стандартная синтаксическая проверка может не увидеть ошибку, если обращение идет через ЭтотОбъект["ИмяРеквизита"], но статический анализатор, настроенный на правила метаданных, подсветит это место как потенциально опасное.
Для того чтобы не писать сложные обработки внутри самой 1С, мы можем воспользоваться OneScript — реализацией языка 1С вне платформы. Существуют готовые библиотеки, такие как add (автоматизация деплоя и разработки), которые позволяют автоматизировать выгрузку конфигурации в исходники и запуск тестов.
Посмотрим, как может выглядеть сценарий автоматизации:
gitsync (используя встроенный или сторонний распаковщик конфигураций), чтобы получить изменения между старым и новым релизом в виде файлов..bsl.Иногда синтаксической корректности недостаточно. Запрос может быть верным с точки зрения структуры, но падать при выполнении из-за прав доступа или пустых значений. Здесь на помощь приходят дымовые тесты. Мы можем написать универсальную обработку, которая будет обходить все добавленные объекты и пытаться:
Выясним причину популярности этого метода: он позволяет найти "горящие" ошибки сразу после объединения, не дожидаясь этапа функционального тестирования пользователями. Если форма не открывается из-за ошибки в ПриСозданииНаСервере, тест зафиксирует это мгновенно.
Наибольшую сложность представляют запросы, собираемые "из кусков". Рассмотрим, как упростить их проверку:
Во-первых, старайтесь минимизировать использование СтрЗаменить для модификации условий ГДЕ. Вместо этого лучше использовать возможности объекта СхемаЗапроса для программного добавления условий или временных таблиц. Это сделает код более прозрачным для автоматизированных инструментов.
Во-вторых, на этапе отладки можно внедрить механизм логирования итоговых текстов запросов. Если система в процессе работы записывает каждый сформированный текст Запрос.Текст в специальный журнал, мы сможем позже прогнать эти тексты через пакетный валидатор и убедиться, что изменения в структуре базы данных их не сломали.
Автоматизация проверки — это не замена разработчика, а инструмент, позволяющий сфокусироваться на сложной бизнес-логике, делегировав поиск опечаток и "битых" запросов машине. Мы рекомендуем комбинировать методы: использовать пакетный запуск конфигуратора для быстрой проверки, СхемуЗапроса для анализа текстов внутри модулей и статический анализ для соблюдения общих стандартов качества кода.