Разработка и тестирование расширений в среде 1С:Предприятие часто сопряжены с определенными рисками, особенно если изменения вносятся в рабочую информационную базу, где одновременно трудятся десятки или сотни сотрудников. Типовой механизм расширений подразумевает, что после подключения и применения изменений функционал становится доступен всем пользователям системы сразу. Однако в процессе отладки нам часто требуется, чтобы «подмена» стандартных функций или новые элементы интерфейса были видны и активны только для разработчика или тестировщика.
В этой статье мы подробно разберем, как реализовать выборочную работу расширения, проанализируем различные подходы — от простых условий в коде до профессиональных инструментов разработки, и выясним, какой метод наиболее эффективен в разных ситуациях.
Рассмотрим самый очевидный и быстрый в реализации способ. Если нам необходимо перехватить выполнение процедуры или функции с помощью аннотации &Вместо, мы можем внедрить проверку текущего пользователя непосредственно в тело метода расширения. Это позволит управлять логикой выполнения: если зашел «нужный» пользователь — выполняется наш новый код, если любой другой — система продолжает работать по стандартному алгоритму.
Проанализируем пример кода, который реализует такую проверку:
&Вместо("РассчитатьСкидку")
Процедура Расш1_РассчитатьСкидку(Параметры)
// Проверяем, является ли текущий пользователь тестировщиком
Если ПользователиИнформационнойБазы.ТекущийПользователь().Имя = "Администратор_Тест" Тогда
// Выполняем нашу новую логику, которую нужно проверить
Сообщить("Работает тестовый алгоритм расчета скидок!");
// Ваш код здесь...
Иначе
// Для всех остальных пользователей вызываем стандартный метод
ПродолжитьВызов(Параметры);
КонецЕсли;
КонецПроцедуры
Этот метод хорош тем, что он дает 100% гарантию изоляции функционала. Однако у него есть существенный минус, который отметили участники обсуждения: если в расширении десятки измененных функций, прописывать такое условие в каждой из них крайне неудобно. Кроме того, постоянное обращение к функции ПользователиИнформационнойБазы.ТекущийПользователь() может создавать избыточную нагрузку на сервер 1С.
Чтобы избежать дублирования кода и повысить производительность, мы можем использовать параметры сеанса. Идея заключается в том, чтобы один раз при старте системы определить, должен ли для данного сеанса работать функционал расширения, и сохранить этот «флаг» в памяти.
Разберем по шагам, как это реализовать:
РежимОтладкиРасширения (тип: Булево).Посмотрим, как упрощается код в этом случае:
&Вместо("ВажнаяБизнесЛогика")
Функция Расш1_ВажнаяБизнесЛогика()
// Вместо сложных проверок проверяем быстрый параметр сеанса
Если ПараметрыСеанса.РежимОтладкиРасширения Тогда
// Новая логика
Возврат РезультатНовогоАлгоритма();
КонецЕсли;
// Стандартная логика
Возврат ПродолжитьВызов();
КонецФункции
Для еще большей централизации мы рекомендуем вынести проверку в общий модуль расширения. Например, создать функцию Расш1_Общий.ЭтоМойСеанс(), которая будет возвращать истину только для нужных условий (имя пользователя, роль или наличие определенного файла на диске разработчика). Тогда в каждой функции расширения достаточно будет добавить одну короткую строку в начале.
Если расширение добавляет новые кнопки, команды или поля на формы, программной проверки в коде будет недостаточно — пользователи всё равно увидят новые элементы (хотя они и не будут работать). Для решения этой задачи мы можем использовать Функциональные опции.
Выясним, как это работает: мы создаем константу или используем параметр сеанса в качестве источника для функциональной опции. Затем привязываем новые объекты расширения к этой опции. Таким образом, для всех пользователей, у которых опция выключена, интерфейс останется в типовом виде, и расширение будет визуально «невидимым».
Как справедливо заметили участники форума, работа в «живой» базе — это крайняя мера. Правильный цикл разработки (Dev-Ops в мире 1С) подразумевает использование тестовых контуров. Рассмотрим основные подходы:
В ходе дискуссии возникал вопрос: можно ли спровоцировать ошибку при подключении расширения для определенных пользователей? Теоретически, можно написать код в модуле расширения, который вызывает Исключение, но это плохая практика. Платформа 1С при ошибке подключения расширения может выдать модальное окно всем пользователям или заблокировать запуск системы. Кроме того, расширение либо загружается в конфигурацию целиком для всех, либо не загружается вовсе. Механизма «индивидуальной загрузки расширения в память» для конкретного сеанса (кроме инструментов отладки EDT) в платформе не предусмотрено.
Подводя итоги, выделим наиболее эффективную стратегию для управления активностью расширения:
ИмяПользователя() в начале функций с вызовом ПродолжитьВызов() в ветке Иначе.Помните, что расширение — это мощный инструмент, который глубоко интегрируется в логику системы, и безопасность данных пользователей должна быть приоритетом при любых экспериментах с кодом.