Технология расширений в платформе «1С:Предприятие 8.3» прошла долгий путь эволюции. На этапе её появления многие разработчики относились к ней с опаской, предпочитая классическое изменение метаданных в основной конфигурации. Сегодня расширения стали стандартом де-факто для кастомизации типовых решений. В этой статье мы подробно разберем, стоит ли связываться с расширениями, с какими подводными камнями можно столкнуться при их использовании, а также рассмотрим методологию безопасного переноса доработок из измененной основной конфигурации.
Основная цель создания расширений — это сохранение типовой конфигурации на полной поддержке поставщика (так называемый «замок»). Давайте проанализируем ключевые преимущества, которые дает этот подход:
Несмотря на очевидные плюсы, технология расширений имеет свои особенности, которые могут усложнить жизнь разработчику, если их не учитывать заранее. Рассмотрим основные проблемы, с которыми сталкиваются на практике:
1. Зависимость от структуры метаданных поставщика. Если в расширении используются заимствованные объекты (например, документы или справочники), то при изменении этих объектов поставщиком расширение может «отвалиться». Выясним причину: если фирма «1С» переименует реквизит или изменит тип данных заимствованного поля (как в примере с переименованием документа ПоступлениеТоваровУслуг в ПриобретениеТоваровУслуг), расширение заблокирует запуск системы из-за конфликта метаданных. В таких случаях программисту все равно придется вмешиваться и корректировать код расширения.
2. Потребление оперативной памяти и производительность. При запуске клиентского сеанса платформа динамически компилирует и объединяет метаданные основной конфигурации и всех активных расширений. На тяжелых ERP-системах (таких как ERP Управление предприятием или Комплексная автоматизация) это может приводить к нехватке памяти на сервере или клиентских машинах при обновлении или запуске. Разберем по шагам, как минимизировать эту проблему далее в статье.
3. Риски потери данных. Если вы создаете новые реквизиты или таблицы внутри расширения, вы должны помнить о главном правиле безопасности: при случайном удалении расширения администратором базы данных все физические таблицы этого расширения в СУБД будут безвозвратно удалены вместе с хранящимися в них данными. Восстановить их можно будет только из резервной копии.
Для модификации существующего кода в модулях платформы используются специальные аннотации. Давайте разберем их особенности и область применения:
&Перед — позволяет выполнить ваш код перед вызовом типовой процедуры или функции. Исходный код типового решения гарантированно выполнится после вашего кода.&После — ваш код выполнится сразу после завершения работы типового метода. Отличный вариант, когда нужно обработать результат вычислений или дозаполнить реквизиты формы.&Вместо — полностью заменяет типовой метод вашим собственным кодом. Внимание! Использование этой директивы противоречит самой концепции расширений. Если поставщик обновит логику замещенной процедуры, ваши пользователи никогда не увидят этих изменений, так как будет выполняться только ваш код. Это может привести к скрытым логическим ошибкам в учете.Для решения проблемы точечного изменения кода без полной его замены разработчики используют важнейшую аннотацию &ИзменениеИКонтроль. Она появилась в платформе начиная с версии 8.3.15 и стала настоящим спасением.
Рассмотрим пример использования аннотации &ИзменениеИКонтроль. Предположим, нам нужно встроить проверку заполнения реквизита в середину типовой процедуры расчета стажа:
&Вместо("РассчитатьСтажСотрудника")
&ИзменениеИКонтроль("РассчитатьСтажСотрудника")
Процедура Расш_РассчитатьСтажСотрудника(Сотрудник, Параметры)
// #Вставка
Если Не ЗначениеЗаполнено(Параметры.ДатаПриема) Тогда
ВызватьИсключение "Не заполнена дата приема на работу!";
КонецЕсли;
// #КонецВставки
// Здесь идет оригинальный код поставщика, который контролируется платформой
Стаж = КадровыйУчет.ВычислитьСтаж(Сотрудник, Параметры);
КонецПроцедуры
При таком подходе платформа запоминает исходный текст процедуры поставщика. Если при очередном обновлении разработчики «1С» изменят оригинальную процедуру РассчитатьСтажСотрудника, платформа выдаст предупреждение о несовместимости, и вы сможете визуально сопоставить изменения. Это полностью исключает «тихие» ошибки при обновлении.
Если перед вами стоит задача перенести существующие доработки из старой измененной базы в расширение, действовать «напрямую» и переносить все подряд вручную — трудоемко и неэффективно. Проанализируем пошаговый алгоритм безопасной миграции:
Шаг 1. Аудит изменений. Выполните сравнение вашей рабочей конфигурации с типовой конфигурацией поставщика той же версии. Сформируйте подробный отчет о сравнении конфигураций. Нам нужно четко разделить изменения на три категории: изменения интерфейса (формы), изменения логики (модули) и новые объекты/реквизиты данных.
Шаг 2. Разработка правил префиксации. Чтобы избежать конфликтов имен в будущем, обязательно выберите уникальный префикс для всех объектов и процедур в расширении. Например, префикс расш_ или префикс вашей компании ит_. Все новые реквизиты, заимствованные формы и модули должны содержать этот префикс: расш_ДатаДоговора, расш_ПроверитьЗаполнение().
Шаг 3. Создание расширения и заимствование объектов. Создайте новое расширение в конфигураторе. Назначьте ему тип «Адаптация». Добавьте в расширение только те объекты метаданных, формы или модули которых вы непосредственно модифицируете. Не затягивайте объекты целиком «на всякий случай» — следуйте правилу минимального заимствования. Это спасет сервер от нехватки памяти при компиляции метаданных.
Шаг 4. Перенос данных (Критически важный шаг). Если в основной конфигурации были добавлены новые реквизиты, в которых уже хранятся реальные данные пользователей, переносить их напрямую в расширение опасно. Рекомендуется использовать гибридную схему:
Шаг 5. Перенос программного кода. Скопируйте логику измененных процедур и функций. Используйте современные аннотации &Перед, &После и &ИзменениеИКонтроль вместо устаревшей &Вместо. Постарайтесь вынести вашу уникальную бизнес-логику в отдельные новые общие модули внутри самого расширения, а в заимствованных модулях оставить лишь минимальные вызовы этих процедур.
Шаг 6. Очистка основной конфигурации и возврат на поддержку. После того как вы перенесли всю логику в расширение и тщательно протестировали работу системы, удалите измененные объекты из основной конфигурации. Верните основную конфигурацию на полную поддержку поставщика («на замок»).
Для облегчения рутинной работы по переносу доработок можно использовать специализированные инструменты. Обратите внимание на проект «Инструменты разработчика» (ИР), который существует в виде расширения. Этот инструмент позволяет быстро анализировать структуру метаданных, отслеживать зависимости объектов и выявлять проблемные участки кода при переносе.
Также существуют различные обработки по автоматизированному переносу несложных изменений в расширения, доступные на профильных сообществах разработчиков 1С. Однако помните, что ни одна автоматическая обработка не заменит ручного контроля логики, особенно когда речь идет о сложных формах и запросах.
Долгое время существенным ограничением расширений была невозможность их автоматической передачи по каналам РИБ. В старых версиях платформы администраторам приходилось обновлять расширения вручную на каждом удаленном узле. Выясним текущую ситуацию: в современных версиях платформы 1С реализована полная поддержка обмена расширениями через механизмы РИБ. Теперь при изменении конфигурации расширения на главном узле изменения автоматически регистрируются к обмену и доставляются на все периферийные узлы при очередном сеансе синхронизации, что значительно упрощает администрирование крупных филиальных сетей.
Подведем итог нашего анализа. Использовать расширения однозначно стоит. Это современный, гибкий и перспективный стандарт разработки в экосистеме 1С. Для минимизации рисков и обеспечения стабильной работы придерживайтесь следующих правил:
&Вместо без крайней необходимости. Отдавайте предпочтение аннотации &ИзменениеИКонтроль.Перевод доработок на рельсы расширений позволит вам существенно сократить время на рутинные обновления и сосредоточиться на развитии функционала вашей системы.