При сопровождении доработанных типовых конфигураций 1С программисты часто сталкиваются с проблемой: после очередного обновления конфигурации часть кода перестает работать, так как вызываемые типовые функции были переименованы, удалены или помечены как устаревшие. Обычная проверка модулей не всегда выявляет такие зависимости, особенно если функции находятся в других общих модулях. Рассмотрим подробнее, какие инструменты и методики позволяют автоматизировать контроль качества кода и вовремя обнаруживать "проблемные" места.
Многие разработчики привыкли пользоваться стандартной проверкой (Ctrl+F7), которая проверяет только текущий модуль на наличие синтаксических ошибок. Однако для поиска ссылок на несуществующие функции в других модулях этого недостаточно. Разберем, как правильно настроить глубокую проверку всей конфигурации.
Для запуска полноценного аудита выберем в меню: Конфигурация — Проверка конфигурации. В появившемся окне необходимо установить следующие флаги:
Проанализируем ситуацию: если мы доработали общий модуль или создали расширение, использующее функцию из типовой БСП (Библиотеки стандартных подсистем), и эта функция была удалена разработчиками 1С, расширенная проверка выдаст сообщение об ошибке. Это основной "бесплатный" инструмент, который должен запускаться после каждого обновления перед этапом тестирования.
Современная среда разработки EDT предоставляет гораздо более мощные механизмы контроля, чем классический конфигуратор. Выясним причину, почему EDT лучше справляется с поиском устаревших функций.
В 1С существует стандарт оформления кода: если функция планируется к удалению, разработчик добавляет специальный комментарий. Рассмотрим пример оформления такого метода:
// Устарела. Следует использовать ОбщегоНазначения.ИмяНовойФункции.
//
Процедура СтараяФункция() Экспорт
// Тело функции
КонецПроцедуры
Если в коде вашей доработки встречается вызов СтараяФункция(), EDT автоматически выделит это место предупреждением (Warning) прямо в текстовом редакторе. Это работает благодаря встроенному статическому анализатору, который распознает ключевое слово "Устарела." или аннотацию @deprecated. Использование EDT позволяет видеть потенциальные проблемы еще на этапе написания кода, не дожидаясь запуска полной проверки конфигурации.
Для крупных проектов ручного контроля в конфигураторе становится недостаточно. Посмотрим на возможности инструментов внешнего анализа кода. Одним из наиболее популярных решений является SonarQube в связке с плагинами для языка 1С (BSL).
Рассмотрим по шагам, как это работает:
Помимо SonarQube, существует проект BSL Language Server. Его можно интегрировать в редакторы вроде VS Code. Он умеет находить вызовы методов, помеченных как устаревшие, и даже предлагать замену, если она указана в комментарии к функции. Это значительно ускоряет процесс рефакторинга после обновления "тяжелых" конфигураций, таких как ERP или КА.
Разберем ситуацию, когда функция еще существует в коде, но разработчики 1С уже крайне не рекомендуют её использовать. В Библиотеке стандартных подсистем (БСП) реализованы механизмы рантайм-контроля. В коде устаревших функций часто можно встретить конструкцию:
Если ОбщегоНазначенияКлиентСервер.ЭтоКопияБазы() Тогда
ВызватьИсключение "Метод 'СтараяФункция' более не поддерживается!";
КонецЕсли;
Или использование журнала регистрации. Проанализируем это: в некоторых версиях БСП предусмотрена константа или параметр запуска, который включает логирование вызовов устаревших функций. Каждое такое обращение фиксируется в журнале регистрации с указанием стека вызова. Это отличный способ выявить "хвосты" в работающей системе, которые не были пойманы на этапе разработки.
Если штатных средств недостаточно, можно реализовать собственный инструмент мониторинга. Рассмотрим пример логики скрипта на языке 1С или OneScript, который поможет сопоставить список используемых функций с актуальным состоянием системы:
Процедура или Функция, к которым добавлен комментарий Устарела.Такой подход позволяет подготовить детальный план работ по адаптации кода еще до того, как вы начнете физическое объединение конфигураций.
Важно помнить, что обычная проверка конфигурации часто игнорирует внешние отчеты и обработки. Чтобы проверить их на наличие вызовов удаленных функций, рекомендуется использовать Vanessa Automation или другие инструменты для "дымового тестирования" (smoke-tests).
Разберем, как это реализовать:
ПриСозданииНаСервере или в области объявлений переменных вызывается отсутствующая функция общего модуля, тест зафиксирует ошибку.Резюмируя: наиболее надежным способом "борьбы" с устаревшими функциями является использование EDT для разработки и SonarQube/BSL Language Server для автоматического контроля качества. Если же эти инструменты внедрить невозможно, необходимо приучить команду разработчиков выполнять полную расширенную проверку конфигурации после каждого обновления типового решения, обращая особое внимание на логическую целостность модулей.