При длительном сопровождении программных продуктов 1С перед разработчиком неизбежно встает выбор: вносить доработки непосредственно в типовую конфигурацию, сняв ее с поддержки полностью или частично, либо выносить всю индивидуальную логику в расширения конфигурации. Рассмотрим особенности работы обоих подходов, проанализируем поведение заимствованных объектов при обновлении типовых релизов от поставщика и сформируем оптимальную стратегию сопровождения.
Разберем одну из главных причин популярности расширений — работу с графическим интерфейсом и управляемыми формами. В классическом механизме поставки (при изменении формы в снятой с замка конфигурации) каждое обновление требует трехстороннего сравнения и ручного поиска элементов, чтобы случайно не затереть новшества от разработчика 1С.
В случае с расширениями платформа работает по принципу слияния интерфейса:
Важное ограничение: если вы планируете вносить несколько интерфейсных правок в одну и ту же форму (например, добавлять новые кнопки и поля), настоятельно рекомендуется объединять их в рамках одного расширения. Если одну форму заимствуют разные расширения для изменения интерфейса, при сеансе применится только одно из них.
Выясним, как ведет себя программный код при использовании расширений и какие риски несет подмена типовых процедур.
Для перехвата и изменения логики процедур и функций в модулях используются специальные директивы:
&Перед — выполняется перед вызовом основного метода типовой конфигурации.&После — выполняется сразу после вызова стандартного метода.&Вместо — полностью замещает стандартную процедуру или функцию типовой конфигурации.При использовании директив &Перед и &После обновление конфигурации поставщика проходит максимально гладко: код расширения просто отрабатывает до или после обновленного модуля типовой конфигурации.
Однако с директивой &Вместо возникают критические риски. Так как типовая процедура полностью перекрывается вашим кодом, любые исправления багов, изменение бизнес-логики или формата расчетов, сделанные 1С в новом релизе, просто не будут выполнены. При этом система не выдаст синтаксической ошибки, и проблема проявится лишь в процессе эксплуатации (например, при закрытии месяца или формировании отчетности).
Для предотвращения подобных "тихих" ошибок в современных версиях платформы вместо директивы &Вместо применяется аннотация #ИзменениеИКонтроль:
&Вместо("РассчитатьСпецификацию")
Процедура Расширение_РассчитатьСпецификацию(Параметры)
#Раздел1
// %ИсходныйКод%
#Удаление
// Типовой код округления
Значение = Округлить(Значение, 2);
#КонецУдаления
#Вставка
// Пользовательский перерасчет с нецелым коэффициентом
Значение = Округлить(Значение * Коэффициент, 4);
#КонецВставки
#КонецРаздела
КонецПроцедуры
Благодаря тегам #Удаление и #Вставка платформа при обновлении проверяет, изменялся ли фрагмент %ИсходныйКод% поставщиком. Если 1С внесла изменения в дорабатываемый кусок кода, расширение заблокирует запуск базы и проинформирует о необходимости актуализировать доработку.
Чтобы избежать сбоев при обновлении конфигураций в рабочей среде, рекомендуется выполнять предварительную проверку возможности применения расширений. Проверить корректность подключения расширения можно как встроенными средствами Конфигуратора, так и программно.
Проанализируем пример программной проверки применимости всех подключенных расширений в коде 1С:
МассивОшибок = Новый Массив;
Если Не РасширенияКонфигурации.ПроверитьВозможностьПримененияВсех(МассивОшибок) Тогда
Для Каждого Ошибка Из МассивОшибок Цикл
ЗаписатьОшибкуВЖурналРегистрации(Ошибка.Описание);
КонецЦикла;
КонецЕсли;
Метод РасширенияКонфигурации.ПроверитьВозможностьПримененияВсех() позволяет проверить сигнатуры методов и наличие метаданных до выполнения критичных бизнес-операций.
Чтобы полностью исключить конфликты при обновлении графических форм поставщика, специалисты часто используют программное создание элементов. Вместо того чтобы заимствовать форму целиком в Конфигураторе и редактировать ее визуально, элементы добавляются кодом в обработчике ПриСозданииНаСервере.
Рассмотрим пример добавления поля и кнопки на форму через расширение модуля формы:
&После("ПриСозданииНаСервере")
Процедура Расширение_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Добавление нового реквизита формы
МассивДобавляемыхРеквизитов = Новый Массив;
МассивДобавляемыхРеквизитов.Добавить(Новый РеквизитФормы("ДопКоэффициент", Новый ОписаниеТипов("Число")));
ИзменитьРеквизиты(МассивДобавляемыхРеквизитов);
// Добавление элемента управления на форму
ЭлементКоэффициент = Элементы.Добавить("ПолеДопКоэффициент", Тип("ПолеФормыВвод"), Элементы.ГруппаШапка);
ЭлементКоэффициент.ПутьКДанным = "ДопКоэффициент";
ЭлементКоэффициент.Вид = ВидПоляФормы.ПолеВвода;
КонецПроцедуры
Такой подход гарантирует, что даже при кардинальном изменении состава реквизитов поставщиком ваша форма не потеряет работоспособность и успешно примет обновления.
Проанализируем плюсы и минусы использования обоих механизмов при длительном сопровождении:
&После или #ИзменениеИКонтроль, правку логики надежнее выполнять в основной конфигурации со снятием конкретного объекта с замка.Итоговый вывод: наилучшие результаты показывает гибридный подход. Дополнительные отчеты, обработки, добавление новых реквизитов, справочников и интерфейсные изменения форм выносятся в расширения. Критичная бизнес-логика со сложным трехсторонним слиянием при отсутствии аналогов сохраняется в основной конфигурации на поддержке с возможностью изменения.