Модульность в 1С – как следовать принципам DRY в реалиях 1С: Предприятие 8.3

Как говорят в англосфере, код должен быть сухим (dry). В противоположность этому они используют аббревиатуру wet, которая иронично расшифровывается как:

• write everything twice – мы очень любим писать все дважды);

• we enjoy typing – любим печатать на компьютере

• waste everyone's time – тратим время на каждого

Игнорируя забавные аббревиатуры:

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

• Вынесение повторяющегося кода в единый экземпляр упрощает дальнейшие изменения. Если нам потребуется поменять код, нам не потребуется менять его в двух местах. И тем более, нам не нужно менять его в 20 местах. Мы просто меняем его в одном месте.

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

Модульность

От этого мы переходим к модульности.

Модульность – это принцип DRY, разогнанный практически на все программистское коммьюнити.

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

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

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

Менеджеры пакетов

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

• Практически все серьезные языки имеют менеджеры пакетов. У некоторых языков есть более одного менеджера пакетов. Разработчики Facebook не были довольны стандартным менеджером пакетов для JavaScript, они написали свой и поделились им с коммьюнити.

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

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

  • Организации получают с open-source-модулей свои паблисити – смотрите, какие мы классные, у нас есть модули. Какой-нибудь программист находит этот модуль, а потом вспоминает, что есть организация, которая сделала этот классный модуль, ему сразу приходит мысль: «я готов с ними работать». Выложив модуль в open-source, вы получаете к нему бесплатных тестеров, которые найдут вам баги и спросят. Вы получаете потенциальных бесплатных контрибьютеров – это несколько сложнее, но также возможно. У всего этого много преимуществ. Как говорил GitHub: «Все, кроме основной бизнес-функциональности, должно быть в open-source». Продукт, которым вы реально зарабатываете деньги, конечно, будет closed-source – вы его шифруете, обфусцируете и т.д. А все остальное, все сопровождающие вещи – open-source.

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

А что в 1С?

Посмотрим, что у нас:

• До недавнего времени (до версии 8.3.9) с модулями в 1С все было совсем плохо. Чтобы до 8.3.9 собирать итоговую конфигурацию, отдаваемую заказчику, из модулей, которые были добавлены, требовалось использовать сложную систему построения через XML (возможность собирать конфигурацию из XML появилась раньше 8.3.9). Но так никто не делал, потому что это никому не нужно – слишком сложно и неудобно.

• Начиная с 8.3.9 появилась возможность добавлять общие модули в расширения – это позволило реализовать полноценную модульность. А начиная с 8.3.11 в расширениях можно хранить данные и делать реально интересные вещи.

• К сожалению, менеджера пакетов в 1С пока не существует – я про него не знаю. Инфостарт не является менеджером пакетов, потому что, возможно, ему недостаточно пакетов, и у него немного другая система.

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

Платформа как набор модулей?

В жизни я встречал некоторые возражения:

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

• Но платформа, честно, достаточно бедная по многим параметрам. Я привел буквально два примера:

  • У нас в платформе нет метода для сортировки массива. Это очевидная задача, которую хочется делать постоянно, но нельзя. В 1С всего 9 методов у массива, в JavaScript у массива 30 методов плюс есть пакеты, добавляющие дополнительные методы, потому что их не хватило каким-то программистам.

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

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

Библиотека стандартных подсистем?

Есть мнение, что у нас есть модули БСП, соответственно, они дают нам все то, что не дает платформа.

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

• БСП не является модулем, расширением, хотя стоило бы давно сделать его расширением.

• БСП не имеет префиксы, а это мешает работать всем остальным – про это даже была статья на Инфостарте.

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

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

Концепция модульной архитектуры

Итак, как это должно бы выглядеть?

• Каждый модуль – это отдельное расширение.

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

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

Глобальное пространство имен

Какие сложности возникают при работе с данной схемой?

• Во-первых, у нас глобальное пространство имен. Все имена в 1С – общие. Это и удобно, потому что нам, чтобы включить модуль, не нужно писать:
  #include ОбщийМодуль

• Чтобы глобальное пространство не приводило к сложностям с менеджером пакетов, я предлагаю использовать именную схему:
  <ИдентификаторКомпании>_<ИдентификаторМодуль>_<ПрикладноеИмя>

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

Ограничения в заимствовании типов

Заимствование типов в платформе ниже 8.3.20, конечно, реализовано так себе.

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

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

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

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

Ограничения в переопределении объектов

Далее у нас есть сложности с переопределением объектов.

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

• Чтобы с этим бороться, я реализовал паттерн publisher-subscriber на глобальном уровне – для всего 1С. Publisher-subscriber – это публикатор, источник, приемник. Грубо говоря, любой объект публикует события. ПриЗаписиНаСервере – это событие. ПриПроведении – это событие. ПриСозданииНаСервере – это событие.
  Кроме того, прикладной программист может привнести свои другие события и вызвать их в любой момент. И дальше, другой программист, из другой компании, из другого модуля в любой момент может подключиться к этим событиям и сказать, что на этих событиях должно что-то происходить.
  При этом, их код полностью изолирован, он связан между собой неким модулем, и публикаторы события ничего не знают про subscriber, они просто публикуют событие.

Ограничения в разработке форм

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

Чтобы подключить к документу какой-нибудь механизм БСП, нужно выполнить кучу действий, включая добавление кода в форму. В идеале, это не то, что мы хотим, потому что, если у нас 50 документов, в которые нужно добавить какой-то механизм, я хотел бы просто написать код:

Механизм.Добавить(«ИмяМеханизма», МассивИз50Документов)

Вместо этого я должен идти по этим 50 документам и добавлять в каждую форму свой код и свои обработчики.

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

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

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

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

Практические результаты

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

• У меня в профиле на GitHub есть 7 open-source модулей.

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

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

• Существует альфа-версия менеджера пакетов, в котором можно устанавливать эти модули «одной кнопкой».

• Есть сервер менеджера пакетов, сделанных на Node.js, это примитивный веб-сервер, который отдает JSON-файл и клиент – внешняя обработка.

Попробую показать все это на прикладной демонстрации.

Смотрите, у меня есть практически пустая конфигурация, в ней есть только:

• один документ «БазовыйДокумент»;

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

• и роль «ПолныеПрава».

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

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

Соответственно, я открыл БСП «Работа с файлами», посмотрел и закрыл – по нескольким причинам.

• Во-первых, БСП в очередной раз продемонстрировала отвратительную тенденцию –чтобы включить свой документ в список документов, поддерживаемых подсистемой «Файлы», я должен поменять код БСП и добавить свой документ в состав определяемых типов ВладелецФайлов и ВладелецФайловОбъект. И после этого я не могу обновить БСП одной кнопкой, потому что мне нужно делать сравнение/объединение.

• И еще там были некоторые сложности с расширениями.

В итоге я все это бросил и решил написать свой собственный модуль работы с файлами.

Итак, давайте добавим в документ формы «ФормаДокумента» и «ФормаСписка» – они нам дальше потребуются.

Теперь начинается магия. Мы идем в режим «1С:Предприятие» и открываем обработку «Менеджер пакетов». Ее можно взять в публикации на Инфостарте или в составе модуля A1-Instruments, который можно скачать с GitHub, этот модуль представляет собой расширение «А1И».

В нашей инфраструктуре, про которую я говорю, я называю себя А1, а буква «И» в префиксе расширения «А1И» означает, что это пакет с инструментами для программистов. В этом расширении у меня консоль запросов, консоль кода и все прочее – его можно накатить на каждую базу заказчика и никакого сравнения/объединения не нужно.

Открываем обработку «Менеджер пакетов» и видим, что в списке перечислены все модули, которые поддерживает наша инфраструктура на данный момент.

Нам потребуется модуль «А1Файлы». Этот модуль зависит от «А1Э» и «А1БК», и в идеале, при выборе одного модуля должны поставиться галочки на других модулях, которые для него требуются, но это пока не реализовано.

Поэтому я установлю галочки вручную – поставлю все, кроме модуля БСП – он модифицирует БСП так, как мне нравится. Я решил, что стандартное БСП недостаточно хорошо, и сделал его лучше.

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

Нажму кнопку «Установить отмеченные» и перезагружусь.

Обратите внимание, что после перезагрузки в интерфейсе появилась подсистема «Инструменты (А1)».

Теперь мы сделаем еще одну немного магическую вещь.

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

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

Это расширение мы загрузим вручную в конфигурацию из файлов XML, появившихся в этой папке.

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

Расширение загрузилось, обновим базу.

Давайте посмотрим, что у нас есть в этом расширении.

Расширение А1М (Механизмы) реализует подключение обработчиков во все модули объекта для всех документов. Например, видно, что в модуль объекта документа «БазовыйДокумент» у меня подключились все обработчики.

«Механизмы» – это и есть тот самый publisher-subscriber, про который я говорил. И сейчас мы его реализуем.

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

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

Модуль «А1СписокМеханизмов» должен экспортировать две функции.

• ДобавитьМеханизмы с параметром СписокМеханизмов;

• ДобавитьОбъекты с параметром СписокОбъектов.

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

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

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

• К этим объектам мы подключаем механизм расширения с файлами, поэтому третьим параметром пропишем название механизма – «А1Файлы».

Можно посмотреть, что в расширении с файлами тоже есть общий модуль «А1Файлы_А1СписокМеханизмов», где объявляется механизм «А1Файлы». Именно его мы и вызвали, чтобы подключить работу с файлами в документ «БазовыйДокумент».

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

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

Давайте посмотрим, что мы получили.

Обратите внимание, у нас для документа появилась кнопка «Файлы».

В ней есть кнопка «Добавить», которая открывает файл и добавляет его.

И есть кнопка «Показать список», которая открывает список файлов.

Всего этого мы добились одной строкой кода.

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

Вопросы

Чем такое решение с пакетным менеджером лучше обычного сравнения/объединения с конфигурациями по подсистемам?

Модули накатываются отдельно, они лежат отдельно. Есть четкая сепарация кода. Вам не нужно ничего сравнивать.

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

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

Вас смущает связанность и неизолированность подсистем БСП?

Меня смущает, что они все вместе скопом. Если я хочу обновить модуль «Файлы» в БСП, я не могу этого нормально сделать, потому что БСП поставляется целиком и полностью. Мне потребуется что-то там сравнивать, объединять, ломать голову.

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

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

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

Я готов рассматривать opm, но к нему нужно будет написать клиент.

И еще вопрос – opm имеет распределенное хранилище или локальное?

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

Я не рассматривал opm, потому что не думал, что могу хранить в opm расширения.

Да, мало кто думает, что opm имеет возможность работать с чем-то помимо OneScript.

И опять же – под opm нужно будет написать отдельный клиент.

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

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Путь к идеальному коду".