Механизм расширения конфигурации в платформе 1С:Предприятие 8.3 задумывался как революционный шаг, позволяющий дорабатывать типовые решения без снятия их с поддержки. Однако среди разработчиков до сих пор не утихают споры: можно ли использовать расширения как основной и единственный инструмент ведения проекта, или же они пригодны только для точечных «патчей» и временных исправлений? В рамках этой статьи мы детально разберем практический опыт разработчиков, проанализируем основные технические проблемы, с которыми можно столкнуться при масштабном использовании расширений, и выясним, как эти ограничения эволюционировали в новых версиях платформы.
Рассматривая архитектуру доработок, каждый архитектор или ведущий разработчик 1С сталкивается с дилеммой. С одной стороны, сохранение базы на полной поддержке гарантирует простое и быстрое обновление. С другой стороны, разработка крупного функционала внутри расширений часто наталкивается на жесткие платформенные ограничения. В реальности успешность внедрения этого подхода напрямую зависит от используемой конфигурации, масштабности доработок и версии используемой платформы 1С.
Проанализируем ключевые технические проблемы, которые долгие годы заставляли разработчиков отказываться от расширений в пользу классического изменения основной конфигурации, и рассмотрим эффективные способы их решения.
Одной из главных проблем, озвученных разработчиками на практике, является добавление новых реквизитов к заимствованным объектам (например, добавление реквизита Партнер в справочник Контрагенты). На более ранних версиях платформы (периода 8.3.12–8.3.14) это приводило к критическим ошибкам работы базы данных.
Выясним причину: при проведении процедуры тестирования и исправления (ТиИ) с проверкой логической целостности платформа могла «не увидеть» новые реквизиты в расширении и физически удалить подчиненные данные или очистить ссылки. Это вызывало обоснованный страх у администраторов и разработчиков.
Как решать эту проблему на практике:
РегистрСведений, где ключевым измерением будет ссылка на объект, а ресурсом — наше новое свойство. Это полностью исключает риск повреждения структуры таблиц основной конфигурации.
Функция ПолучитьДополнительноеСвойство(СсылкаНаОбъект) Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| СвойстваОбъектов.ЗначениеСвойства КАК ЗначениеСвойства
|ИЗ
| РегистрСведений.СвойстваОбъектов КАК СвойстваОбъектов
|ГДЕ
| СвойстваОбъектов.Объект = &Объект";
Запрос.УстановитьПараметр("Объект", СсылкаНаОбъект);
Результат = Запрос.Выполнить();
Если Не Результат.Пустой() Тогда
Выборка = Результат.Выбрать();
Выборка.Следующий();
Возврат Выборка.ЗначениеСвойства;
КонецЕсли;
Возврат Неопределено;
КонецФункции
Эволюция платформы: В современных версиях платформы (начиная с 8.3.15 и выше) работа с реквизитами в расширениях была кардинально переработана и стабилизирована. В платформе 8.3.24 также появилась фоновая реструктуризация таблиц расширений, что делает этот процесс безопасным и исключает «порчу данных» при обслуживании базы.
Рассмотрим ситуацию: вы создали в расширении новый документ и хотите подключить его к типовому отчету «Структура подчиненности» или связать с бизнес-логикой дополнительных реквизитов БСП. Для этого необходимо добавить ваш новый документ в состав ОпределяемыеТипы (например, в тип ДокументОбъект или ОбъектСДополнительнымиРеквизитами).
В старых версиях платформы это вызывало тупик: состав определяемого типа в расширении должен был строго совпадать с основной конфигурацией. Изменить определяемый тип в расширении было невозможно, а менять его в основной базе — значит снимать её с поддержки, что перечеркивает всю пользу расширения.
Как решалась эта проблема: Разработчикам приходилось обходить это ограничение программно, внедряя «костыли», переписывая логику формирования структуры подчиненности или создавая дублирующие отчеты специально под нетиповые документы.
Современное решение платформы: Начиная с версии 8.3.20, фирма «1С» полностью сняла это ограничение. Теперь в расширениях поддерживается полноценное изменение ОпределяемыеТипы, планов видов характеристик и общих реквизитов. Вы можете заимствовать определяемый тип и свободно расширять его состав объектами, созданными непосредственно в расширении.
Еще одно частое препятствие при разработке масштабных проектов — невозможность использовать ПодпискиНаСобытия для объектов из расширений или создавать новые подписки, если основная конфигурация находится «на замке».
Как обойти это ограничение на практике:
Проанализируем обходной путь, который успешно используется программистами: мы можем заимствовать общий модуль, который вызывается в существующих подписках основной конфигурации, и перехватить исполнение там. Также в большинстве типовых конфигураций (например, в ERP, КА или БП) существуют специальные модули интеграции и локализации (с суффиксом *Локализация или аналогичные), которые предназначены для внедрения нетиповых алгоритмов.
Если мы создаем полностью свой объект внутри расширения, то вместо механизма подписок на события нам следует использовать стандартные предопределенные процедуры модуля самого объекта (такие как ПередЗаписью, ПриЗаписи или ОбработкаПроведения).
Современное решение платформы: Начиная с версии платформы 8.3.17, ограничение было снято. Теперь разработчик имеет возможность создавать собственные ПодпискиНаСобытия внутри расширений для любых типов объектов, включая заимствованные и созданные с нуля.
Если мы все же приняли решение делать проект на расширениях, перед нами встает важный архитектурный выбор: использовать одно монолитное расширение для всех доработок или делить систему на несколько независимых модулей?
Разберем плюсы и минусы обоих подходов:
1. Одно монолитное расширение (Монопроект):
2. Несколько отдельных расширений (Модульный подход):
Как правильно организовать модульную структуру:
Платформа 1С позволяет управлять профилями и очередностью применения расширений с помощью назначения (Исправление, Адаптация, Дополнение). Для связывания нескольких модулей необходимо использовать свойства зависимостей в свойствах расширения, когда одно расширение явно указывает, что оно зависит от метаданных другого. При этом критически важно помнить правило: избегайте одновременного изменения форм одного и того же типового документа в разных расширениях, так как платформа применит только одно из изменений интерфейса.
Подводя итог, можно уверенно сказать: разработка проектов на расширениях в экосистеме 1С прошла путь от экспериментального и рискованного инструмента до стабильного индустриального стандарта.
Если вы ведете разработку на современных версиях платформы (8.3.20 и выше) и работаете с типовыми конфигурациями средней сложности (такими как 1С:Бухгалтерия, 1С:Зарплата и Управление Персоналом, 1С:Управление нашей фирмой), использование расширений как основного инструмента разработки полностью оправдано и несет огромные выгоды при последующих обновлениях.
В то же время, при внедрении масштабных систем класса 1С:ERP или сильно кастомизированных конфигураций с огромным объемом данных, рекомендуется применять гибридный подход: тяжелые новые объекты (справочники, документы) создавать непосредственно в основной конфигурации, а логику их проведения, интеграционные механизмы и кастомизацию интерфейсов выносить в расширения.