Как управлять качеством кода 1С, используя платформу SonarQube

Приветствую всех на конференции Infostart Event Inception. Зовут меня Тымко Олег, я работаю ведущим разработчиком в торговой сети «Командор» города Красноярска. Сегодня я хочу рассказать вам, как у нас в организации внедрялась непрерывная проверка качества кода на базе платформы SonarQube, с какими проблемами мы столкнулись, какое решение было выработано, и что в итоге у нас получилось. Но обо всем по порядку.

Как уследить за качеством при быстром росте функциональности?

У нас, как и в любых других организациях, для автоматизации бухгалтерского и управленческого учета, расчета зарплаты используются программные решения на базе 1С:Предприятие. Бизнес требует быстро и качественно внедрять новую функциональность в продуктив. С увеличением функциональности растет и размер проектов 1С. Соответственно, и количество кода в этих проектах. И становится актуальным следить за качеством кода, так как каждая ошибка чревата большими затратами бизнеса на ее исправление.

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

С какими проблемами мы столкнулись до внедрения этого всего?

• Первая проблема – при большом количестве разработок проблематично проводить визуальный Code-Review. Проблема ручного Code-Review не только в том, что это дорого и долго для бизнеса, но и в том, что программистам просто это делать лениво, и это их сильно утомляет. И, соответственно, их КПД падает.

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

• Третья проблема в том, что в принципе нет автоматизированного контроля внутренних стандартов разработки – только с помощью Code-Review. 

• И последнее, но не менее важное – это большие затраты на принятие работ от внешних разработчиков. 

С этим нужно было что-то делать, поэтому мы решили внедрить непрерывную проверку качества кода на базе платформы SonarQube.

В основу нашего решения легло использование SonarQube в связке с Jenkins и 1С. Об этом я сейчас все и расскажу.

Общая схема решения

SonarQube – это программное решение, которое позволяет непрерывно проверять качество кода. В платформе поддерживается более 27 языков программирования. С помощью плагина поддерживается и язык 1С.

Хочу рассказать о том, какое решение было выработано у нас и как всем этим пользоваться:

• Разработчики ведут разработку в хранилище 1С, помещают туда свои изменения по каким-то задачам, по проектам и т.п.

• Затем на стороне Jenkins (это такой сервер сборок) выполняется работа (Job), которая экспортирует историю хранилища 1С с помощью консольной утилиты GitSync в локальный Git-репозиторий.

• Затем из локального Git-репозитория изменения отправляются в удаленный Git-репозиторий GitLab, который размещен у нас внутри организации.

• Потом, следующая работа (Job) на стороне Jenkins анализирует изменения в этом удаленном репозитории, где у нас хранятся исходные коды конфигурации. И, если есть изменения, запускает анализ и отправляет результат в SonarQube.

• На стороне SonarQube настроены уведомления пользователей о состоянии проектов, прохождении порогов, о новых и закрытых замечаниях. Уведомления для программистов и для ведущих разработчиков одинаковые – разница у них только в статусе прохождения порога качества.

• Ведущие разработчики на стороне SonarQube каждый рабочий день проверяют замечания по контрольным подсистемам (в том числе по общим подсистемам) и прорабатывают их с разработчиками.
  Также ведущие разработчики контролируют увеличение дублирования в коде. Если такое дублирование ими было выявлено, то информация отправляется виновнику на исправление.

• Также программисты сами работают с SonarQube – смотрят замечания по себе, работают над ними, тем самым, уменьшая объем работы ведущим разработчикам.

Такой процесс настроен у нас во всех основных проектах 1С.

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

Снова вернусь к самому SonarQube. А есть ли аналоги SonarQube в принципе на рынке? Да, есть – например, Solar или App scanner. Но не понятно, какую функциональность они содержат у себя на борту и сколько они будут стоить для бизнеса. 

Также есть решение на базе 1С:Предприятие – называется «1С:Автоматизированная проверка конфигураций» (в дальнейшем, я буду ее называть сокращенно 1С:АПК). Если сравнивать 1С:АПК с SonarQube, то у второго более простой и понятный интерфейс, удобный фильтр по замечаниям, есть оценка текущего состояния проекта, есть динамика изменения показателей проекта.

Если говорить о функциональности SonarQube в общем, то можно отметить следующее:

• У SonarQube есть бесплатная поддержка кода 1С с помощью плагина SonarQube BSL Community

• Сама платформа SonarQube имеет бесплатную версию Community Edition – не нужно сразу покупать Enterprise или Develop-версию. 

• Есть возможность расширения функциональности с помощью плагинов. 

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

• И последнее, но не менее важное – SonarQube можно развернуть у себя на сервере, внутри.

В итоге получается, что мы можем развернуть у себя SonarQube и провести анализ проектов 1С, ничего не покупая из платного программного обеспечения. Только обеспечить сервер под развертку, арендовать его или купить.

Первый анализ в SonarQube

Что же мы увидели после первого анализа в коде проекта?

Конечно же, кучу ошибок, которые сначала кажутся необъятными. И что же с ними делать?

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

Обзор проектов в SonarQube

Посмотрим, как выглядит интерфейс SonarQube. На главной странице у нас обзор проектов с какими-то краткими показателями. Но лучше посмотреть подробно, как выглядит сам проект.

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

Замечания по проекту. Классификация ошибок в коде.

Проблемы в коде бывают следующие:

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

• Уязвимости – они так же критичны, как и ошибки. Они являются отражением проблем безопасности в коде. И с помощью них можно нанести непоправимый вред информационной базе.

• Дефекты кода – это «код с запашком». Они менее критичны, чем ошибки, но влияют на сопровождаемость и простоту доработки конфигурации.

• Дублирование кода – менее критично, чем дефекты кода. Но также влияет на простоту доработки. По сути, является отражением меры копипаста в проекте.

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

• он не канонически пишет ключевые слова;

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

• объявляет константу в цикле;

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

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

То есть, надо Барта постоянно контролировать, либо вообще увольнять.

Далее – в самом проекте можно посмотреть список замечаний по проекту. SonarQube предоставляет гибкий отбор по замечаниям. Мы у себя, в основном, пользуемся отборами:

• по типу замечания;

• по дате его создания – смотрим, какие у нас были замечания за период;

• по назначенному ответственному – кто этим замечанием должен заниматься и занимается;

• и по конкретному правилу.

Как в принципе замечание выглядит?

Из него можно понять:

• местоположение – модуль, где это замечание сработало, строчка кода, на которой оно сработало;

• суть самого замечания – его заголовок (в данном случае «Отсутствует код в блоке «Исключение»);

• тип;

• статус;

• дату создания;

• кто ответственный за это замечание (кому оно назначено);

• можно проставить теги, если они ведутся. В данном случае, если по тегу классифицируются какие-то проблемы, можно, допустим, написать, что это – Bad Practice. 

В контексте кода замечание выглядит так, как на слайде.

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

Профили качества

В SonarQube есть определенные сущности. Первая сущность называется профиль качества. Они нужны, чтобы группировать правила проверки и делать какие-то конкретные настройки по этим правилам. Для себя у нас создано два профиля качества:

• общий профиль для проектов 1С в целом;

• профиль конкретно под OneScript.

Пороги качества

Еще одна вещь в SonarQube – это пороги качества. Они нужны, чтобы установить границы уведомления о непрохождении порогов качества по каким-то выбранным критериям. Для одного из наших проектов на команду 5-8 человек были установлены следующие условия порога – мы за период 21 день не должны превышать:

• больше 25 ошибок;

• больше 300 замечаний;

• больше 10% дублирования в коде;

• и не больше нуля уязвимостей. 

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

Некоторые диагностики. Магические числа

Кто в зале знает, что такое магические числа? Это такие числа, про которые в коде нельзя однозначно сразу понять, что они означают. В качестве примера на экране показан кусок кода, в котором у нас проверяется какое-то условие, связанное, видимо, с датами. И при выполнении этого условия будет вызван какой-то метод. 

А что такое 7*60*60? Или 55*60? С первого взгляда это же не понятно? А когда опускаешься до контекста, то начинаешь понимать. Первое – это 7 часов в секундах. А второе – 55 минут в секундах. Это и называется магическими числами. 

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

У правила есть исключения, на которые эта диагностика не реагирует – это 0, 1, -1 и 86400 (1 день в секундах). 

Следующее правило – параметры при объявлении структуры. В упрощенном виде это правило гласит: «Не рекомендуется объявлять структуры с параметрами в параметрах других структур». 

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

Это – плохочитаемый и плохоподдерживаемый код. При любом изменении в параметрах доработка такого кода почти всегда чревата ошибками. 

Правильно все структуры разбить на отдельные переменные. И множество параметров добавлять через «Вставить».

Как сказал один программист: «У меня с таким кодом вообще никогда проблем не было, я не первый день на родео и это далеко не первое мое родео». А нам такого родео не надо. С этим кодом можно обрести очень много проблем – что в разработке, что в продакшене.

Рассылка на почту

Перейдем снова к SonarQube – вот так выглядит уведомление, которое он присылает на почту. В данном случае, по уведомлению можно понять:

• что это за проект, его версию;

• что в данном случае случилось – появилось какое-то новое замечание 

• и быструю ссылку, чтобы перейти к этому замечанию в веб-интерфейсе. 

Вообще у SonarQube есть несколько шаблонов рассылок. 

• Одну вы видите на экране – это уведомление о новых замечаниях и изменении статуса предыдущих, уже существующих.

• И вторая – это уведомление о непрохождении порога качества (либо прохождении).

Результат

Хочу подвести промежуточные итоги. Что мы получили после внедрения такого контроля?

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

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

Где взять диагностики кода?

В ходе использования платформы SonarQube у нас возникла необходимость внедрить больше правил. На основе анализа существующих решений были выявлены следующие источники – это:

• 1С:АПК;

• Проект BSL Language Server;

• 1C:EDT, о которой я сейчас расскажу.

EDT

1С:EDT – это такой новый конфигуратор 1С. Он разрабатывается на базе IDE Eclipse. С помощью утилиты ring можно выгрузить список замечаний в произвольный формат csv. На борту имеется примерно 87 диагностик, которые частично пересекаются с основным плагином для SonarQube. Этот результат можно сконвертировать в понятный для SonarQube формат – generic issue с помощью проекта с GitHub, который называется edt-export (https://github.com/Stepa86/edt-export-bugs).

1С:АПК

Следующий источник – это 1С:АПК. Его разработала компания ИжТиСи в 2009 году. Решение позволяет в автоматическом режиме проверять конфигурации на соответствие стандартам разработки 1С и 1С:Совместимо.

В 1С:АПК есть настройка проверяемых требований. Мы у себя проверяем группу требований – это:

• платформенные проверки конфигурации;

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

• особенности кросс-платформенной разработки – мы используем решения не только на Windows, но и на Linux, поэтому нам важно проверять эти моменты;

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

• и последнее – это оформление модулей. В них входит структура модулей, описание процедур и функций и т.п.

Вот так у нас в SonarQube выглядят замечания, выгруженные из 1С:АПК. Для выгрузки замечаний из 1С:АПК в понятном SonarQube формате generic issue используется проект acc-export (https://github.com/otymko/acc-export).

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

Также можно выгрузить из 1С:АПК описание правил проверок в формате json и загрузить их в SonarQube. И, не открывая 1С:АПК, видеть описание проблем со ссылками на стандарты в ИТС. 

По каждому из правил можно предварительно оценить объем технического долга – сколько времени потребуется на исправление, и после выгрузки замечаний из 1С:АПК в SonarQube все это посчитать.

BSL Language Server

И последний проект – это BSL Language Server. Проверки для бесплатного плагина, который мы использовали в SonarQube, берутся из этого проекта.

Это – проект реализации Language Server Protocol для языка 1С. Чтобы увеличить количество диагностик в этом проекте, нужно участвовать в его развитии, писать на Java, на Kotlin. Понятно, что не каждая команда это себе может позволить, но, в принципе, какие-то базовые проверки пишутся не так сложно. 

На экране – немного кода Java. Что из него можно понять? 

• у нас есть какое-то описание диагностики – ее тип, важность, время на исправление;

• и есть какой-то класс с переопределенным методом, который посещает список параметров метода visitParamList. 

Диагностика на слайде – это контроль порядка параметров в методе. Проверка срабатывает, если хотя бы один обязательный параметр идет после необязательного. Если в нашем коде такая ошибка встречается, мы увидим это замечание в SonarQube.

Изменение показателей проектов

Подведу финальный итог. Что же нам удалось добиться всем этим внедрением?

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

• Разработчики теперь могут сами смотреть свои замечания и прорабатывать критические ошибки до внедрения в продакшен.

• Появилась самообучаемость у младших разработчиков – их стиль кода и качество написания кода улучшились без какого-то особого вмешательства ведущего разработчика. 

• Также с помощью SonarQube где-то на 20% быстрее стал ревью кода. 

• Теперь мы можем смотреть динамику по проектам и использовать эту информацию в каких-то управленческих решениях. 

• Итого, в краткосрочной перспективе, за 2-3 месяца нам удалось добиться прекращения увеличения замечаний по проектам, и начать работу над существующими.

Я хочу показать вам пару графиков – показателей одного из проектов.

Первый график – у нас анализ проводился с апреля по сентябрь 2019 года. На графике мы видим, сколько у нас в проекте было дублирующихся участков с копипастом. Начали мы примерно с 18 тысяч, сейчас примерно 7 тысяч. За это время нам удалось добиться уменьшения дублирования кода в 2 раза, и это очень хорошо. Уменьшили копипаст – проект стал более качественным.

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

Что у нас в планах?

Мы собираемся развивать эту тему дальше:

• внедрить большее количество диагностик – то есть, участвовать в развитии проекта BSL Language Server;

• довнедрить SonarQube в оставшихся проектах – их осталось немного;

• разработать регламент, по которому бы Sonar внедрялся сразу в новые проекты;

• и собираемся автоматизировать CodeReview с помощью связки SonarQube + GitLab + Cruisible. 

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

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

• Как развернуть у себя SonarQube? //infostart.ru/public/1089670/

• Зачем это все нужно? //infostart.ru/public/1096770/

• Управление техническим долгом - Концепция Continuous Inspection. //infostart.ru/public/622617/

• Пример pipeline Jenkins для автоматического запуска. //infostart.ru/public/1117485/

• Проект BSL Language Server. https://github.com/1c-syntax/bsl-language-server

Надеюсь, кому-то это покажется полезным.

Вопросы

• Сколько человек у тебя сейчас работает и смотрит SonarQube и сколько всего проектов?

• У нас сейчас работает 11 человек – в этом направлении движется. Проектов (разных конфигураций) у нас тоже 11. С дублирующими конфигурациями по разным направлениям у нас проектов около 15.

• Ты особое внимание уделил слайду с дублирующимися участками. Почему для вас это было проблемой?

• Конфигурация, на которой мы сейчас ведем основной учет – у нас внедрялась очень давно, 12 лет назад, может, даже больше. И там было очень много легаси-кода. Соответственно, там было очень много копипаста. Этот показатель на слайде показывает не просто количество дублирующихся строк кода, он показывает количество дублирующихся участков. То есть, есть функции, которые в разных модулях дублируются. И мы их потихоньку, с помощью SonarQube начали отслеживать и выпиливать. И новые отслеживать.

• Почему потребовалось избавляться от этих дублей, из-за них возникали какие-то ошибки?

• Просто получается, что у нас, допустим, есть метод генерации штрихкода, который вызывается в пяти разных местах. Если мы дорабатываем один метод – это хорошо. Но есть и другие вызовы такого же точно метода из других мест, и получается, что нам нужно доработать все эти места. А мы можем еще и забыть их доработать – мы не идеальны. Поэтому лучше уменьшить копипаст, чтобы какая-то конкретная функциональность была в определенных модулях, в определенных методах, и нигде ничего не дублировалась. Это избыточно.

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.