Механизм расширений в платформе «1С:Предприятие 8.3» — это мощный инструмент, который позволяет модифицировать типовые решения, не снимая их с поддержки. Однако при работе с крупными системами класса ERP или Управление торговлей разработчики часто сталкиваются с дилеммой: выносить ли все изменения в расширение или по старинке править основную конфигурацию. В этой статье мы проанализируем опыт практикующих специалистов, разберем технические риски и сформулируем оптимальный «гибридный» подход к разработке.
Рассмотрим ситуацию, когда перед командой стоит задача доработки сложной системы. Существует мнение, что расширение — это панацея, позволяющая сохранить «чистоту» типовой конфигурации для легкого обновления. На практике же мы сталкиваемся с тем, что выбор инструмента сильно зависит от архитектуры изменений. Проанализируем ключевой вывод экспертов: если ваша задача — создание тиражного решения для продажи многим заказчикам, то использование расширений для хранения метаданных оправдано. Если же вы ведете индивидуальный проект внедрения, логика меняется.
Разберем ситуацию на примере. Если в проекте требуется добавить новые реквизиты в типовые регистры сведений или планы видов характеристик, и эти реквизиты имеют ссылочный тип на новые справочники, использование расширения может стать источником проблем. В таких случаях целесообразно добавлять новые объекты и реквизиты в основную конфигурацию, а программную логику и интерфейсные формы выносить в расширение.
Посмотрим на техническую подоплеку работы расширений на уровне базы данных. Когда мы добавляем новые реквизиты через расширение, платформа 1С не меняет структуру основной таблицы в SQL. Вместо этого создаются дополнительные таблицы расширения. Проанализируем, к чему это приводит:
LEFT JOIN для объединения данных из основной таблицы и таблицы расширения. В высоконагруженных системах (например, при расчете себестоимости в ERP) это может существенно снизить производительность.Поэтому мы рекомендуем придерживаться правила: структурные изменения (новые справочники, документы, реквизиты) вносим в основную конфигурацию. Это гарантирует сохранность данных и прозрачность структуры таблиц для SQL-оптимизатора.
Выясним причину, по которой разработка крупных расширений в команде может быть затруднена. При использовании Хранилища конфигурации для расширения возникают специфические нюансы:
Разберем, почему расширения часто называют «хрупкими». Главный риск в крупных проектах — это использование аннотации &Вместо. Рассмотрим пример перехвата типового метода:
&Вместо("РассчитатьСуммуДокумента")
Процедура Моя_РассчитатьСуммуДокумента(Параметры)
// Наша доработка
ПродолжитьВызов(Параметры);
// Дополнительная логика
КонецПроцедуры
Проанализируем риски этого подхода. Если вендор (1С) в новом релизе изменит состав параметров типового метода или полностью перепишет его бизнес-логику, система может не выдать синтаксическую ошибку при обновлении. Однако логика работы приложения сломается, так как ваше расширение будет обращаться к устаревшим данным или перехватывать метод, который больше не используется в нужной цепочке вызовов.
Также стоит учитывать эффект «наслоения»: когда над одной базой работают несколько команд и каждая создает свое расширение, порядок их применения (приоритет) становится критически важным. Если два расширения меняют один и тот же метод через &Вместо, результат может быть непредсказуемым.
Посмотрим на объекты, которые до сих пор вызывают сложности при использовании в расширениях. Программисту важно помнить, что работа с такими объектами как Определяемые типы, Планы видов расчета и Бизнес-процессы в расширениях часто ограничена или требует дублирования сложной логики.
Кроме того, большое количество активных расширений (более 10-15 штук) заметно замедляет запуск клиентского приложения 1С. Это происходит потому, что платформе требуется время на компиляцию «сводных» форм и модулей из множества источников в оперативной памяти при каждом открытии тяжелой формы в ERP.
Проанализировав все «за» и «против», мы предлагаем использовать следующую стратегию при разработке на платформе 8.3:
&Перед и &После. Старайтесь избегать &Вместо без крайней необходимости.Документ.ЗаказКлиента или РегистрНакопления.ВыручкаИСебестоимостьПродаж — делайте это в основной конфигурации.Таким образом, расширение — это не способ «уйти от ответственности» за изменение типовой конфигурации, а инструмент для разделения ответственности между кодом вендора и вашими доработками. Грамотное сочетание обоих механизмов позволит вам создать стабильную и легко обновляемую систему.