Как правильно организовать свою библиотеку функций в 1С

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Почему стоит отказаться от глобальных модулей

Рассмотрим популярную идею: сделать все модули библиотеки «Глобальными», чтобы вызывать функции напрямую, не указывая имя модуля. На первый взгляд это кажется удобным, но давайте проанализируем последствия такого решения:

  1. Засорение контекста: При наборе кода в конфигураторе выпадающий список подсказок (IntelliSense) будет перегружен сотнями функций. Это значительно замедляет работу программиста, заставляя его искать нужную функцию среди множества похожих имен.
  2. Конфликты имен: Если вы назовете свою глобальную функцию СтрЗаменить() или ОткрытьФорму(), вы создадите конфликт с платформенными методами или функциями других библиотек. Вероятность совпадения имен в глобальном контексте чрезвычайно высока.
  3. Снижение читаемости кода: Проанализируем ситуацию: вы читаете чужой код и видите вызов ПреобразоватьДату(). Откуда взялась эта функция? Из вашей библиотеки? Из общего модуля конфигурации? Из глобального модуля БСП? Если бы вызов выглядел как бфОбщегоНазначения.ПреобразоватьДату(), источник был бы очевиден сразу. Код нужно читать как книгу, и любая задержка на поиск «откуда растут ноги» — это потеря эффективности.
  4. Производительность: Глобальные модули компилируются при старте сеанса. Чем больше в них кода, тем дольше пользователь будет ждать открытия программы.

Вывод: Откажитесь от флага «Глобальный». Использование явного обращения через имя модуля — это стандарт чистого и понятного кода.

Архитектурный паттерн «Фасад» или интерфейсный модуль

Разберем наиболее эффективный способ организации доступа к функциям. Вместо того чтобы заставлять пользователя помнить десятки названий модулей (бфСтроки, бфКоллекции, бфРаботаСФайлами), мы можем создать единый «интерфейсный» модуль.

Как это работает по шагам:

  1. Создаем основной модуль с коротким и понятным именем, например, бф (или более длинным БиблиотекаУниверсальныхМетодов).
  2. Внутри этого модуля создаем экспортные функции, которые просто перенаправляют вызов в специализированные модули.
  3. Специализированные модули (например, бф_СтрокиСервер) делаем неэкспортными или договариваемся не обращаться к ним напрямую.

Пример реализации интерфейсного модуля:


// Модуль бф
Функция ТекстТабличногоДокумента(ТабДок) Экспорт
    Возврат бф_ТабличныеДокументыСервер.ТекстТабличногоДокумента(ТабДок);
КонецФункции

Процедура ПрисвоитьБезопасно(Объект, ИмяСвойства, Значение) Экспорт
    бф_ЯзыкСервер.ПрисвоитьБезопасно(Объект, ИмяСвойства, Значение);
КонецПроцедуры

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

Правила именования и префиксы

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

Что касается названий самих функций, рассмотрим два подхода:

Проанализировав практику, можно сказать: если вы используете интерфейсный модуль бф, то лучше называть функции «от действия», так как контекст объекта уже понятен из параметров или названия модуля. Однако названия методов должны быть «залиты бетоном». Если вы выпустили версию библиотеки, менять название функции или порядок её параметров в будущем нельзя — это сломает код у всех пользователей вашей библиотеки.

Настройка контекста исполнения (Клиент, Сервер, Вызов сервера)

Разберем типичную ошибку при настройке свойств общих модулей. Часто разработчики ставят галочки «Клиент», «Сервер» и «Вызов сервера» одновременно. Посмотрим, почему это не совсем правильно:

  1. Если модуль имеет флаги «Клиент» и «Сервер», он будет скомпилирован в обоих контекстах. Это удобно для «чистых» функций (математика, логика), которые не обращаются к базе данных или специфичным объектам (например, формам).
  2. Флаг «Вызов сервера» нужен только тогда, когда вы хотите вызвать процедуру на сервере с клиента. Если у вас уже стоит флаг «Сервер», этот модуль и так доступен серверному коду.
  3. Важный момент: если ваша библиотека предназначена для программистов, разделяйте логику. Создайте модули бфКлиент и бфСервер. Это предотвратит попытки вызвать серверный код (например, запрос к БД) там, где это невозможно (на тонком клиенте без вызова сервера).

Современные инструменты: Расширения и Git

Чтобы ваша библиотека была по-настоящему профессиональной, рассмотрим современные способы её распространения:

Использование расширений (.cfe)

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

Система контроля версий и тесты

Если вы планируете развивать библиотеку, использование Git обязательно. Это позволит отслеживать историю изменений и возвращаться к стабильным версиям. Кроме того, критически важно покрыть функции Unit-тестами (например, используя xUnitFor1C или Vanessa-ADD). Библиотека без тестов — это «черный ящик», который может сломаться в самый неподходящий момент при добавлении новой функции.

Итоги: чеклист идеальной библиотеки

Подведем итог нашему анализу. Чтобы создать качественную библиотеку функций, следуйте этим правилам:

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

← На главную