Как организовать использование общего кода в нескольких расширениях 1С?

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

Способ 1: Создание общего расширения-библиотеки

Наиболее логичным и структурированным решением является создание отдельного расширения (назовем его ОбщаяБиблиотека), в котором будут сосредоточены все универсальные методы. Рассмотрим, как это работает на практике.

Вопреки распространенному мнению, расширения могут «видеть» друг друга. Если в Расширении1 есть общий модуль ОбщийМодульСервер с экспортным методом, вы можете вызвать его из Расширения2 напрямую:

// Код в Расширении2
ОбщийМодульСервер.ИмяНужнойФункции();

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

Способ 2: Настройка зависимостей между расширениями

Проанализируем встроенный механизм платформы 1С для связи расширений. В свойствах каждого расширения существует список «Требуемые расширения». Разберем по шагам, как настроить среду разработки:

1. Откроем свойства Расширения1 (потребителя кода).
2. Найдем пункт «Используемые расширения» или «Требуемые расширения» (в зависимости от версии платформы).
3. Добавим туда ОбщуюБиблиотеку.

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

Способ 3: Учет типов назначений расширений

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

• Исправление (Patch): самый высокий приоритет.
• Адаптация (Adaptation): средний приоритет.
• Дополнение (Supplement): самый низкий приоритет.

Проанализируем правило видимости: расширение с «более высоким» назначением не видит методы из «более низкого». Например, если ваша библиотека имеет тип Дополнение, а основное расширение — Адаптация, вызов завершится ошибкой. Рекомендуем устанавливать для всех связанных расширений одинаковый тип назначения (например, Адаптация), чтобы обеспечить беспрепятственный доступ к общим модулям.

Способ 4: Добавление общего модуля в основную конфигурацию

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

1. Включим возможность изменения в основной конфигурации, но не снимаем с поддержки ни один типовой объект.
2. Создадим новый объект ОбщийМодуль с уникальным префиксом, например _итОбщиеМетоды.
3. Поместим туда весь «золотой фонд» своих функций.

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

Работа с динамическими вызовами

Иногда возникают ситуации, когда жесткая зависимость нежелательна (например, если Расширение1 может работать как с Расширением2, так и без него). В этом случае проанализируем использование функции Вычислить() или Выполнить(). Посмотрим на пример безопасного вызова:

Попытка
    Результат = Вычислить("МойОбщийМодульИзДругогоРасширения.ВыполнитьДействие()");
Исключение
    // Обработка ситуации, когда расширение не подключено
    Результат = Неопределено;
КонецПопытки;

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

Архитектурные риски и рекомендации

Разберем ситуацию, когда количество расширений растет (в практике встречаются случаи с 20-30 расширениями). Это порождает «ад поддержки»:

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

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

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