Подходы использования расширений в проектном внедрении

Расширение конфигурации — инструмент, позволяющий выполнять адаптацию основной конфигурации, если необходимо оставить основную конфигурацию на поддержке.

К 2024 году расширения получили широкий спектр возможностей по адаптации типовых конфигураций. Расширения решают 99% задач заказчиков на доработку системы, что позволяет:

• сэкономить время на последующих обновлениях; 
• ускорить разработку и отладку доработок — объем расширения намного меньше объема основной конфигурации. Это позволяет снизить накладные расходы на обновление конфигурации БД;
• быстро вносить хотфиксы в предпродуктовую и продуктовую среду;
• избежать динамического обновления конфигурации БД.

Основные возможности расширения, которые могут пригодиться при доработках типовой конфигурации (в режиме совместимости с 8.3.21):

• изменение программных модулей основной конфигурации;
• изменение основных свойств объектов (например, справочников, документов), длины кода, номера;
• добавление в состав движений документов основной конфигурации собственных движений;
• изменение описания типов реквизитов объектов основной конфигурации, в т. ч. добавление собственных типов и расширение составных типов;
• изменение описания типов для определяемых типов реквизитов;
• добавление в типовые подсистемы собственных объектов или существующих объектов основной конфигурации, которые отсутствуют в подсистеме по умолчанию;
• добавление собственных предопределенных значений для заимствованных объектов.

1. Собственные объекты метаданных (справочники, документы, регистры, общие модули и т. д., а также добавление реквизитов в существующие объекты метаданных основной конфигурации) следует создавать в основной конфигурации. 

На это есть ряд причин:

• В режиме «Конфигуратора» основная конфигурация и расширения находятся в разном пространстве имен. На текущий момент в платформе 8.3.23 расширение может видеть объекты основной конфигурации, но основная конфигурация не видит объектов расширения. Это вызывает неудобство, например, при создании внешних отчетов и обработок, которые работают в пространстве имен основной конфигурации.
• В случае «непредвиденного» удаления расширения отсутствует риск потерять данные в объектах, добавленных через расширение.
• Не влияет на дальнейшее обновление и поддержку основной конфигурации, поскольку собственные объекты не являются изменениями по отношению к новой конфигурации поставщика.

2. Минимизировать использование аннотации &ИзменениеИКонтроль

Использование аннотации &ИзменениеИКонтроль приводит к тому, что модифицированные методы в расширении «ставятся на поддержку». В случае обновления типовой конфигурации модифицированные таким образом методы придется восстанавливать вручную или с помощью дополнительных инструментов, например, KDIF. Это влечет дополнительные затраты на поддержку системы. Гораздо предпочтительнее использовать аннотации &Перед или &После, если есть такая возможность.

В общем виде на практике приоритет использования аннотаций следующий (от наивысшего к наименьшему, при наличии возможности реализации):

• &Перед/&После — для процедур; 
• &Вместо — только в паре с “ПродолжитьВызов()”;
• &ИзменениеИКонтроль.

3. Аннотацию &Вместо следует применять только в паре с “ПродолжитьВызов()”

В общем виде аннотацию &Вместо следует использовать только в паре с вызовом метода встроенного языка “ПродолжитьВызов()”. Использование аннотации &Вместо без конструкции ПродолжитьВызов() равносильно снятию расширяемого метода с поддержки. Изменение в расширяемом методе основной конфигурации никак не отслеживается в расширении, из-за этого можно не учесть важный функционал, который потенциально может быть заложен в основной конфигурации в новом релизе. 

Использование аннотации &Вместо, а затем копирование кода целиком или его отдельного участка расширяемого метода из основной конфигурации в переопределяемую процедуру или функцию, также является грубой ошибкой.

Пример использования: выполнить что-то после «Функции» основной конфигурации.

По понятным причинам аннотации &Перед и &После нельзя применить к «Функциям», поэтому когда нужно выполнить какое-то действие «После» выполнения функции основной конфигурации, можно использовать следующий подход (пример на рисунке).

В общем виде следует понимать, что расширение — это «вторая конфигурация сбоку». Создание нескольких расширений, в которых ведется доработка системы, может порождать проблемы, когда одни и те же механизмы модифицируются в нескольких расширениях разными разработчиками. Из-за этого могут возникать коллизии и взаимоисключения в доработках, что приводит к ошибкам.

Хотфиксы в продуктовой среде

Нередко возникают случаи, когда не до конца протестированная доработка попадает в продуктовую среду и может вызывать программную ошибку при выполнении определенных условий или при любых условиях. Использование расширений позволяет гибко решать такие ситуации, не прерывая работу и не выгоняя при этом всех пользователей из системы. В отличие от основной конфигурации, внесение изменений в расширение не вызывает динамического обновления и не требует монопольного режима, если не меняется структура базы данных. Это не приводит к печальным последствиям, которые могут возникнуть при динамическом обновлении основной конфигурации.

Но необходимо понимать, какие изменения можно вносить «на лету». Обновление расширения при наличии пользователей в системе допустимо проводить только для исправления ошибок. Обновление расширения не должно порождать две версии реализации одного алгоритма.

Пример: требовалось разработать программу, которая ожидает от пользователя ввода двух чисел. Программа должна посчитать произведение двух чисел и вывести результат пользователю на экран.

Ситуация №1

В процессе реализации разработчик допустил программную ошибку в алгоритме и пользователь получил на экран сообщение об ошибке вместо результата.

Поскольку в этом случае программа выдает ошибку в любом случае, допустимо внести исправление в расширении «на лету». В таком случае пользователи, работающие на старой версии расширения, будут все так же получать ошибку, а пользователи работающие на новой версии, увидят конечный результат. 

Подобная ситуация не приведет к возникновению ошибок в учете.

Ситуация №2

В процессе реализации разработчик не допустил программную ошибку и программа полностью выполняется. Однако совершил логическую ошибку, что в конечном итоге выдает неверный результат.

Разработчик быстро находит проблему и вносит исправление через расширение, обновляет конфигурацию расширения.

В результате образуются две версии одного алгоритма:

• Версия №1, содержащая логическую ошибку. Эту версию используют пользователи, которые работали в системе до обновления конфигурации расширения;
• Версия №2, выдающая корректный результат. Эту версию используют пользователи, которые работали в системе после обновления конфигурации расширения.

Подобный подход не следует использовать в разработке, поскольку в качестве алгоритма может выступать, например, запись движений в регистр. Это может привести к полной невозможности анализировать дальнейшие проблемы, которые возникнут в учете, поскольку отдельные пользователи могут работать в одном сеансе на старой версии алгоритма на протяжении нескольких дней после обновления. 

Для исправления подобных проблем следует:

• определить ближайшее технологическое окно для обновления конфигурации расширения, завершить сеансы всех пользователей, не смотря на то что структура базы данных не меняется;
• выполнить обновление конфигурации расширения;
• решать потенциально возникшие проблемы в учете привычными подходами.

При использовании расширений зачастую невозможно полностью отказаться от использования аннотации &ИзменениеИКонтроль.

Из-за этого после обновления релиза типовой конфигурации и изменения метода расширяемой конфигурации можно встретить подобный конфликт при проверке возможности применения расширения.

При значительной доработке системы можно встретить множество подобных конфликтов. Чтобы вручную не обращаться к каждому методу основной конфигурации и приводить в соответствие контролируемый участок кода в расширении с кодом расширяемой конфигурации, существуют различные инструменты, которые могут облегчить решение подобных ситуаций.
К одним из таких инструментов относится KDIF

Чтобы его подключить, нужно скачать с официального сайта исполняемый файл, а затем в конфигураторе через «Сервис — Сравнение/объединение» указать путь к исполняемому файлу.

После подключения инструмента в окне проверки применения расширения можно нажать на гиперссылку «Восстановить соответствие с методом конфигурации».

Интерфейс KDIF:

• в левой части экрана отображается код из старой конфигурации поставщика;
• в середине экрана отображается код из расширения;
• в правой части экрана отображается код из новой конфигурации поставщика;
• в нижней части экрана отображается результат, который будет записан в модуль расширения.

Зачастую KDIF автоматически решает конфликты при несоответствии методов конфигурации. Достаточно лишь проверить результат работы и сохранить изменения. В некоторых случаях может потребоваться ручное разрешение конфликтов.

Это в разы повышает скорость при восстановлении доработок в расширении в случае обновления релиза. При доработках в основной конфигурации без использования расширений операция по переносу доработок на новый релиз занимала на порядок больше времени.