Как контролировать качество внешних обработок, отчетов, правил обмена, расширений 1С и поставить это на поток

Публикация № 1420861 09.04.21

Инструментарий разработчика - Рефакторинг и качество кода

Если код написан качественно, его легче развивать и дешевле поддерживать. О том, как организовать контроль качества кода в ручном и автоматическом режиме, и какие инструменты могут в этом помочь, на INFOSTART MEETUP Новосибирск.Online рассказал Олег Тымко.

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

В рамках доклада я рассмотрю следующие вопросы:

  • Зачем контролировать качество кода.

  • Как и с помощью каких инструментов можно контролировать качество кода в ручном и автоматическом режиме.

  • Как использовать Jenkins, чтобы автоматизировать процессы повышения качества.

  • И поделюсь ссылками, которые будут упомянуты в рамках доклада.

 

Качество кода и его критерии

 

 

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

 

 

Критерии качества кода следующие – это:

  • соответствие стандартам разработки;

  • отсутствие ошибок в коде;

  • невысокая сложность;

  • низкое количество дублирования в коде;

  • наличие документации и тестов.

В совокупности все эти критерии и образуют общую картину, насколько качественно написано решение.

 

Зачем контролировать качество кода?

 

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

Чтобы ответить на этот вопрос, нужно рассмотреть эту ситуацию с разных сторон.

 

 

Со стороны заказчика:

  • Уменьшая количество проблем в коде, можно сэкономить деньги и время у бизнеса.

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

 

 

Со стороны исполнителя/подрядчика:

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

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

 

 

Со стороны сопровождения/поддержки.

  • Для сопровождения качественного проекта потребуется меньше ресурсов, чем для проекта, который написан по передовой технологии «через пень-колоду».

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

Подведу маленький итог. Всем сторонам выгодно держать качество разработки на приемлемом уровне:

  • с одной стороны, это возможность заработать больше;

  • с другой стороны, это экономия денег;

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

 

Как контролировать качество кода?

 

 

Допустим, мы знаем критерии качественного кода. Но что дальше? Как это качество контролировать?

Для повышения качества кода можно использовать следующие практики:

  • Стандарты разработки 1С и выработанные внутри команды стандарты.

  • Чтение кода.

  • Инструменты автоматизации разработки.

  • Тестирование кода.

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

  • Статический анализ кода.

Расскажу о каждой из этих практик подробнее.

 

Стандарты разработки

 

 

К стандартам разработки можно отнести:

  • Стандарты 1С:Совместимо и сами стандарты 1С с сайта 1С:ИТС. Это очень полезные правила – большинство из них обосновано и помогают сохранить много человеко-часов при разработке.

  • Также есть какие-то внутренние стандарты разработки компании, которые вырабатываются внутри команды. Чаще всего, это какие-то исключительные особенности, либо адаптация стандартов разработки 1С.

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

 

Чтение кода

 

 

Следующая практика – это чтение кода. Сюда входит:

  • Code Review – анализ кода с целью выявить ошибки, плохую архитектуру, отклонения от изначально поставленной задачи

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

  • Разработка в команде, когда контроль кода организуется в группе от 2 до 5 человек. Ведущий группы чаще всего занимается архитектурой в общем, сложными задачами, проводит чтение кода, разделяет задачи на более мелкие и распределяет их между членами команды.

 

Инструменты автоматизации разработки

 

 

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

 

Расширение возможностей конфигуратора 1С

 

 

Для конфигуратора 1С, как минимум, есть следующие инструменты, которые могут облегчить жизнь. Это:

  • PhoenixBSL;

  • SmartConfigurator;

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

Подробнее расскажу про PhoenixBSL и SmartConfigurator.

 

PhoenixBSL

 

 

PhoenixBSL – это проект, который позволяет упростить работу в конфигураторе 1С за счет использования возможностей движка BSL LS (проект, который реализует Language Server Protocol для языка 1С).

На текущий момент PhoenixBSL предоставляет три основные возможности:

  • Анализ кода на замечания.

  • Форматирование кода.

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

 

 

Например, открываем модуль в конфигураторе, по сочетанию клавиш Ctrl+I для выделенного кода вызываем PhoenixBSL и видим результат анализа кода текущего модуля на замечания.

Как видите, здесь есть и ошибки, и какая-то информация, и какие-то подсказки. Если посмотреть детально:

  • Есть условия «Если» с разными ветками. PhoenixBSL нам говорит, что у нас есть дубли, повторяющиеся условия. Смотрите, здесь есть ветка «Переменная = 1 Тогда Результат = 1» и есть ветка «Переменная = 2 Тогда Результат = 1». Это плохо – либо кто-то ошибся, либо это какой-то жесткий копипаст, так не должно быть.

  • Еще PhoenixBSL может отловить, например, использование устаревшего метода «Сообщить», который сейчас использовать не принято – нужно использовать либо функцию из БСП, либо «Новый СообщениеПользователю()».

Возможности проекта BSL LS позволяют PhoenixBSL предоставлять очень много диагностик для анализа кода.

 

 

Следующая функциональность PhoenixBSL – это форматирование кода. Я все сдвигаю, чтобы было некрасиво, и нажимаю для выделенного кода Ctrl+K – у меня произошло форматирование кода.

 

 

Последняя особенность PhoenixBSL – это быстрые исправления в коде. Допустим, в результате анализа кода на замечания, слово «Истина» у нас оказалось написано не канонически. Я выделяю этот блок, нажимаю Ctrl+J и PhoenixBSL:

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

  • ставит пробел между комментарием и двумя слэшами;

  • и ставит точку с запятой после оператора «Сообщить».

 

SmartConfigurator

 

 

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

 

 

SmartConfigurator также умеет выполнять анализ кода в конфигураторе – он тоже вызывается через хоткей в конфигураторе и открывает окно с замечаниями. Замечания также выводятся с помощью проекта BSL LS.

 

 

Здесь тоже есть форматирование кода – оно реализовано с помощью скрипта форматирования OneStyle. Этот скрипт имеет много настроек – вы можете настроить форматирование кода под себя.

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

 

 

И последняя возможность SmartConfigurator – это хоткеи.

Вы можете назначить свои хоткеи на какие-то действия в конфигураторе. Например, на слайде показано, как через Ctrl+1 вызываются методы текущего модуля.

 

Расширение возможностей 1C:EDT

 

 

Перейдем к 1С:EDT.

1С:EDT – это такой новый конфигуратор от 1С. Помимо встроенных проверок кода (их порядка 94 штук), умеет форматировать код.

Важная особенность – для 1С:EDT можно писать собственные плагины либо использовать какие-то готовые.

Я хочу более подробно рассказать о конкретном плагине, который называется BSL LS validator.

 

BSL LS Validator

 

 

Плагин BSL LS Validator также использует проект BSL LS, чтобы анализировать код на замечания и делать быстрые исправления.

Давайте покажу вам, как это выглядит в EDT.

 

 

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

Здесь есть процедура Ошибка(), где вызывается «НачатьТранзакцию()» и дальше переход в какой-то метод, в котором делается Попытка – Исключение – ОтменитьТранзакцию().

EDT нас предупреждает, что:

  • для НачатьТранзакцию() нет парных вызовов ЗафиксироватьТранзакцию() и ОтменитьТранзакцию() – понятно, что это чревато;

  • также подсвечено красным, что ОтменитьТранзакцию не идет первым после исключения – в сообщении у меня происходит деление на ноль, все вылетит, и транзакция не отменится;

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

 

 

При нажатии на строку с ошибкой доступны быстрые исправления.

 

Тестирование

 

 

Следующая практика – это тестирование.

Тема тестирования в 1С очень «заезжена» за много лет. Я не буду сейчас показывать пирамиду тестирования. Хочу выделить только некоторые инструменты, которые помогут вам сделать ваше решение более качественным. Это:

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

 

Документирование

 

 

Следующая практика – это документирование. Документирование помогает писать более качественный код и тратить на это меньше времени.

  • Документировать можно подсистемы, модули и архитектуру в целом.

  • Можно формировать техническую документацию.

  • И можно формировать проектную документацию.

 

AutoDocGen

 

 

Если говорить конкретно об инструментах документирования, то из инструментов, которые позволяют автоматически сгенерировать описание методов ваших модулей, есть AutoDocGen – это OpenSource-проект, написанный на OneScript, который позволяет на основании исходных данных конфигурации формировать документации в формате HTML, MD, и даже сразу автоматически отправлять документацию в Confluence. На слайде показан скриншот сформированной документации.

 

Swagger

 

 

Еще есть инструмент, который называется Swagger. Это инструмент, который реализует спецификацию по описанию REST-API.

Например, HTTP-сервис в 1С предоставляет REST-API, и с помощью Swagger можно составлять документацию по HTTP-методам 1С-ных сервисов.

Позднее я более подробно покажу, как Swagger работает.

 

Статический анализ кода

 

 

Следующая область инструментов – это статический анализ кода.

Статический анализ кода – это анализ кода без его реального выполнения. К платформам анализа кода можно отнести:

  • сам конфигуратор 1С, потому что внутри есть расширенная проверка конфигурации;

  • SonarQube;

  • и «1С:Автоматизированную проверку конфигураций».

 

Стандартная проверка конфигурации

 

 

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

Механизм может проводить:

  • проверку логической целостности и поиск некорректных ссылок;

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

  • поиск неиспользуемых локальных процедур и функций;

  • поиск пустых обработчиков;

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

 

1С:АПК

 

 

Дальше – «1С:Автоматизированная проверка конфигурации» (1С:АПК). Она позволяет проверять решения 1С на соответствие стандартам разработки 1С:Совместимо и писать какие-то свои проверки.

Решение не плохое, но на мой взгляд, оно уступает платформе SonarQube в своей удобности.

 

SonarQube

 

 

SonarQube – это еще одна платформа для статического анализа кода. У нее есть веб-интерфейс и очень много закладок для анализа и контроля.

Если установить плагин SonarQube 1C (BSL) Community Plugin, то на сервере SonarQube можно анализировать и код 1С.

 

Автоматизация на Jenkins

 

 

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

Если кто не знает, Jenkins – это сервер сборок. С его помощью можно настроить запуск каких-то действий, чтобы они при определенных условиях выполнялись автоматически. Как минимум, можно:

  • Генерировать документацию.

  • Тестировать код – запускать юнит-тесты, поведенческие тесты, дымовые тесты.

  • Проверять код статическими анализаторами.

Для вас я подготовил пример и разместил его в репозитории GitHub по адресу https://github.com/otymko/infostart2020-nsk-example

 

 

В этом проекте содержится код расширения, которое реализует HTTP-сервис с определенными методами.

  • В модуле этого HTTP-сервиса описана функциональность всех методов с помощью комментариев, оформленных по стандарту.

  • Для проверки работоспособности расширения написан юнит-тест.

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

 

 

Для этой цели у нас в Jenkins создана задача demo с видом pipeline.

 

 

В настройках этой задачи указан определенный pipeline-скрипт.

 

 

Я нажму кнопку «Собрать сейчас» и расскажу вам, что этот скрипт делает:

  • На первом шаге он берет с GitHub текущую версию вашего проекта.

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

  • Затем запускает модульные тесты – есть один маленький модульный тест, который написан для демонстрации.

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

  • Далее –с помощью Swagger-а генерирует документацию, которая описывает наш HTTP-сервис.

  • Потом – генерирует документацию модулей этого расширения.

  • И публикует результаты тестирования в Allure, в которой можно все это смотреть и анализировать.

Собирается этот пайплайн порядка двух минут.

 

 

В репозитории на GitHub есть:

  • краткое описание – что вам может потребоваться, чтобы построить у себя такую же сборочную линию.

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

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

 

 

Пайплайн собрался. Мы можем посмотреть результаты прохождения модульных тестов – в меню слева переходим к Allure.

 

 

Здесь видно, что сейчас выполнился один тест, который прошел успешно.

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

 

 

Через Swagger сгенерировалось описание API нашего HTTP-сервиса. Это очень удобно, если вам нужно интегрироваться по HTTP с другим отделом или с другой компанией. Генерируете такую документацию и отправляете – интегрируйтесь с нами, пожалуйста.

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

 

 

Также сгенерировалась документация общего модуля «Управление заказами», который был в расширении. Здесь видно каждый метод – что он делает и его параметры. Все это в каком-то удобном виде. В примере показано, как описание формируется в HTML, можно формировать в MD – это еще удобнее.

 

 

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

 

 

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

Здесь видно, что проект проанализировался – он не идеальный, есть какие-то дефекты кода.

Все эти замечания можно просмотреть.

 

 

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

 

 

По сравнению с АПК в SonarQube можно в рамках самого кода путешествовать, смотреть, что здесь происходит – можно посмотреть сводку по файлу.

А на главной странице проекта можно отслеживать тенденцию изменения показателей.

 

 

По поводу Swagger – есть два варианта использования.

  • Вы можете развернуть серверное приложение Swagger-UI у себя по инструкции, и генерировать для него спецификации по своему проекту.

  • Либо вы можете использовать Swagger через Jenkins, как было показано ранее.

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

Поделюсь опытом, что какие приемы автоматизации разработки и тестирования используются у нас в компании:

  • Мы автоматически выгружаем скриптами внешние обработки и отчеты в Git и там их версионируем.

  • Мы используем версионирование правил обмена КД2 – раскладываем большой XML-файл правил на мелкие составляющие и их версионируем. Очень удобно смотреть – кто что изменил и когда.

  • Также у нас положено начало написанию модульных тестов. Есть пара проектов, в которых уже пишутся модульные тесты, прогоняются автоматически через Jenkins перед внедрением.

  • И у нас используется документирование подсистем. Есть пара наших внутренних подсистем, которые документируются с помощью AutoDocGen. Эту документацию удобно передавать для изучения, чтобы вводить кого-то в курс дела.

 

Итоги

 

 

Используя хотя бы минимум практик, о которых я рассказал, можно:

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

  • допускать меньше ошибок в коде – либо через PhoenixBSL смотреть ошибки до SonarQube в конфигураторе, либо в SonarQube смотреть текущие ошибки, которые вы допускаете, и их исправлять.

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

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

 

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

 

Как я и обещал, привожу ссылки, о которых упоминал в докладе.

Первая порция ссылок – инструменты разработки:

Вторая порция ссылок – инструменты тестирования и проверки качества кода:

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

 

Вопросы:

 

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

В данном случае все зависит от объема компании. Если эта компания маленькая – ей в любом случае не получится это продать, потому что они не смогут уложиться в бюджет с учетом проверки качества. Если говорить о компаниях побольше – средних и крупных – тут уже дело в убеждениях. Когда у компании распределенная система из 300 магазинов, то в случае маленькой оплошности в обмене вся сеть встанет. Сколько вы денег потратите на ее восстановление – непонятно, зависит от критичности ошибки. Но если вы эту проблему уже исправили, и вам нужно не допустить ее возникновение заново – вы напишете тест и потом сэкономите деньги на том, что одно и то же у вас два раза не случится. Бизнесу можно доказать необходимость проверок только на примерах каких-то ошибок либо простоя. Либо для некоторых компаний это вопрос престижа – мы контролируем качество. Соответственно, стоимость компании за счет этого растет.

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

С одной стороны, есть проблемы, которые в любом случае по закону Мерфи когда-то случатся. Соответственно, тестирование дает возможность этой ошибке не повториться. То же самое, что мы можем в логике программы поставить защиту от дурака, ограничить пользователя, чтобы он не совершал ошибки – так же и с кодом. Если у вас произошла какая-то проблема, мы бизнесу гарантируем, что эта ошибка больше не повторится. По поводу того, что бизнес от нас требует заранее предугадывать все недочеты, тут тоже больше работа для РП-шника, который может объяснить, что это потом будет проще сопровождать, потому что, если бизнес не должен работать только на внедрение. Мы-то внедрили, посопровождали какое-то время и ушли. А потом все это остается на плечах бизнеса. И они будут тратить денег намного больше, чем они тратили до этого – в любом случае. Мне кажется, нужно индивидуально подходить к каждому и объяснять, что и как.

Как Swagger натянуть на JSON по RMQ?

Если говорить, по порядку, Swagger – это спецификация описания REST API. RMQ – это просто транспорт из одной точки в другую. Если вопрос в том, как описать сервис RMQ – то я не отвечу, потому что нужно смотреть сам проект RMQ, где описывается его REST-сервер, чтобы с ним общаться. Если мы говорим про решение внутри 1С, то есть готовый скрипт, который формирует JSON-файл, потом отправляет его через HTTP по RMQ в то место, где у вас размещается сервер со Swagger, который через UI отображает ваши API. И там будет подхватываться по определенной ссылке.

Вы выгружаете конфигурацию в Git через «Выгрузить конфигурацию в файлы?»

Если говорить про хранилище, выгрузка автоматизирована – все выгружается через GitSync, потому что люди не должны на это тратить время. Если мы говорим про уже какие-то свои разработки. У меня написаны скрипты, чтобы конфигурации, которые не прикреплены к хранилищу, при определенном триггере выгружались в файлики, чтобы я с ними что-то мог сделать – открыть в Visual Studio Code, либо сгенерировать документацию, либо в том же самом SonarQube это все проверить. Для каких-то своих действий это можно сделать ручками или с помощью скрипта, а для перевода истории хранилища в Git – это все можно автоматизировать. Например, через GitSync или GitConverter.

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

Если мы говорим про проблемы, которые мы выявили для себя через PhoenixBSL, это в зависимости от их критичности. Если я зашел в модуль, увидел, что там непарное использование транзакций или неправильно в попытке указано ОтменитьТранзакцию, это решается в рамках текущего времени. Единственное, что тут нужно закладывать время на тестирование. Потому что вы поправили, должны еще проверить. А еще лучше – вы должны написать тест, что у вас ничего не упало и все хорошо. Если говорить про SonarQube – тут время не оценить. Это работа ведется непрерывно. Если у вас в команде 5-10 человек – это еще можно сдержать. Если у вас команда больше, а если еще у нас несколько команд, то это работа ведется только непрерывно, ведется определенными людьми, которые это все анализируют. А еще лучше находить и исправлять ошибки при код-ревью, до того, как это попало в SonarQube. Если это уже попало в SonarQube – это значит, этот код уже помещен в хранилище, значит, мы его уже скоро внедрим. Поэтому люди должны заранее это еще посмотреть. Ведущие разработчики должны проанализировать, что у вас там написано. Но бывает часто – рук не хватает на ревью кода.

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

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

Как ускорить SonarQube? Сейчас фоновое задание по обработке УПП отрабатывает за 2.5 часа.

Вы можете анализировать полностью все УПП, либо вы хотите анализировать только свой код. Вы можете ускорить работу SonarQube за счет отключения анализа того, что стоит на замочке. Потом вам нужно понимать, на чем у вас просадка. Вы можете этот проект у себя на компьютере развернуть, и через BSL LS запустить анализ и посмотреть – сколько времени этот анализ занимает у вас. Может быть, проблема с сервером, на котором SonarQube развернут. Может быть, там памяти не хватает. Можно тоже упереться в память. Либо она вообще упадет, не проанализируется. И последнее – не анализируйте регламентные отчеты. Они вам не нужны. Если вы, конечно, их не дорабатываете. Они очень много занимают файлов и очень много времени тратится, чтобы их проанализировать. И нужно правильно настроить конфиг анализа проекта. Исключить xml-файлы, анализировать только файлы с расширением bsl. И пользоваться последними релизами плагина, который с каждым разом становится все быстрее. Это даст вам экономию времени. Если мы где-то развернули SonarQube, обязательно нужно использовать реальную СУБД – MS SQL или PostgreSQL, не встроенную. Если вы используете встроенную базу, вы потом не обновитесь. Есть костыльные способы все это перевести в нормальную базу данных и разместить на сервер, но хапнуть горя, пока это делается. Мы используем PostgreSQL.

 

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

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Новосибирск.Online. Больше статей можно прочитать здесь.

Приглашаем всех принять участие в INFOSTART EVENT 2021 (6-8 мая, СПб).

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. wtlz 202 09.04.21 12:45 Сейчас в теме
Вот это годнота!
Особенно рад первому упоминаю PhoenixBSL на инфостарте - для меня это было настоящее открытие.
olegtymko; +1 Ответить
3. olegtymko 750 09.04.21 15:13 Сейчас в теме
(1) я очень ленив и все не могу про него написать статью..)
2. surikateg 09.04.21 15:03 Сейчас в теме
Натравил PhoenixBSL на общие модули УТ, в УправлениеПечатью получил 4 ошибки и 39 предупреждений, в УправлениеКонтактнойИнформацией 5 ошибок, 91 предупреждение. Кто прав? Стоит ли писать код лучше чем в типовом решении?
4. olegtymko 750 09.04.21 15:14 Сейчас в теме
(2) это не все проверки. Пока феникс не умеет подцеплять метаданные автоматом. А вообще - качество вещь относительная. Главное править критические и важные баги.
25. Зеленоград 12.04.21 16:37 Сейчас в теме
(2) А на ЗуП 3.1 можно натравить?
5. booksfill 09.04.21 18:13 Сейчас в теме
Я что-то не смог найти, где в PhoenixBSL можно настраивать правила, кто-нибудь знает?

P.S.
Удручает, когда нельзя изменить макс. длину строки,
отключить крайне спорное предупреждение о кол-ве пробелов после \\,
совершенно неясно почему авторы правил решили, что всегда является ошибкой использование ТекущаяДата вместо ТекущаяДатаСеанса и т.п.
6. nixel 1057 09.04.21 20:40 Сейчас в теме
(5) Phoenix bsl для анализа использует BSL Language Server, который конфигурируется через json файл. Параметры конфигурационного файла описаны в документации https://1c-syntax.github.io/bsl-language-server/dev/features/ConfigurationFile/
10. booksfill 10.04.21 10:09 Сейчас в теме
(6)Спасибо.
1. Но чтобы что-то отредактировать, надо это что-то иметь. Я вижу вы в этом разбираетесь намного лучше, может быть подскажете, где этот файл можно взять?

2. Я верно понимаю: что потом можно будет подключить файл через настройки программы?

3. Отредактировать руками JSON, разумеется, могу, но нет ли удобной приблуды, или только linux way?
13. nixel 1057 10.04.21 13:00 Сейчас в теме
(10) файл нужно создать руками :) это обычный json, в нем нет ничего сложного.
Если его редактировать через visual studio code, то будет работать автокомплит и всплывающая подсказка по параметрам.

И да, в настройках феникса можно указать путь к нему.
16. booksfill 10.04.21 19:03 Сейчас в теме
(13)Немного не понял, т.е. надо руками воссоздать все те правила, что работают сейчас в фениксе и потом их править?
Или я, скажем, могу добавить только правило проверки длины строки, а остальное будет браться по-умолчанию?
17. nixel 1057 11.04.21 14:20 Сейчас в теме
(16) достаточно переопределить настройки конкретного правила. Остальные правила будут иметь настройки по умолчанию.
20. booksfill 12.04.21 09:12 Сейчас в теме
(17)Большое спасибо! Все понял, пойду экспериментировать.
21. nixel 1057 12.04.21 09:24 Сейчас в теме
(20) приходите к нам в чат :)
23. booksfill 12.04.21 14:45 Сейчас в теме
(21)Не очень понял как попасть в чат, поэтому напишу здесь:
При подключении своих правил надо следить за правильностью указания пути.
Случайно добавил пробел в конец пути и... - программа ни на что не ругается, но не запускает проверку и не дает открыть настройки.
Лечится через ручную правку конфигурационного файла.
24. nixel 1057 12.04.21 14:47 Сейчас в теме
(23) телеграм-чат - @bsl_language_server

> Случайно добавил пробел в конец пути

куда добавили? в настройках PhoenixBSL?
7. Артано 719 09.04.21 22:05 Сейчас в теме
Отличный материал. Мог бы поспорить по некоторым формулировкам и утверждениям. Но всё же главное в публикации это обзор инструментов и сделано это очень хорошо.
8. muskul 10.04.21 05:32 Сейчас в теме
Почему есть куча статей, стандартов, автопроверок и так далее, а на выходе 90% 1с решений глюкавое и тормознутое
9. olegtymko 750 10.04.21 06:16 Сейчас в теме
(8) Причин масса, одни из них:
* Большая кодовая база
* Много легаси (код со временем устаревает)
* Универсальность решений

Тесты, CI / CD у вендора однозначно есть, но часто этого бывает мало.
11. booksfill 10.04.21 10:20 Сейчас в теме
(9)Мне кажется, что забыли упомянуть кривую архитектуру, а также "эффективных программистов", которые пытаются это преодолеть экзотическими путями.
Напрмиер. ЗУП 3. с их сборкой запроса в 100500 местах и попыткой сокрытия этих сложностей путем создания функций, которые как-бы и не заставляют вас лезть в механизм. И все это отлично работает, пока, не дай бог, что-то пойдет не так , или надо будет доработать. Какова вероятность, что у кого-то будет желание и время потратить месяц на разборки со всей этой "гениальной" кашей.? Думаю в 99,9% случаев получим смесь ежа с ужом.

Или механизм реализации асинхронных методов (я в курсе, что сейчас поправили)? Он же по сути вынуждает плодить никому не нужные методы, и кстати, далеко не всегда один - попробуйте поработать ассинхронно с потоками ...
asupsam; smit1c; director04; +3 Ответить
12. user1534961 10.04.21 12:24 Сейчас в теме
А в чем разница между оптимизацией и рефакторингом? Оптимизация имеет цель повышение производительности, а рефакторинг это только читабельность кода, разве не так?
Если речь идет о реструктуризации (когда программист объединяет код нескольких своих коллег или напротив, выделяет собственный блок из общего процесса), то сам рефакторинг без заказчика качества кода не повышает и не интересен.
В конфигурации есть возможность провести рефакторинг по одной или выборочно нескольким подсистемам? Но сначала эти подсистемы надо поаыделять.
FatPanzer; +1 Ответить
14. leobrn 474 10.04.21 14:04 Сейчас в теме
PhoenixBSL взял на вооружение, интересно будет потестировать
18. olegtymko 750 11.04.21 16:24 Сейчас в теме
(14) Предложения / досады можно фиксировать здесь -> https://github.com/otymko/phoenixbsl/issues
15. karpik666 3403 10.04.21 18:00 Сейчас в теме
Спасибо, Олег, как всегда, было очень интересно
19. olegtymko 750 11.04.21 16:24 Сейчас в теме
(15) Очень рад, если доклад был полезен / интересен )
22. Поручик 4547 12.04.21 12:41 Сейчас в теме
Быстро, дёшево, качественно. Выберите один из пунктов.
Вылизывать можно до бесконечности.
26. пользователь 25.11.21 17:16
Сообщение было скрыто модератором.
...
Оставьте свое сообщение

См. также

Снегопат - расширение Конфигуратора 8.2/8.3 от orefkov Промо

Снегопат, openconf v8 1cv8.cf Россия Платные (руб)

Работать в Конфигураторе становится еще удобнее и производительнее. Усилий меньше - результат больше! Будь программистом, а не кодером.

16.12.2011    188308    1    orefkov    1094    

Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода Технологический журнал v8 Бесплатно (free)

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

07.09.2021    4213    ivanov660    23    

Распространенные ошибки разработчиков, приводящие к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода v8 Бесплатно (free)

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    9519    ivanov660    77    

Антипаттерны программирования в 1С

Рефакторинг и качество кода v8 Бесплатно (free)

Поговорим про плохой стиль программирования и рассмотрим 17 часто встречающихся антипаттернов.

19.07.2021    10212    ivanov660    121    

Чек-листы для проведения Code Review

Рефакторинг и качество кода v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

17.05.2021    8296    Alexsandr_Retunskiy    99    

Ускорение расчета себестоимости УПП 1.3 в несколько раз

Рефакторинг и качество кода Закрытие периода v8 УПП1 БУ УУ Бесплатно (free)

Как определить причину медленного расчёта себестоимости в УПП 1.3, один из вариантов поиска проблем производительности с помощью инструментов 1С и ускорения расчёта средствами встроенного языка

02.02.2021    3620    RPGrigorev    19    

Реальный кейс по внедрению CodeReview

Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

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

20.01.2021    1939    Alexsandr_Retunskiy    3    

Операторы перехода в программном коде: использовать или нет?

Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

Рассмотрим ситуации использования операторов перехода Перейти (GoTo), Возврат (Return), Прервать (Break), Продолжить (Continue). Как вы считаете - это дурной тон, нормальная практика или зависит от ситуации?

16.11.2020    3880    ivanov660    23    

Чистый кот (Clean cat)

Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

От автора легендарного бестселлера "Совершенный кот".

04.11.2020    1907    vasilev2015    25    

Доработайте это "немедленно", или как уменьшить доработки конфигурации

Рефакторинг и качество кода v8 Россия Бесплатно (free)

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

25.09.2020    4207    Богатырев Артур    24    

Метод борьбы с большим количеством комментариев в коде

Рефакторинг и качество кода Практика программирования v8 1cv8.cf Бесплатно (free)

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

08.09.2020    1550    tambu    9    

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

Рефакторинг и качество кода v8 Бесплатно (free)

Наличие в 1С-решениях некачественного кода мешает их поддержке и эффективному развитию. Как добиться соблюдения стандартов разработки при написании кода и внедрить бюджетный Code Review с помощью инструментария на основе АПК (Автоматизированной проверки конфигураций) на конференции Infostart Event 2019 Inception рассказал технический руководитель компании Бизнес Лоджик Иван Козлов.

22.06.2020    4159    kozlov.alians    1    

Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

Рефакторинг и качество кода Сценарное тестирование v8 Бесплатно (free)

Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

29.05.2020    5299    grumagargler    14    

Рефакторинг в редакторе модулей

Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

Для тех, кто не пользуется Ctrl+Alt+R. “Контролируемый процесс улучшения кода без написания новой функциональности”, “Равносильное преобразование алгоритмов” и т.п в данной статье НЕ рассматриваются. Тема статьи: замечательные команды из подменю Рефакторинг контекстного меню редактора модулей в конфигураторе. В статье описано, как команды из подменю Рефакторинг помогают при написании кода

10.03.2020    4760    pparshin    5    

Качество кода: Поведенческие паттерны проектирования

Рефакторинг и качество кода v8 Бесплатно (free)

Поговорим про применение паттернов проектирования в разработке на 1С.

03.03.2020    9377    ivanov660    0    

Боремся с запросами в циклах. Мой опыт рефакторинга запросов

Рефакторинг и качество кода v8::Запросы 1cv8.cf Бесплатно (free)

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

02.03.2020    9517    aximo    55    

Качество кода: слабое связывание и высокая сопряженность (Low coupling and High Cohesion)

Рефакторинг и качество кода Бесплатно (free)

Поговорим о некоторых общепринятых подходах и принципах разработки кода.

10.02.2020    11578    ivanov660    90    

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

Рефакторинг и качество кода SonarQube Бесплатно (free)

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

30.12.2019    11587    olegtymko    10    

Стабильность превыше всего

Рефакторинг и качество кода v8 Бесплатно (free)

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

07.11.2019    10261    YPermitin    40    

Оценка скорости кода. Сложность алгоритма

Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

Эта тема одной из первых всплывает на собеседовании программистов языков вроде Java и C, но она почти неизвестна в "мире 1С". Поговорим о вычислительной сложности алгоритмов.

07.10.2019    6763    m-rv    12    

Управление качеством кода

Математика и алгоритмы Рефакторинг и качество кода SonarQube EDT v8 Бесплатно (free)

О SonarQube, АПК, EDT. Какие преимущества дает их использование. Для каких команд подходит.

22.07.2019    19647    Stepa86    40    

Как завести у себя в команде код-ревью. Отвечаем на вопросы

Рефакторинг и качество кода Бесплатно (free)

Дадим советы как начать использовать у себя в команде код-ревью (code-review), а также ответим на вопросы читателей.

17.07.2019    13058    ivanov660    31    

По следам код-ревью

Рефакторинг и качество кода v8 Бесплатно (free)

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

09.07.2019    14651    ivanov660    111    

Управляй качеством кода 1С с помощью SonarQube

Рефакторинг и качество кода SonarQube Россия Бесплатно (free)

Управляй техническом долгом проектов 1С с помощью SonarQube. В статье рассматривается пример применения SonarQube при разработке.

07.07.2019    58450    olegtymko    246    

Что такое рефакторинг и в чем его цели

Рефакторинг и качество кода Практика программирования v8 Бесплатно (free)

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

30.10.2018    13930    eu_genij    34    

Повышение качества разработки. Статья 3. Ошибки программы

Математика и алгоритмы Рефакторинг и качество кода Практика программирования Бесплатно (free)

Учебный курс по теории и практике программирования. Бесплатно. В виде структурированного текста. Статья 3. Эта статья посвящена ошибкам программ, их классификации и способам исправления.

10.07.2018    22712    Артано    92    

OneStyle. Улучшенное форматирование кода в конфигураторе

Инструментарий разработчика v8 Абонемент ($m)

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

1 стартмани

19.06.2017    29519    24    Stepa86    46    

Как писать неподдерживаемый код

Рефакторинг и качество кода Практика программирования Бесплатно (free)

Вы хотите чтобы Вы были самым ценным сотрудником компании? Чтобы Вас носили на руках? Тогда эта статья для Вас. Эти знания передаются из поколения в поколение и представляют особую ценность в умелых руках.

25.08.2015    23556    vandalsvq    64    

Типичные ошибки, некоторые вопросы качества и эффективности работы при разработке в 1С

Рефакторинг и качество кода Практика программирования Бесплатно (free)

В этой статье мы приведем набор типичных и часто встречающихся ошибок при разработке в 1С (скорее всего особенно актуально для начинающих программистов). Предложим набор советов и рекомендаций по улучшению качества кода и работы при использовании типового инструментария. Это первая часть из 24 пунктов. Бонусом к каждому пункту мы привели разъяснения и комментарии.

15.02.2015    26404    ivanov660    42    

Как повысить качество разработки своих проектов под 1С?

Методология Рефакторинг и качество кода Бесплатно (free)

Здравствуйте уважаемые коллеги. Мы – небольшое франчайзи (4 человека), которое занимается разработкой под 1С вот уже более 2х лет. После первого года работы возникли некоторые проблемы с качеством кода, поскольку начался стремительный рост сложности проектов и, соответственно, начало появляться большое количество неприятных ошибок. В статье я постараюсь рассказать о тех мерах, которые мы приняли для повышения производительности труда программиста и качества написанного им кода. Кому интересно прошу под кат.

11.03.2013    26224    akomar    80    

Открытая просьба разработчикам подсистем

Рефакторинг и качество кода v8 1cv8.cf Россия Бесплатно (free)

Давайте жить дружно. Письмо - буквально, мольба человека который приобрел несколько подсистем и теперь пытается их банально внедрить. Итого 4 подсистемы 1 приобретена тут одна поставлена франчами и 2 открытые с ограниченным функционалом.

29.12.2010    21829    iov    110    

Мастер-класс от Poppy (практикум по рефакторингу)

Рефакторинг и качество кода Практика программирования v8 1cv8.cf Россия Бесплатно (free)

Попался на глаза код неопытного программиста. Не смогла пройти мимо, захотелось выполнить рефактроинг. Вот что из этого получилось.

04.11.2008    18954    poppy    33    

Основы менеджмента кода в 1С

Математика и алгоритмы Рефакторинг и качество кода Практика программирования Россия Бесплатно (free)

Продолжаем тему рефакторинга, начатую на примере "Глокой Куздры" Итак, каковы основные принципы поддержания кода в рабочем состоянии?

17.10.2008    33493    keleg    194