Разработка с использованием расширений конфигурации в платформе 1С:Предприятие 8.3 стала стандартом де-факто. Всё чаще от заказчиков и архитекторов звучит жесткое требование: «Основную конфигурацию не снимать с поддержки, все доработки делать только через расширения». Но когда объем доработок растет, перед разработчиком встает серьезная дилемма: упаковать весь измененный функционал в одно огромное расширение или разделять задачи по отдельным небольшим расширениям? Рассмотрим этот вопрос детально, проанализируем технические нюансы платформы и выработаем оптимальную стратегию.
Подход с использованием одного монолитного расширения предполагает, что абсолютно все доработки (новые справочники, измененные формы, перехваченные процедуры проведения документов) помещаются в один контейнер.
Преимущества монолитного расширения:
СоглашенияСКлиентамиДополнительный, и нам требуется обратиться к нему из формы документа, дорабатываемой в расширении, в рамках одного контейнера это происходит бесшовно. Все объекты «видят» друг друга без настройки сложных связей..cfe.Недостатки монолитного расширения:
Альтернативный подход предлагает создавать под каждую отдельную задачу, патч или печатную форму свое собственное изолированное расширение.
Преимущества модульного подхода:
Критические недостатки и технические ограничения множества расширений:
Прежде чем создавать десятки мелких расширений, необходимо детально проанализировать ограничения платформы 1С. Очень часто разработчики сталкиваются со следующими проблемами:
&ИзменениеИКонтроль. Платформа не позволяет изменять один и тот же метод основной конфигурации этой аннотацией в разных расширениях. Если расширение «А» и расширение «Б» попытаются перехватить процедуру ПередЗаписью документа РеализацияТоваровУслуг через &ИзменениеИКонтроль, система выдаст ошибку при применении расширений.&Вместо. Если несколько расширений перехватывают один метод через &Вместо, отработает только то расширение, которое применилось последним в цепочке. Предыдущие перехваты будут проигнорированы, если разработчик не позаботился о вызове метода ПродолжитьВызов(). Это усложняет отладку и логику работы системы.Как же поступить правильно? Опытные разработчики и архитекторы систем уровня 1С:ERP рекомендуют использовать гибридную схему группировки доработок.
Выделим три основных уровня деления расширений по их функциональному назначению согласно стандартам «1С»:
1. Уровень исправлений (Патчи)
Для оперативного исправления багов типовой конфигурации создаются точечные мелкие расширения с назначением «Исправление» (Patch). Их жизненный цикл короток: они устанавливаются для быстрого решения проблемы «здесь и сейчас» и безжалостно удаляются, как только вендор выпускает официальный релиз с исправлением этой ошибки.
2. Уровень адаптации и доработки бизнес-логики
Для изменения существующего функционала создаются расширения с назначением «Адаптация» (Adaptation). На этом уровне крайне важно соблюдать баланс:
ЗаказПокупателя и его формы), эти задачи обязательно должны находиться внутри одного расширения. В противном случае вы гарантированно получите конфликты при обновлении и непредсказуемое поведение интерфейса.Наш_ИнтеграцияWMS (все объекты, процедуры и API, связанные со складом);Наш_КазначействоДоработки (изменения в цепочке согласования заявок на расходование средств);Наш_Логистика (доработки маршрутных листов и доставки).3. Уровень дополнений и новых подсистем
Для внедрения абсолютно новых блоков, не связанных с типовым кодом (новые справочники, несвязанные документы, собственные АРМ), создаются расширения с назначением «Дополнение» (Supplement). Их можно делать независимыми, так как они не пересекаются с типовыми модулями и работают изолированно.
В современных конфигурациях на базе БСП (Библиотеки Стандартных Подсистем) разработчики отказываются от старого механизма внешних обработок и печатных форм в пользу расширений. Это повышает надежность системы и упрощает администрирование.
Разберем пример создания команды печати в расширении. Чтобы зарегистрировать новую печатную форму в подсистеме БСП, нам больше не нужно создавать внешние обработки. Мы добавляем команду печати напрямую в расширение и связываем ее с БСП.
Посмотрим на пример регистрации команды печати в модуле управления печатью расширения:
// В модуле менеджера объекта (например, документа РеализацияТоваровУслуг) в расширении
// Перехватываем процедуру добавления команд печати
&Вместо("ДобавитьКомандыПечати")
Процедура Наш_ДобавитьКомандыПечати(КомандыПечати) Экспорт
// Сначала вызываем типовой обработчик, чтобы не затереть стандартные печатные формы
ПродолжитьВызов(КомандыПечати);
// Добавляем свою новую команду печати
КомандаПечать = КомандыПечати.Добавить();
КомандаПечать.Идентификатор = "Наш_НакладнаяСЛоготипом";
КомандаПечать.Представление = НСтр("ru = 'Накладная с логотипом (доработка)'");
КомандаПечать.ПроверкаПроведенияПередПечатью = Истина;
КомандаПечать.Порядок = 1;
КонецПроцедуры
Такой подход позволяет хранить печатные формы непосредственно в коде расширения подсистемы, избегая деградации производительности, свойственной внешним обработкам при безопасном режиме работы.
Проанализируем практический опыт крупных проектов автоматизации и сформулируем правила работы с расширениями, которые помогут избежать хаоса:
Наш_, ИП_, СКТ_). Это предотвратит коллизии имен, если в следующем обновлении типовой конфигурации от фирмы «1С» появится объект с таким же именем.Таким образом, золотое правило разработки гласит: компромисс и структурирование. Не сваливайте абсолютно все задачи в одну кучу и не плодите сотни мелких расширений под каждый чих. Группируйте доработки по крупным бизнес-подсистемам, изолируйте патчи ошибок и помните о технических ограничениях платформы 1С.