Механизм расширений конфигурации в платформе «1С:Предприятие 8.3» призван упростить адаптацию прикладных решений и сохранить типовую конфигурацию на поддержке поставщика («на замке»). Однако на практике перевод доработок с модифицированной основной конфигурации на расширения имеет как ощутимые плюсы, так и серьезные подводные камни. Разберем по шагам, в каких случаях использование расширений оправдано, с какими трудностями сталкивается разработчик при обновлениях и как правильно организовать архитектуру доработок.
Преимущества использования расширений конфигурации
Рассмотрим ключевые достоинства, которые делают механизм расширений привлекательным инструментом для адаптации решений:
Сохранение поддержки и простота обновления основной базы: Основная конфигурация остается полностью на замке. Это позволяет накатывать обновления типовых релизов из файлов CFU в штатном автоматическом режиме без сложного сравнения и объединения модулей основной конфигурации.
Замена внешних печатных форм, отчетов и обработок: Начиная с Библиотеки Стандартных Подсистем (БСП) версии 2.3.5 и выше, расширения эффективно заменяют механизм дополнительных отчетов и обработок. Добавленные в расширение объекты получают собственный модуль менеджера (что позволяет писать печатные формы стандартным образом), полноценно отлаживаются в конфигураторе, интегрируются в интерфейсные подсистемы и поддерживают назначение ролей и прав доступа.
Небольшие косметические доработки интерфейса: Расширения идеально подходят для вывода дополнительных реквизитов на форму, скрытия ненужных элементов, добавления командных кнопок или изменения видимости полей.
Оперативное исправление ошибок (патчи): С помощью расширений с назначением «Исправление» можно быстро вносить исправления в работу системы до выхода официального обновления от поставщика, не снимая базу с поддержки.
Недостатки, ограничения и риски применения расширений
Проанализируем проблемы и узкие места, с которыми приходится сталкиваться при эксплуатации и разработке расширений:
Сложность контроля изменений при обновлении поставщика: При обновлении типовой конфигурации отсутствует полноценный инструмент трехстороннего сравнения и объединения основного модуля поставщика, старой версии и расширения. Если поставщик изменит код перехватываемого метода, расширение может молча прийти в негодность или выдать ошибку во время исполнения (в рантайме).
Ограничения групповой разработки: Механизм расширений не поддерживается стандартным Хранилищем конфигурации 1С. Для версионирования и коллективной работы приходится привлекать внешние инструменты, такие как EDT и Git.
Опасность полного перекрытия методов через директиву &Вместо: Полная замена кода процедур типовой конфигурации создаёт высокий риск потери критической логики при обновлениях. При использовании нескольких расширений отсутствие вызова ПродолжитьВызов() блокирует работу последующих расширений в цепочке.
Особенности работы с данными: При добавлении собственных реквизитов и объектов в расширении создаются реальные таблицы в базе данных. В случае случайного удаления или отключения расширения все накопленные в этих объектах данные удаляются из СУБД без возможности автовосстановления.
Необходимость обязательного тестирования: После каждого обновления основной конфигурации необходимо проводить полное ручное или автоматическое тестирование доработанного функционала.
Правила использования директив модификации кода
Выясним, как правильно перехватывать процедуры и функции основной конфигурации, чтобы минимизировать риски при обновлении платформы и конфигурации.
В зависимости от задачи используются следующие аннотации:
&Перед — выполняет код расширения до вызова основного метода. Подходит, когда требуется подготовить данные или выполнить проверки.
&После — выполняет код расширения после завершения работы основного метода. Идеально для дополнительной обработки результатов или логирования.
&Вместо — полностью заменяет исполнение основного метода. Требует обязательного вызова метода ПродолжитьВызов(), чтобы не сломать стандартную логику и цепочки вызовов других расширений.
&ИзменениеИКонтроль — наиболее безопасный метод для точечной модификации кода. Позволяет указать удаляемые и вставляемые фрагменты с помощью специальных конструкций.
Посмотрим на пример применения директивы &ИзменениеИКонтроль для изменения фрагмента кода типовой процедуры:
&ИзменениеИКонтроль(ЗаполнитьДанныеДокумента)
Процедура Расш1_ЗаполнитьДанныеДокумента(ДокументСсылка)
// Типовой код до изменений
#Удаление
Сумма = ДокументСсылка.СуммаДокумента;
#КонецУдаления
#Вставка
Сумма = ДокументСсылка.СуммаДокумента * КоэффициентПересчета;
#КонецВставки
КонецПроцедуры
Если в новом релизе поставщика исходная строка в процедуре ЗаполнитьДанныеДокумента изменится, платформа 1С при применении расширения сразу оповестит разработчика о нежизнеспособности аннотации &ИзменениеИКонтроль, предотвращая скрытые ошибки в работе пользователей.
Практические рекомендации по разработке и поддержке расширений
Разберем по шагам правила, которые помогут эффективно использовать расширения в реальных проектах:
Не перегружайте расширение лишними метаданными: При заимствовании объектов конфигурации в расширение часто попадают смежные и неиспользуемые типы данных. Обязательно удаляйте из метаданных расширения все заимствованные объекты, которые не модифицируются и на которые не ругается проверка синтаксиса. Это уменьшит объем расширения и снизит вероятность конфликтов.
Соблюдайте предназначение расширений: Используйте свойство расширения «Назначение» (Исправление, Адаптация, Дополнение). Это обеспечивает правильную очередность их подключения и исполнения платформой.
Следите за безопасным режимом: Если коду расширения требуется доступ к файловой системе, внешним компонентам или COM-объектам, необходимо настроить профили безопасности или корректно отключить безопасный режим в административной панели.
Крупные доработки выносите в отдельную архитектуру: Если объем модификаций затрагивает десятки взаимосвязанных форм и логику проведения документов, внедрение расширения может оказаться трудоемким. В таких случаях разумнее выносить сложную бизнес-логику в отдельные независимые подсистемы или подписки на события, либо использовать комбинацию из внешних обработок БСП и точечных расширений.
Подводя итог, можно сделать вывод: переводить доработки на расширения однозначно стоит для задач малой и средней сложности (интерфейсные правки, печатные формы, новые отчеты и локальные патчи). Это позволяет сохранить базовую конфигурацию на замке и существенно упростить процесс базового обновления 1С.