1С:Элемент. Доступные библиотеки, их возможности, подходы к разработке

Меня зовут Александр Волков. В последние полтора года я активно работаю с технологией 1С:Элемент – занимаюсь прикладной разработкой сервиса «1С:Кабинет сотрудника», а в свободное время создаю open source-библиотеки для этой технологии.

Хочу рассказать о доступных библиотеках для технологии 1С:Элемент и поделиться опытом их разработки. Мы обсудим:

• Зачем вообще писать библиотеки, и почему это особенно актуально для 1С:Элемента.

• Какие библиотеки для 1С:Элемента уже существуют – как от вендора, так и в целом в сообществе. Сейчас их насчитывается примерно 20 штук.

• Как изначально проектировать приложение на 1С:Элементе, чтобы при переходе от монолита к библиотечной структуре не столкнуться с проблемами и сделать этот процесс максимально простым и безболезненным. На практике почти все, кто начинает писать на 1С:Элементе, стартуют с монолита, а позже приходят к необходимости разделения кода на библиотеки.

• Расскажу про свою небольшую библиотеку, которая стала попыткой создать для 1С:Элемента аналог БСП. Сначала я также написал монолит, затем начал выделять из него куски, которые могут быть востребованы в других проектах, а потом решил объединить все это в библиотеку и выложить в открытый доступ.

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

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

Что такое библиотеки… и почему «Библиотеки != Расширения» и «Библиотеки != Микросервисы»

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

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

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

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

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

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

Еще один момент, который стоит прояснить: библиотека – это не микросервис, это именно дополнение к вашему приложению.

• Если вы добавляете библиотеку, то такое расширение кодовой базы требует остановки основного приложения. А если вам требуется обновление библиотеки, то оно, как правило, также потребует обновления основного приложения – т.е. не избавляет нас от проблем изоляции обновления кодовой базы.

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

• Библиотеки зачастую полезны только в «симбиозе» с основным приложением.

Библиотеки фирмы «1С»

Теперь давайте пробежимся по библиотекам фирмы «1С». На странице в официальной документации перечислены все библиотеки, которые сейчас есть у вендора – как с ними работать, как их подключить, и что они могут (в том числе, со скриншотами):

• Форум – аналог форума, реализованного для конфигурации 1С:Документооборот. Площадка, где пользователи могут общаться на различные темы, задавать вопросы и получать советы.

• Рассылки и уведомления – библиотека, которая предназначена для информационных рассылок и уведомлений о прикладных событиях внешних (относительно приложения) получателей. Позволяет отправлять клиентам или пользователям рассылки по шаблонам на email или через SMS на номер телефона.

• Импорт табличных частей – аналог знакомой всем БСП-шной обработки «Загрузка из табличного документа». Позволяет импортировать табличные данные из Excel-файлов в справочники и документы приложения.

• Телеграм бот – подключает к приложению телеграм-бота для отправки и приема сообщений, а также обработки команд. Автор библиотеки – Матвей Серегин.

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

• Анкетирование – включает в приложение возможность создавать опросники и анкеты по аналогии с Google-формами или с Яндекс-формами.

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

Библиотеки сообщества

Теперь поговорим о том, какие библиотеки есть в сообществе разработчиков 1С:Элемента на GitFlic:

• Библиотека криптографии – упрощает работу с криптографией, добавляет дополнительные алгоритмы, особенно полезно для приложений, построенных на версиях 1С:Элемента ниже 8.0 (до версии 8.0 криптографии на клиенте не было и библиотека как раз предоставляет для этих случаев возможность такой работы).

• Библиотека контактной информации – аналог БСП-шного модуля контактной информации.

• Ставки НДС – позволяет создавать в приложениях свои ставки и описывать управление ими. По сути, это тоже аналог модуля БСП, которые подключает все ставки в перечисление, создает нужные объекты метаданных и методы для работы с ними.

• Аккаунты приложений – позволяет расширить системный справочник «Пользователи». Дело в том, что справочник пользователей в 1С:Элементе нерасширяемый, поэтому для того, чтобы его как-то переопределить, все создают для работы с аккаунтами пользователей свой дополнительный справочник. Эта библиотека как раз и реализует эту функциональность – ее можно использовать в своих приложениях.

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

• Классификатор стран мира – тоже аналог БСП-шной библиотеки. Там можно с ИТС скачать классификатор стран мира, загрузить его в справочник «Страны мира» и использовать в своем приложении.

• Генератор плана обмена – интересная и сложная библиотека, которая на основе плана обмена конфигурации 1С генерирует полный YAML-файл плана обмена для приложения 1С:Элемент, позволяя выбрать существующие в приложении метаданные.

• Календарь – библиотека с несколькими вариантами компонентов для календаря.

• Сериализация – упрощает работу с сериализацией.

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

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

Разработчики 1С привыкли писать приложения монолитно, а это приводит к следующим проблемам:

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

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

• Одни и те же объекты (классы) метаданных имеют разнородную структуру из приложения в приложение. Например, реквизитный состав знакомого всем справочника «Партнеры» в УТ и ERP отличается – мы просто привыкли писать монолит именно так, хотя в случае выноса справочника в библиотеку с использованием контракта, реквизитный ряд был бы везде одинаковый.

• При расширении библиотечного кода зачастую требуется адаптация основного прикладного кода.

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

Теперь давайте поговорим о том, как нужно писать монолит, если вы пишете его на 1С:Элементе

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

• «Общение» между подсистемами осуществляем через контракты и программный интерфейс. Например, я в своих библиотеках ограничиваю видимость рамками подсистемы практически для всех объектов и общих модулей – у меня ни один справочник не виден вне подсистемы. Оставляю видимым только один общий модуль под названием «ПрограммныйИнтерфейс» или «МояБиблиотекаAPI», и все общение с внешним миром моя подсистема проводит через него. Таким образом я контролирую общение с остальными частями приложения.

• Максимально абстрагируем бизнес-логику – стараемся всегда думать абстракциями. Не думаем бизнес-требованиями. Конечно, о них тоже нужно помнить, но в целом при разработке стараемся постоянно задавать себе вопрос: «А что будет, если нас попросят добавить сюда еще вот эту функцию?» «Как упростить добавление в этот запрос еще одного справочника?» и т.д.

• Максимально используем готовые библиотеки (при их отсутствии пишем и делимся с товарищами). Мы с вами уже поговорили о том, какие библиотеки есть, и где они выложены. Они постоянно развиваются и пополняются. Но если нужной вам библиотеки нет – напишите ее и поделитесь с другими. Это сэкономит время и вам, и коллегам.

Универсальное приложение

Возвращаемся к моей библиотеке, о которой я пытался рассказать.

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

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

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

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

Возможности библиотеки:

• Там есть библиотека цветов – например, вы можете задать корпоративную цветовую палитру и использовать ее внутри своего приложения. Не нужно каждый раз задавать кодировку цвета – достаточно написать БиблиотекаЦветов.ОсновнойКорпоративный, и цвет будет получен. А еще в вашем приложении можно будет переопределить этот корпоративный основной цвет – в библиотеке уже заданы базовые настройки, но вы из своего приложения можете их переопределить.

• Дополнительные компоненты. Реализовано то, что пока отсутствует в стандартных возможностях 1С:Элемента – например, прогресс-бар или еще один вариант сворачиваемых групп. В 1С:Элементе есть сворачиваемые группы, но у меня, на мой взгляд, реализовано посимпатичнее.

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

• Контактная информация. Практически в каждом приложении нужна работа с контактами. Здесь реализована возможность подключать контактную информацию к справочникам и документам – тоже одной строчкой кода.

• Журнал событий. Аналог журнала регистрации из 1С, адаптированный под 1С:Элемент. Причем в отличие от 1С, где для добавления записи в журнал регистрации нужно написать 3-4 строчки кода, здесь это сводится к одному вызову с двумя параметрами.

• Параметры сеанса и приложения. В 1С:Элементе нет встроенных параметров сеанса, и эта библиотека добавляет их поддержку. Подключаем, указываем, что приложение использует параметры сеанса, и можно пользоваться. При необходимости инициализацию параметров можно переопределить.

• Настройка подключения к V8. Большинство приложений на 1С:Элементе все равно взаимодействуют с V8, поэтому в библиотеке реализовано хранение настроек подключения. Не нужно писать с нуля.

• Общего назначения. Аналог БСПшного модуля «ОбщегоНазначения», его клиент-серверной части. Поддерживает работу с разными типами данных: с датами, числами, моментами времени, включает в себя СтроковыеФункцииКлиентСервер и другие. Например, можно выразить момент времени через строковое представление даты «Вчера», «Сегодня», а более ранние показывать конкретной датой: «28.01.1993».

Контракты

Чтобы все описанные возможности библиотек корректно работали в любом приложении, они реализованы на основе контрактов.

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

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

Есть три вида контрактов:

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

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

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

Теперь давайте разберем каждый из видов контрактов подробнее.

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

Например, у вас есть три справочника – «Контрагенты», «Пользователи» и «Сотрудники», и вы хотите использовать их объединенные данные в одном месте, например, в поле выбора. Причем так, чтобы система не предлагала выбрать справочник, а сразу показывала данные из трех справочников в одном общем месте. Это имеет смысл, когда у этих справочников есть какое-то общее свойство – например, телефон.

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

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

Контракт сервиса мы выбираем для изоляции подсистем и возможности переопределения базового поведения библиотеки нашим прикладным решением. На контракт сервиса может подписываться только код.

Примеры использования

Теперь давайте рассмотрим примеры использования контрактов.

Контракт сущности. Предположим, нам нужно реализовать планировщик событий, который объединяет три вида документов – «Встречи», «Задачи» и «Звонки».

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

Либо мы хотим сделать так, чтобы нам не нужно было каждый раз объединять в запросе данные этих справочников вручную через «ВЫБРАТЬ … ИЗ Документ.Встреча… ОБЪЕДИНИТЬ ВСЕ ... ВЫБРАТЬ … ИЗ Документ.Звонок … ОБЪЕДИНИТЬ ВСЕ … ВЫБРАТЬ … ИЗ Документ.Задача …».

Чтобы этого избежать, мы делаем следующее:

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

• Подписываем на этот контракт наши документы – Документ.Встреча, Документ.Звонок и Документ.Задача. На средней картинке видно, как это сделано в файле YAML-описания для объекта Документ.Встреча:
  НастройкиТипов:
  Документ.Объект:
  Контракты:
  - ЗапланированноеСобытие.Объект
  Таким образом мы говорим, что наш документ «Встреча» реализует этот контракт.

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

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

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

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

Контракт типа. Допустим, нам требуется хранить параметры сеанса и параметры приложения – с такой задачей при разработке на 1С:Элементе сталкивается практически каждый.

Для этого:

• Создаем контракт типа и называем его «ПоддерживаетПараметрыСеанса».

• Описываем в нем два свойства-структуры – «ПараметрыСеанса» и «ПараметрыПриложения», определяя в них те параметры, которые нам требуются.

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

• Подписываем на контракт «ПоддерживаетПараметрыСеанса» наше клиентское приложение.

• Зная, что у контракта есть свойство «ПараметрыСеанса», мы можем обращаться к нему через точку: «КлиентскоеПриложение.ПараметрыСеанса».

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

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

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

• Мы создаем контракт «ПереопределениеЦветовойСхемы» с единственной реализацией (Множественный:Ложь) – это означает, что на этот контракт может быть подписан только один общий модуль, не должно быть нескольких модулей с абстрактными методами для этого контракта.

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

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

Обратите внимание, что методы «КорпоративныйОсновной» и «КорпоративныйДополнительный» в контракте возвращают либо Число, либо Неопределено. Неопределено нам нужно, потому что в целевом приложении реализации контракта может не быть. Поэтому:

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

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

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

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

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

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

В библиотеках уже реализовано множество готовых объектов системы:

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

• Дальше через библиотеку «Телеграм бот» мы подключаем туда своего телеграм-бота.

• Так как мы – event-агентство, и у нас есть календарь событий, мы подключаем библиотеку «Календарь».

• Чтобы у нас в системе появилась возможность указывать места встречи из классификатора адресов, подключаем библиотеку «Адреса».

• Так как у нас есть обмен с 1С, мы подключаем библиотеку «План обмена» – она позволяет обмениваться с УТ и CRM.

• И поскольку у нас есть учет финансов, мы подключаем «Ставки НДС», чтобы немного упростить себе задачу и не реализовывать это самим.

По сути, всего 8 импортов и около 200 строчек кода – и у вас почти готово полноценное приложение.

Это похоже на опыт работы с Python, где мы подключаем 90 библиотек, пишем 10 строчек кода, и у нас готово полноценное приложение MVP-версии, которое уже можно показывать заказчику.

Подведем итог

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

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

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

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

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

• Гибкость разработки. Библиотеки и приложения можно разрабатывать и тестировать независимо друг от друга. При этом, благодаря обратной совместимости, библиотека может работать на одной версии технологии 1С:Элемент (например, 7.0), а основное приложение – на 8.0. При обновлении версии технологии вам не придется обновлять все приложение, библиотеку вы можете обновить позднее – она будет работать за счет совместимости.

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

Теперь немного минусов.

• Ограничение производительности – это, наверное, один из самых больших минусов. Если вы хотите из одной многофункциональной библиотеки (такой, как «Универсальное приложение») использовать только один какой-то модуль – например, библиотеку цветов – вам придется тащить всю кодовую базу. Все это будет импортироваться и использоваться при компиляции – в приложении будет 90% мусора. Но это минус именно использования больших библиотек.

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

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

Но по моему мнению, плюсы использования библиотек полностью перекрывают все эти минусы.

Идеи для разработки

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

• Например, можно реализовать коннектор к Redis. В телеграм-чате 1С:Элемента часто обсуждают подключение к Redis, но никто почему-то до сих пор не написал для этого полноценную библиотеку. При этом следует учитывать, что у 1С:Элемента нет нативной поддержки TCP, поэтому коннектор нужен именно по HTTP. Если кто-то возьмется за эту задачу – это будет очень востребованное решение.

• Можно написать библиотеку отзывов, которая позволит подключать отзывы к объектам приложения. Например, при создании CRM или маркетплейс-системы нам нужны отзывы на продавца или на товары. Можно написать библиотеку, которая будет подключаться к объекту одной строчкой и предоставлять возможность проставлять оценки, оставлять и просматривать отзывы.

• Graph TD. Было бы удобно иметь возможность выгружать обычное дерево значений (или таблицу значений) и генерировать на его основе файл Graph TD, чтобы получить из этих данных UML-модель процесса. Учитывая, что в 1С:Элементе нет такого объекта метаданных как бизнес-процесс, эта библиотека как раз позволила бы закрыть эту потребность. Условно, мы описываем бизнес-процесс в дереве, а дальше генерируем текст Graph TD, который может отрисовываться в диаграмму. Было бы полезно.

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

• Генератор Swagger-файлов. Его отсутствие – это серьезная боль, поскольку мы пишем на 1С:Элементе веб-приложения, а API описать не можем. Формируем описание либо руками, либо никак. Поэтому библиотека, которая будет генерировать Swagger-файл на основе метаданных проекта, многим бы пригодилась.

• Коннектор к ClickHouse. В чате 1С:Элемента тоже часто упоминается, что хорошо бы иметь коннектор к ClickHouse – хранить там данные и считывать их оттуда, чтобы использовать для аналитики, но пока никто не написал

Причем что касается последних двух библиотек, я их начал. По ClickHouse у меня уже реализовано выполнение простых запросов, обращение к локальному ClickHouse и размещенному в Yandex Cloud с авторизацией по сертификату. И для Swagger я уже получаю всю структуру метаданных, осталось только описать ее в формате OpenAPI. Но из-за отсутствия свободного времени у меня пока получается закончить эти две библиотеки. Если кто-то готов подключиться – я могу этим поделиться, и мы сможем выпустить эти библиотеки вместе.

Вопросы и ответы

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

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

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

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

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

Каким образом библиотеки подключаются в приложение – по аналогии с 1С:БСП или как в Python?

По аналогии с Python.
Библиотеки хранятся в приложении «Панель управления» (оснастка для управления сервером Элемента) как проекты. Версионирование также управляется консолью 1С:Элемента – например, там видно, что вышла новая поставка библиотеки, можно обновить.

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

Планируется ли обеспечить в 1С:Элементе обязательную обратную совместимость библиотек, чтобы при их использовании можно было быть уверенным, что даже старые версии будут корректно работать? Например, как в Java, где до сих пор можно переиспользовать библиотеки, созданные еще в 2003 году.

Здесь два момента.

Первый – обратная совместимость технологии. Начиная с седьмой версии, в технологии 1С:Предприятие.Элемент введен режим совместимости, который работает по аналогии с платформой 1С:Предприятие, где до сих пор поддерживаются старые режимы – например, 8.1. Таким образом, можно ожидать, что и 1С:Элемент будет достаточно долго сохранять поддержку библиотек, созданных на предыдущих версиях технологии.

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

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

А еще есть аннотация @Устарело. Разработчик может отметить несколько методов как устаревшие, и система начнет указывать другим разработчикам, что используется depricated API, предлагая перейти на новые методы. Через несколько релизов старые методы можно будет безопасно удалить.

Есть ли планы запустить маркетплейс по библиотекам?

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

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

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

Я знаю реальные кейсы автоматизированного тестирования приложений на 1С:Элементе, где используются стандартные инструменты тестирования для веб-разработки – например, Selenium и Playwright. То есть можно сказать, что автотестирование уже возможно, но пока это зачаточная стадия – направление активно развивается, но единой библиотеки для тестирования приложений на 1С:Элементе (как это сделано для 1С) пока нет.

Когда появится нормальная, удобная и читаемая документация по 1С:Элемент – с примерами и понятной структурой?

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

Кроме того, сейчас доступна интегрированная среда разработки (IDE) для языка 1С:Элемент Скрипт, который ранее назывался 1С:Исполнитель, со встроенными синтакс-помощниками – по работе с IDE, по самому 1С:Элемент Скрипт, по 1С:Шине и по 1С:Аналитике. Эту IDE можно скачать с сайта releases.1c.ru или без регистрации с отдельного сайта по 1С:Элементу – https://lang.1c.ru/.

С этого же отдельного сайта можно запустить среду облачного исполнения. И там же можно скачать официальный учебник от Максима Радченко – «1С:ЭЛЕМЕНТарно!» 1С:Элемент для будущих разработчиков: практикум 10-11 класс.

Плюс вы можете задавать вопросы в официальной телеграм-группе и через форму обратной связи (доступна в облачной версии 1С:Элемента и в статьях документации по кнопке «Была ли статья полезна»). Команда разработчиков прислушивается к отзывам, поэтому если вы видите, что чего-то не хватает для старта – обязательно пишите.

По опыту партнеров, порог входа для разработчиков, переходящих на 1С:Элемент, составляет около двух месяцев. Обычно, если дать доступ к инструментам и документации, уже через 6-8 недель специалисты уверенно чувствуют себя в новой среде.

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

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