Вскрытие статического анализа кода проектов 1С

 

Сегодня я расскажу, из чего состоит статический анализ, и что интересного можно найти с его помощью в проектах на 1С.

Подопытным в данном случае будет выступать плагин для SonarQube от компании «Серебряная пуля». Кроме этого, многие аналогии будут применимы и к плагину для SonarQube от сообщества «1С-syntax».

По каждому модулю я буду показывать примеры ошибок, которые там можно найти.

 

Что такое статический анализ?

 

 

Статический анализ кода – это процесс выявления проблем в исходном коде программы. Процесс во многом похож на код-ревью и, бывает, дополняет его. Но, в отличие от код-ревью, процесс статического анализа полностью автоматизирован.

 

 

Многие считают, что статический анализ устроен просто – берем исходный код, применяем какую-то магию, и, вуаля, у нас на выходе список ошибок.

Но это не так, статический анализ устроен более сложно.

 

 

Процесс следующий:

• Сначала берем исходный код и по нему строим объектную модель метаданных.

• Затем запускаем разбор текстов модулей и текстов запросов и превращаем их в синтаксические деревья.

• После этого мы строим контекст (контекст проекта, модуля и т.д.)

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

• Дополнительный шаг – это расчет метрик. Например, для SonarQube это – когнитивная сложность или количество строк кода

• И последний этап – это фиксация отчета в какой-то внешний файл или в базу данных. SonarQube пишет информацию в базу данных, а оперативные данные у него крутятся в Elastic Search.

 

Синтаксическое дерево (AST) кода 1С

 

Исходный код 1С-модулей хранится в файлах с расширением bsl.

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

 

 

Посмотрим пример – берем простое выражение:

Сумма = Цена * Количество

Это выражение в виде синтаксического дерева выглядит следующим образом:

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

• Переменная с идентификатором «Сумма»

• Знак «=»

• Переменная с идентификатором «Цена»

• Знак «*»

• Переменная с идентификатором «Количество»

• Символ «;»

А еще синтаксическое дерево – это конечное ориентированное дерево, в котором:

• вершины сопоставлены операторам языка;

• листья сопоставлены операндам.

 

 

Для того, чтобы получить синтаксическое дерево, нужно сделать следующее:

• Сначала из исходного кода мы извлекаем тексты.

• Затем прогоняем все это через лексический анализ.

• На выходе получаем список токенов. Токен или лексема – это абстрактная единица морфологического анализа (например, переменная с идентификатором «Сумма»).

• Дальше нам нужно прогнать все это через грамматический анализ.

• В результате мы получаем построенное синтаксическое дерево. Либо не построенное дерево, если в коде модуля есть какие-то ошибки, которые не позволяют его построить – грамматика нарушена, либо что-то еще.

 

 

На примере переменной «Сумма» рассмотрим, что из себя представляет узел синтаксического дерева:

• У него есть тип – в данном случае, это переменная (BSLGrammar.Variable).

• У него есть родитель – это присвоение (assignment).

• У него есть дочерний элемент – идентификатор (identifier).

• И есть токен. По токену мы можем узнать:

  • номер строки;

  • позицию в тексте;

  • длину;

  • оригинальное значение и приведенное к верхнему регистру для удобной работы с ним;

  • а также коллекцию с «пустяками», где содержится комментарий, инструкции препроцессора и т.п.

 

 

Аналогично тексту модулей строится и дерево для текстов запросов.

Рассмотрим простой пример запроса. У нас происходит выборка значений поля «Наименование» из справочника «Номенклатура».

 

 

Синтаксическое дерево запроса у нас выглядит следующим образом:

• Вершина дерева – узел текста запроса.

• Далее можно проследить типы узлов: пакет запроса, описание запроса, описание полей выборки и т.д.

• Я снова выделил зеленым конечные узлы. В итоге мы можем текст запроса представить из следующих конечных узлов:

  • Ключевое слово «Выбрать»

  • Описание полей выборки, которое состоит из идентификатора «ТекущийСправочник», точки и идентификатора «Наименование».

  • Ключевое слово «Из»

  • Описание таблицы, из которой мы выбираем – оно стоит из идентификатора «Справочник», точки и идентификатора «Номенклатура»

  • И заканчивается это все алиасом, который состоит из ключевого слова «Как» и идентификатора «ТекущийСправочник».

Хорошо, у нас в распоряжении есть синтаксическое дерево. Что нам нужно сделать, чтобы выявить по нему какие-то ошибки?

 

Модуль «Правила проверок»

 

Для этого существует модуль «Checks» – в переводе на русский это «Правила проверок». Эти правила описывают, на какие типы узлов нам нужно подписаться в этом дереве, и описывают алгоритмы – каким образом мы будем все это проверять.

 

 

Давайте посмотрим на примере. На слайде – небезопасное удаление из коллекции (из таблицы значений). Согласно этому условию у нас могут быть удалены не все значения, которые нам нужно будет удалить, и это – неправильно. Получается небезопасный, некорректный алгоритм. Описание правила проверки выглядит следующим образом – мы сначала в правиле подписываемся на тип узла «Для Каждого». Затем в этом блоке «Для Каждого» мы извлекаем имя коллекции. Дальше это имя коллекции мы ищем в блоке внутри. Затем ищем вызовы методов Удалить() или Очистить().

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

 

 

Следующий пример.

Что самое трудное в программировании? Конечно же дать осмысленное правильное понятное название именам переменных и методов. В данном случае полет фантазии «иногда» далеко не уводит и рождаются переменные с именами «Строка1», «Строка2» и т.д.

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

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

• Запустить тесты. Ручные, автоматизированные – не важно. Но редкие кейсы обычно тестами не покрываются, поэтому здесь все равно могут быть проблемы.

• Дать осмысленное имя переменной. Это дешево, сердито и быстро.

Идем дальше.

 

 

В тексте запроса на слайде трудно без контекста дать точный вердикт, какие именно есть проблемы. Одно точно сказать можно – здесь есть проблемы с отборами в блоке «ГДЕ». Потому что использование «НЕ» с «И» – не слишком хорошая идея. Кроме этого, здесь выражения НачалоПериода() и КонецПериода() нужно вынести в параметры запроса &НачалоПериода и &КонецПериода.

А в таком виде запрос в продакшене очень сильно тормозил, и люди его потом переписывали.

Не пишите таких запросов, и ваши «маневры» не будут вам стоить «51 год».

 

Модуль анализа метаданных – MDClasses

 

 

Вернемся к компонентам статического анализа.

Еще одна из очень интересных и непростых задач – это прочитать все данные из исходного кода 1С и построить на основании этого объектную модель метаданных.

При этом нужно еще учитывать, что у нас сейчас на данный момент два формата метаданных:

• Первый – это формат экспорта из конфигуратора 1С.

• Второй – это формат EDT.

Для построения объектной модели метаданных нужно анализировать:

• множество MDO и XML-файлов с различными видами объектов;

• у каждого вида объектов – свой набор свойств объектов метаданных;

• сложная модель формы, особенно, в формате конфигуратора;

• и, бывает, что нужно получить статусы поддержки из конфигурации поставщика.

 

 

Для этого существует проект MDClasses. Он написан на Java, имеет открытый код и развивается на GitHub сообществом «1С-syntax».

Проект покрывает большинство кейсов, которые нужны при статическом анализе в данный момент – это метаданные, формы и макеты СКД.

Пока что проект не умеет строить, например, модель табличного документа, чтобы с ней потом можно было работать – не хватает рук, чтобы это допилить.

 

 

Из чего состоят метаданные? Как их можно представить?

Справа на слайде представление корня конфигурации в виде объекта. Здесь вперемешку и свойства корня, и дочерние объекты (например, документы или общие формы), и какие-то служебные коллекции. Но в целом с этим работать пока еще удобно.

 

 

Более сложный пример – это форма.

Слева у нас представление простой формы, которую мы можем нащелкать в конфигураторе, а справа ее представление в модели.

Тут помимо атрибутов, команд, обработчиков можно увидеть иерархический или плоский список элементов формы.

Для чего все это нужно? Например, можно написать проверку, которая будет проверять, что у всех элементов формы путь к данным написан корректно. Либо в текстах модуля проверить, что все элементы формы, к которым мы обращаемся, существуют.

Точно так же можно анализировать реквизиты объектов метаданных и проверять обращения к ним в запросах.

 

 

Давайте посмотрим на примерах – начну с доп. возможностей анализа текстов запросов.

Имея модель СКД-макетов и динамических списков мы можем получить тексты запросов и прогнать их на существующие проверки.

В данном случае на слайде проблема с соединениями и значениями «NULL». Разработчик себя обезопасил, но не до конца – второе значение тоже может принимать значение NULL.

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

 

 

Идем дальше – опечатки в именах справочников, общих модулей и т.п.

Прогоняем элементы метаданных, проверяем опечатки.

Такие опечатки можно найти в отраслевых решениях. Особенно печалит, что это требование является обязательным при сертификации 1С-Совместимо.

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

 

 

Следующий пример. Одно из самых полезных правил проверки текстов запросов – это проверка существования метаданных, о которой я говорил ранее. Может возникнуть ситуация, что, допустим, объект метаданных удаляется, переименовывается, либо какая-то подсистема внедряется, где его забыли. В данном случае текст запроса у нас был найден в обработке в одной из конфигураций.

И выводов у меня, как минимум, несколько.

• Во-первых, никто не искал использование этого метаданного в тексте запросов.

• Во-вторых, если этот объект метаданных изменялся давно, то либо этой обработкой пользуются очень редко, либо это просто мертвый код, и его нужно обязательно удалить.

 

Модуль контекста и конфигурация «Context collector for BSL» для сбора контекста платформы

 

 

Следующий компонент статического анализа – это контекст, куда относится:

• Контекст модуля

• Контекст проекта

• Контекст платформы

• Общий контекст.

В контекст модуля входят:

• Методы

• Переменные – их описание и определение.

• Области

• И инструкции препроцессора из расширений, которые регулируют удаление и вставку объектов

Хороший пример использования контекста модуля – это использование недокументированных параметров методов в публичном API.

Следующий контекст – это контекст проекта. Он состоит из публичного API модулей и глобальных методов. Такой контекст позволяет реализовать более сложные проверки, например, использование устаревших методов.

Но самая трудная задача – это разобрать и получить контекст платформы. Нужно учитывать, что версий множество, соответственно, нужно хотя бы поддерживать версию с «8.2.19». У нас сейчас данные по контексту платформы частично захардкожены, но мы параллельно ведем разработку проекта, чтобы делать это прозрачно и более удобно.

 

 

Для этой цели на GitHub есть открытый проект https://github.com/otymko/bsl-context-collector

Он читает справку 1С и фиксирует ее в информационную базу. Затем с этими данными можно провести различные трансформации, и все это выгрузить в произвольном формате.

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

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

 

Какие проблемы можно выявить

 

 

Возвращаемся к примерам. Когда вы пилите типовую конфигурацию либо свою на базе БСП, вы, скорее всего, рано или поздно, будете использовать методы из публичных API.

Хороший пример – метод «СообщитьПользователю» из конфигурации «Библиотека стандартных подсистем». Раньше этот метод был только в модуле «ОбщегоНазначенияКлиентСервер», теперь реализацию разделили – этот метод есть в общем модуле «ОбщегоНазначения» и в модуле «ОбщегоНазначенияКлиентСервер», где он помечен в документирующем комментарии меткой «Устарело».

Соответственно, когда разработчики БСП будут уверены, что они больше не будут поддерживать этот API, удалят этот метод, возникнет очень неприятная ситуация – потребуется потратить больше времени на доработку этой функциональности у себя.

 

 

Следующая проверка – встречались с ситуацией, что обработчик у элемента формы почему-то не работает? Такая проблема возникает, когда изменения переносят из конфигурации в конфигурацию, либо разработчик сначала создал процедуру обработчика для события элемента формы, а потом эту процедуру удалил или переименовал, а в элементе формы эту привязку не поменял.

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

 

Control flow graph или граф потоков управления

 

 

Напоследок хочу рассказать об еще одном интересном модуле статического анализа – это граф потоков управления, сокращенно «CFG».

«CFG» – это граф, в котором мы знаем все пути выполнения кода.

В графе есть:

• два спецблока – входной и выходной блок;

• узлы операторов;

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

Давайте посмотрим на примере. На слайде – процедура Тест(), в которой есть:

• блок с условиями;

• и вызов метода «doAfterIf()».

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

В примере представлено два вида выражений – это «expression_statement» и «if_statement». В нашей реализации таких видов может быть 13.

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

 

 

На слайде показан классический пример недочета при реализации функции.

Как только в переменной «ТекстОбласти» появится новое значение, функция вернет «Неопределено» за счет скрытого оператора возврата.

Это – неочевидное поведение алгоритма, и иногда такие проблемы не получается быстро выявить. «CFG» позволяет получить все пути выполнения кода и проверить все выходы из блока на «Возврат» или «ВызватьИсключение».

 

Какие есть статические анализаторы для 1С

 

 

Теперь хочется рассказать, какое еще есть ПО для статического анализа для 1С.

• Как я говорил ранее, есть плагин для SonarQube от сообщества 1c-syntax. Он написан на Java.

• Также у фирмы «1С» есть расширенная проверка конфигураций, которая доступна из меню конфигуратора, либо мы можем ее вызвать с помощью пакетного режима платформы.

• Далее, есть платформа EDT, в которой реализовано множество проверок статического анализа, их там более ста. Они работают с помощью модуля v8-code-style. Это модуль, который 1С сейчас разрабатывает в OpenSourсe.

• Кроме этого, на 1С есть конфигурация «1С:Автоматизированная проверка конфигураций». Развитие этого проекта сейчас остановилось в пользу EDT, но релизы еще выпускаются.

 

Планы и полезные ссылки

 

Хочется рассказать о планах – что мы собираемся сделать по нашему статическому анализу:

• мы хотим выпустить контекст платформы;

• поддержать мультиконтекст при анализе, когда мы хотим анализировать и конфигурацию и обработки либо расширения;

• хотим выпустить MVP анализа потока данных (DFA) – пока планируем, изучаем подходы, хотим реализовать для начала примеры с примитивами, чтобы вызовов лишних не было и т.п.

Материалы, которые использовались в рамках доклада:

• 1C (BSL) Plugin

• Документация по SonarQube и 1C (BSL) Plugin

• Чтение метаданных 1С

• Контекст платформы в виде ИБ 1С

• 1C (BSL) Community Plugin

• v8-code-style

 

Вопросы

 

Сколько времени занимает статический анализ ERP?

Помимо стат. анализа есть еще расчет авторов – кто какую строчку изменил (git blame). Если его откинуть, то на средних раннерах статический анализ занимает примерно 12-15 минут. Но это только на стороне клиента. Еще потом запускается процесс на самом сервере SonarQube, который эти данные загружает. На облачном сервере SonarQube, который мы используем, это тоже происходит в течение 10-15 минут, в зависимости от количества изменений. В первый раз будет подольше.

Когда мы коммит помещаем, Sonar анализирует изменения только в этом коммите?

Нет, Sonar всегда анализирует полностью проект, потому что когда он проанализировал, он сверяет данные с предыдущими замечаниями. И, если что-то пропало, он это замечание закрывает. Поэтому анализ происходит весь.

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

Насколько различается функциональность вашего плагина и 1С (BSL) Community Plugin?

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

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

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

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

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

Второй шаг – берете инструкцию, и по ней выгружаете конфигурацию в XML-файлы, рядом добавляете файл с настройками и запускаете sonar-scanner, который все это отправит в сервер SonarQube (вам его, соответственно, тоже нужно установить).

И все, это все шаги. Но это – ручные действия.

Потом идет развитие. Если у вас есть CI, вы можете в Jenkins, в GitLab-CI либо в GitHub-CI настроить уже автоматические действия. Допустим, появился новый коммит в проекте Git, автоматически по какому-то триггеру запускается событие, которое анализирует.

Следующий этап – строится проверочный контур, где уже одним из этапов может выступать как раз анализ SonarQube.

Дальше вы для себя можете определить, какие вам нужны проверки, и потом уже закручивать себе гайки. Например, вы можете решить, что уязвимости вообще нельзя пропускать. Соответственно, устанавливаете порог качества «Количество уязвимостей = 0», и при нахождении уязвиомстей ваша линия сборки теперь будет падать.

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

Все говорят про SonarQube, но я использую PhoenixBSL на локальном компьютере. Планируете ли вы его дальше развивать, добавлять новые правила?

PhoenixBSL сейчас работает в двух режимах.

Первый режим основывается на проекте BSL Language Server, поэтому количество проверок зависит от него – если в BSL Language Server сделают новые проверки, они появятся в PhoenixBSL.

При работе в этом режиме у PhoenixBSL есть сейчас три недочета.

• Первый недочет – он не знает, какой мы файл редактируем.
• Второй недочет – он не знает, что существуют метаданные, т.е. этих проверок сейчас не хватает.
• И третий недочет – нет возможности смотреть diff, т.е. мы написали новый код, и мы хотим посмотреть только новый код – быстро, без всего списка замечаний, потому что сейчас чаще всего люди дорабатывают типовые конфигурации и там много шума идет от этих типовых отраслевых решений.

А во втором режиме вы используете сервер с нашим плагином к SonarQube. Вы можете получить к нему доступ, чтобы запускать анализ локально, если вы что-то дорабатываете в OpenSource. По его подключению есть статьи для двух платформ разработки – для EDT и для конфигуратора. 

Вы можете попробовать сами локально все это у себя погонять – будет скачан плагин и запущен анализ в ограниченном режиме SonarLint (без расчета метрик, подсветки и всего подобного).

Вопрос по поводу построения AST-дерева для запросов. Можно ли как-то ему скормить текст запроса из 1С и получить обратно JSON с деревом запроса? Я находил подобные решения на GitHub для модулей 1С – там очень удобно, можно ему скормить модуль, и отобразить в виде дерева переменные и методы, которые находятся в определенных экспортных процедурах. А для запросов такой штуки нет.

Здесь есть как минимум три варианта.

Первый вариант – вы можете взять проект BSL-parser от сообщества 1c-syntax, написать над ним надстройку, которая анализирует текст запроса, чтобы он вам выдал JSON. Но для этого нужно будет покодить на Java.

Второй способ – если вы используете наш плагин, там есть инструмент SonarTools, он строит XML, которую можно использовать и иерархический список, с которым вы можете взаимодействовать. Ему на вход можно передать и текст, и путь к файлу, который нужно проанализировать

И третий способ – есть парсер модулей на OneScript с функциональностью анализа текста запросов. Соответственно, там уже можно будет на 1С накодить и сделать выгрузку в JSON.

Проще всего сделать доработку в плагине BSL LS и там написать правила на Java – если вы хотите проверки свои писать. А если пользуетесь нашим плагином, используйте SonarTools либо напишите нам, что вам нужна новая проверка. Мы уже вам поможем.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.