Bsl 1c что это

Обновлено: 09.01.2025

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

Итак знакомьтесь, интегрированный стенд разработки!

Общие принципы архитектуры

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

Процесс

Жизненный цикл любого решения практически не меняется в зависимости от масштаба и сложности проекта. Он включает в себя: анализ, проектирование, разработку, тестирование, внедрение, сопровождение, вывод из эксплуатации. Чтобы получить максимальную эффективность, каждый из этих процессов должен быть выверен и согласован с предшествующими и последующими процессами, объединен в подобие автоматизированного конвейера, который может тиражироваться под неограниченное количество проектов. Решить поставленную задачу, позволила реализация системы в виде связанных через экспортируемые API микросервисов в изолированных контейнерах, которую возможно развернуть как в облачном сервисе, так и в локальной сети предприятия.

Вот так выглядит наш стек, реализующий процесс:

Мы постарались свести к минимуму использование платных сервисов с закрытым исходным кодом, что положительно отразилось на стоимости владения. Практически все сервисы с открытым исходным кодом и работают на ОС Linux.

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

Проектирование (Сервис Проектирования Прикладных Решений)

Один из наиболее значимых этапов при старте проекта — проектирование будущего решения на основе анализа требований. Основная задача — максимально понятно, однозначно и быстро описать архитектуру будущего решения, в терминах понятных как разработчику/инженеру, так и консультанту. Описать метаданные, алгоритмы реализуемых бизнес-процессов. При этом, хотелось максимально задействовать готовые, быстро настраиваемые под конкретные условия шаблоны, которые можно адаптировать к данным на входе и получить проектную документацию на выходе.

Мы внедрили конфигурацию «1С: СППР» в качестве единого интерфейса для проектирования прикладных решений, значительно переработали концепцию описания бизнес-процессов и функций, а также проектирования ТП (ФДР). Еще автоматизировали процессы генерации документации через интеграцию с функционалом «1С: ДО» и микросервисами по генерации документов формата docx.

«1С: СППР». Редактирование информации о проекте:

«1С: СППР». Отчёт по процессам:

«1С: СППР». Редактирование метаданных объектов:

«1С: СППР». Редактирование схемы бизнес-процесса:

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

Разработка (Сервисы непрерывной интеграции, инспекции и тестирования)

Мы постарались сфокусироваться на возможности всестороннего, непрерывного, автоматизированного контроля качества разрабатываемого кода, чтобы гарантировать соответствие установленному в КРОК стандарту. Причем, даже если привлекаем сторонние команды разработчиков, методики, инструменты и стандарты разработки которых могут существенно отличаться от принятых у нас.

Gitlab. Теперь возможно прокомментировать любую строку помещаемого коммитом кода:

Gitlab. Провести «Code Review» c подсветкой синтаксиса:

Gitlab. Получить наглядную картину изменений кода в новом коммите:

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

SonarQube:

Каждая проверка обновляет информацию отслеживаемых метрик качества кодовой базы, таких как:

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

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

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

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

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

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

Тестирование (сервис непрерывного тестирования)

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

Запуск процессов тестирования, так же как инспекция кода, привязан к событию коммита в репозиторий проекта. Для unit-тестов подразумевается разработка теста параллельно с разработкой функционала. Непосредственно перед их выполнением производится автоматизированное развертывание последней версии конфигурации в подготовленную тестовую информационную базу. Затем запускается клиент, который выполняет сценарии тестирования для уже реализованного функционала. Тесная интеграция сервисов автоматизированного тестирования с BSL плагином SonarQube позволяет вычислить такой параметр как покрытие кода тестами. Результат прогона тестов — отчет, который загружается в систему анализа и визуализации результатов тестирования ReportPortal. Этот сервис представляет собой портал отчетов, в котором агрегируются данные о прогонах тестов (статистика и результаты), производится базовое обучение системы по категоризации падений и дальнейшее автоматическое определение причин. Все параметры прогонов тестов доступны в удобном веб-интерфейсе с различными досками для графиков, диаграмм (виджетов). Для расширения функций портала возможно использовать собственные расширения.

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

ReportPortal. Дашборд:

ReportPortal. Неудачные запуски тестов:

ReportPortal. Типы дефектов:

Развитие

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

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

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

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

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

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

Реализация протокола language server protocol для языка 1C (BSL) - языка 1С:Предприятие 8 и OneScript.

Возможности¶

Поддерживаемые операции протокола¶

Запуск из командной строки¶

Запуск jar-файлов осуществляется через java -jar path/to/file.jar .

При запуске BSL Language Server в обычном режиме будет запущен сам Language Server, взаимодействующий по протоколу LSP. Для взаимодействия используются stdin и stdout.

Запуск в режиме анализатора¶

Для запуска в режиме анализа используется параметр --analyze (сокращенно -a ).

Для указания каталога расположения анализируемых исходников используется параметр --srcDir (сокращенно -s ), за которым следует путь (относительный или абсолютный) к каталогу исходников. Для формирования отчета об анализе требуется указать один или "репортеров". Для указания репортера используется параметр --reporter (сокращенно -r ), за которым следует ключ репортера. Допустимо указывать несколько репортеров. Список репортетов см. в разделе Репортеры.

Пример строки запуска анализа:

При анализе больших исходников рекомендуется дополнительно указывать параметр -Xmx, отвечающий за предел оперативной памяти для java процесса. Размер выделяемой памяти зависит от размера анализируемой кодовой базы.

Запуск в режиме форматтера¶

Для запуска в режиме форматтера используется параметр --format (сокращенно -f ).

Для указания каталога расположения форматируемых исходников (или файла) используется параметр --src (сокращенно -s ), за которым следует путь (относительный или абсолютный) к каталогу исходников (или файлу).

Пример строки запуска форматирования:

Конфигурационный файл¶

Подробное описание конфигурационного файла приведено на этой странице

Благодарности¶

Огромное спасибо всем контрибьюторам проекта, всем участвовавшим в обсуждениях, помогавшим с тестированием.

Спасибо компаниям, поддерживающим проекты с открытым исходным кодом, а особенно тем, кто поддержали нас:

С помощью YourKit Java Profiler мы мониторим и улучшаем производительность проекта.

Создатель профессиональных инструментов разработки программного обеспечения, инновационных и мощных, JetBrains поддержал наш проект, предоставив лицензии на свои продукты, в том числе на IntelliJ IDEA Ultimate .

За 2 месяца мы внедрили программу в свои рабочие процессы, благодаря чему качество кода контролируется теперь не вручную, специально выделенным человеком, а автоматически.

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

Мы разобрали и приняли новые стандарты и надеемся, что в будущем производитель сделает их описание еще более полным. Очень полезными в работе стали методические пособия, несмотря на краткость приводимых в них формулировок. Стоит заметить, что SonarQube 1С (BSL) Plugin предьявляет достаточно высокие требования по ресурсам: например: на ERP необходимо минимум 16 ГБ оперативной памяти. Эти требования мы выполняем, и программа решает те задачи, ради которых мы ее установили.

Нам был просто необходим быстрый и удобный способ повышения качества написанного кода и отслеживания соблюдения стандартов разработки. Изучив рынок, мы сопоставили самые подходящие программы, из которых выбрали открытую платформу SonarQube и плагин SonarQube 1С (BSL) Plugin – разработку компании «Серебряная пуля». Важным преимуществом этих IT-решений были: возможность тестирования всей ERP-системы за один раз и методические рекомендации по созданию единой сборочной линии с использованием Jenkins и других инструментов.

С. В. Родионов Зам. руководителя Депертамента проектов внедрения и консалтинга

Компания 25 лет специализируется на автоматизации управления и учета предприятий, продаже программного обеспечения, компьютерного и торгового оборудования, а также на разработке собственных IT-решений. Мы работаем с организациями в любых отраслях бизнеса и управления. На сегодняшний день ГЭНДАЛЬФ автоматизировал более 23 000 и ежемесячно обучлуживает более 3 000 предприятий.

Компания 25 лет специалиализируется на автоматизации управления иучета предприятий, продаже программного обеспечения, компьютерного и торгового оборудования, а также на разработке собственных IT-решений. Мы работаем с организациями в любых отраслях бизнеса и управления. На сегодняшний день ГЭНДАЛЬФ автоматизировал более 23 000 и ежемесячно обучлуживает более 3 000 предприятий.

С. В. Родионов Зам. руководителя Депертамента проектов внедрения и консалтинга

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

Платформа SonarQube предоставляет более 20 различных метрик По надежности По безопасности По сопровождаемости и другие метрики -->

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

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

Избавьтесь от технического долга и дорогого code-review

Задачи которые решает SonarQube 1С (BSL) Plugin:

Оценка накопленного долга в часах и деньгах

Динамика технического долга по дням

Быстрая проверка кода

Автоматическая проверка ускорит разработку

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

Избавление от дублей сделает код легче

260+ проверок чтобы повысить качество кода

Внедрение единого code style и стандартов разработки

Общее ограничение на все проекты - 13 млн. строк кода Аутентификация с помощью GitLab, GitHub или BitBucket

Поддержим на всех этапах внедрения

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

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

Причины возникновения могут быть разными:

недостаточная компетентность кадров;
давление со стороны бизнеса;
плохо спроектированная архитектура и отсутствие документации;
отсутствие процессов review и refactoring;
отсутствует тестирование.

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

Как управлять долгом?

Управлять техническим долгом можно с помощью нескольких подходов:

Внешний аудит — привлечение сторонней компании. Затратно, и на результат может влиять человеческий фактор.
Внутренний аудит — визуальная проверка кода (code review). Опять же на результат влияет человеческий фактор и иногда необъективность.
Автоматизированная проверка кода — применяются статические анализаторы. В мире 1С используется конфигурация 1С:АПК.
Непрерывная проверка кода (continuous code inspection).

SonarQube — программное решение для непрерывного анализа и измерения качества кода. На текущий момент платформой поддерживается более 27 языков программирования. К сожалению, язык 1С не включен в официальный перечень поддерживаемых языков SonarQube.

На рынке существует как минимум два плагина для поддержки языка 1С в SonarQube, и одно из них это SONARQUBE 1C (BSL) Plugin — решение от SilverBulleters.

Серебряная пуля есть — 1C (BSL) Plugin для SonarQube, предназначенный для непрерывного анализа и измерения уровня качества кода 1С-решений:

What's Changed

New Contributors

Contributors

Assets

This commit was signed with the committer’s verified signature.

Исправлено падение сервера на запросе textDocument/documentColor , отправляемом из окна git diff в vscode

Assets

This commit was signed with the committer’s verified signature.

Общие изменения

Добавлена обработка запросов textDocument/documentColor и textDocument/colorPresentation для отображения представления цвета. Обрабатываются обращения к системному перечислению WebЦвета и создание цвета с помощью конструктора Новый Цвет ;
Добавлена обработка запроса textDocument/selectionRange для формирования дерева областей выделения от текущей позиции (команда Expand Selection в VSCode );
Линзы когнитивной сложности и цикломатической сложности теперь показывают текст на языке сервера (параметр language конфигурационного файла);
Добавлен репортер в формат SARIF;
Удален репортер в Generic coverage , метрика covlocData объявлена устаревшей. При необходимости получения данных по строкам к покрытию используйте другие инструменты, например Coverage41C ;
Добавлены диагностики:
- Все возможные пути выполнения функции должны содержать оператор Возврат ( AllFunctionPathMustHaveReturn );
- Назначение псевдонимов выбранным полям в запросе ( AssignAliasFieldsInQuery );
- Флажок «Устанавливать права для новых объектов» должен быть установлен только у роли ПолныеПрава ( SetPermissionsForNewObjects );
- После вызова асинхронного метода есть строки кода ( CodeAfterAsyncCall );
- встроенный словарь Language Tool обновлен до версии 5.4;
- Spring Boot обновлен до версии 2.5.4;
- MDClasses обновлен до версии 0.9.2;
- BSL Parser обновлен до версии 0.19.4;
Изменения для разработчиков
- BSL Language Server теперь публикуется в Maven Central. Снапшоты develop-ветки доступны в Sonatype Snapshot Repository. Версионируемый javadoc доступен на javadoc.io;
- javadoc теперь содержит кросс-ссылки на объекты mdclasses и antrl4;
- Добавлен механизм Expression Tree для построения дерева выражений с учетом приоритетов операций. См. пакет com.github._1c_syntax.bsl.languageserver.utils.expressiontree ;
- Добавлен механизм Control Flow Graph для построения графа потока управления в блоке кода ( CodeBlockContext ). См. пакет com.github._1c_syntax.bsl.languageserver.cfg ;
- Добавлен метод DocumentContext::getScriptVariantLocale , возвращающий вариант встроенного языка текущего файла. Интерфейс класса Resources расширен методами, принимающими Locale
- Изменения базовых настроек проекта, хранящихся в каталоге .idea больше не будут приводить к конфликтам и шуму в измененных файлах репозитория.
Assets

Assets

Assets

Assets

Общие изменения
- Добавлено отслеживание за смертью процесса, запустившего BSL Language Server в режиме LSP. В случае завершения родительского процесса BSL Language Server будет завершать свою работу через 30 секунд.
- В парсер описания метода добавлена обработка конструкций Array contains Something .
- В парсер описания метода добавлена обработка конструкций для составных типов-коллекций с примитивными типами элементов вида Массив из Строка .
- Изменены диагностики:
  - BSL Parser обновлен до версии 0.19.3;
  Assets
  
  This commit was signed with the committer’s verified signature.
  
  Читайте также: