При активной разработке в расширениях конфигурации 1С программисты часто сталкиваются с ситуацией, когда система автоматически добавляет в дерево расширения множество «лишних» объектов — реквизитов, справочников или перечислений. Разберем подробно, почему это происходит, стоит ли чистить расширение от таких объектов и какие технические риски несет избыточное заимствование при обновлении системы.
Рассмотрим причины, по которым платформа «тянет» объекты основной конфигурации в расширение. Прежде всего, это необходимо для обеспечения корректности синтаксического контроля. Если в коде расширения вы обращаетесь к реквизиту объекта основной конфигурации, а этот реквизит не заимствован, конфигуратор выдаст ошибку, так как в контексте расширения этот идентификатор будет неизвестен.
Второй важный момент — работа с конструктором запросов. Чтобы вы могли интерактивно выбирать поля таблиц в конструкторе, эти таблицы и их поля должны присутствовать в метаданных расширения. Проанализируем плюсы и минусы наличия таких объектов:
Проанализируем две основные стратегии поведения разработчика, которые обсуждаются в профессиональном сообществе.
Стратегия 1: Оставлять всё как есть. Это наиболее простой путь. Вы заимствуете объект (например, справочник Номенклатура), и система добавляет его в расширение вместе с типами, которые он использует. Это удобно, так как не прерывает процесс разработки. Однако со временем расширение превращается в «копию» части основной конфигурации, что затрудняет анализ того, что именно было изменено вами.
Стратегия 2: Регулярная очистка. Вы периодически удаляете из расширения объекты, которые не подвергались изменениям и не используются в вашем коде напрямую. Это делает расширение «легким» и понятным. Для облегчения этой задачи воспользуемся встроенным инструментом: в контекстном меню расширения выберем пункт «Удалить неиспользованные заимствованные объекты». Это позволит автоматически вычистить дерево от случайных элементов.
Разберем ситуацию, которая часто вызывает сложности при поддержке расширений. Когда вы заимствуете объект, расширение делает своего рода «снимок» его свойств. Если в основной конфигурации поставщик (например, фирма 1С) изменит тип реквизита или длину строки, может возникнуть конфликт совместимости.
Выясним причину: при запуске системы платформа проверяет соответствие заимствованного объекта в расширении его оригиналу в основной конфигурации. Если обнаружится различие в критичных свойствах (например, в основной конфигурации длина кода справочника стала 15, а в расширении осталась 10), расширение может просто не подключиться. В этом случае пользователю выдается сообщение об ошибке, и весь ваш функционал перестает работать.
Чтобы минимизировать этот риск, проанализируем настройки свойств заимствованного объекта. В палитре свойств для каждого реквизита в расширении можно найти флаги проверки. Если мы снимем флаг «Проверять значение» для таких свойств, как Длина или Точность, платформа будет игнорировать эти изменения при запуске, что повысит стабильность системы.
Посмотрим на развитие механизмов заимствования. В старых версиях платформы (до 8.3.14) заимствование происходило более агрессивно. Начиная с версии 8.3.15, 1С внедрила механизм так называемого «ленивого заимствования».
Теперь платформа старается не тянуть в расширение лишние метаданные, если для выполнения операции достаточно знания только о типе объекта. Это значительно упростило жизнь разработчикам, так как количество автоматически добавленных «хвостов» сократилось. Однако, как отмечают специалисты, это иногда усложняет прохождение проверки синтаксиса, если вы привыкли к полной видимости всех реквизитов.
Если вы решили оставлять заимствованные объекты для удобства разработки, воспользуемся стандартным фильтром конфигуратора, чтобы не путаться. В верхней части дерева метаданных расширения найдем кнопку «Показать только измененные объекты».
Эта функция скрывает все заимствованные объекты, в которых не было сделано никаких правок (не добавлены новые реквизиты, не изменены формы, не переопределены методы). Таким образом, вы будете видеть только суть своих изменений, а «служебные» объекты останутся в расширении для корректной работы компилятора и конструкторов, но не будут мешать обзору.
Особую осторожность проявим при заимствовании форм. Рассмотрим сценарий: вы заимствовали форму документа только для того, чтобы добавить одну кнопку. Платформа при этом заимствует не только форму, но и все реквизиты, связанные с элементами этой формы.
Важно помнить: если разработчик основной конфигурации изменит код в модуле этой формы, ваше расширение (если вы используете аннотацию &Вместо или просто перекрываете форму) может работать со старой логикой. Поэтому при каждом обновлении основной конфигурации необходимо анализировать список заимствованных форм и сопоставлять их с изменениями поставщика.
Подводя итог, можно сказать, что выбор между «удалять» или «оставлять» зависит от масштаба проекта. Для небольших расширений лучше поддерживать чистоту, удаляя лишнее. Для крупных проектов с интенсивным использованием запросов и сложной типизацией наличие заимствованных объектов оправдано скоростью разработки, при условии использования фильтров видимости в конфигураторе.