В сообществе разработчиков 1С не утихают споры о границах применимости расширений конфигурации. С одной стороны, расширения позволяют оставить типовую конфигурацию на «замке», что существенно упрощает процесс обновления. С другой стороны, использование расширений для изменения структуры данных (добавления справочников, регистров, реквизитов) несет в себе скрытые угрозы. Разберем по шагам, какие риски существуют, почему опытные разработчики придерживаются определенных «негласных соглашений» и как обеспечить сохранность данных в долгосрочной перспективе.
Проанализируем основную техническую особенность расширений. Когда мы добавляем новый объект (например, Справочник или РегистрСведений) в расширение, платформа создает соответствующие таблицы в базе данных СУБД. Однако связь этих таблиц с расширением является критически зависимой. Выясним причину опасений многих специалистов: если в расширении произойдет критический баг, из-за которого конфигурация перестанет запускаться, стандартным методом решения проблемы часто является временное удаление или отключение этого расширения.
Важно помнить: при удалении расширения из информационной базы все данные, которые хранились в созданных им объектах или реквизитах, удаляются из СУБД безвозвратно. Рассмотрим ситуацию из практики: если вы добавили реквизит КодКонтрагента в расширение и по какой-то причине расширение было удалено администратором для восстановления работоспособности системы, после повторного подключения расширения вы обнаружите пустые поля. Восстановление в таком случае возможно только из резервной копии, что влечет за собой простой системы и дополнительные трудозатраты.
Посмотрим на существующий в профессиональной среде негласный стандарт. Большинство экспертов придерживаются мнения, что изменения должны распределяться следующим образом:
&Вместо, новые формы или модификация существующих интерфейсов.Такой подход минимизирует риски. Если логика в расширении «сломается», вы сможете его отключить, исправить и включить обратно, при этом все данные, созданные пользователями, останутся в безопасности в основной конфигурации.
Рассмотрим технический нюанс, связанный с регистрами и документами. Предположим, вы создали новый РегистрНакопления в расширении, а движения по нему должен делать типовой документ. В этом случае вам придется менять набор движений самого документа. Проанализируем ситуацию обновления такой конфигурации:
Если поставщик типового решения (например, фирмы «1С») изменит состав движений этого документа в новом релизе, возникнет конфликт. Однако, как показывает практика опытных разработчиков, эта проблема решаема. При обновлении на копии, подключенной к хранилищу, можно использовать механизмы сравнения и объединения. В частности, для измененных наборов движений или перечислений можно использовать настройку «Объединить с приоритетом файла» (или аналогичные настройки объединения метаданных), что позволяет сохранить ваши доработки и принять изменения поставщика.
Разберем реальный пример негативных последствий изменения стандартных реквизитов через расширение. Представим ситуацию: в расширении была изменена длина кода справочника Контрагенты с 9 до 20 символов. Пользователи начали активно заполнять базу, создавая коды большой длины. После обновления конфигурации расширение могло «слететь» или быть некорректно применено. В итоге длина кода вернулась к типовому значению (9 символов), и все данные, не умещающиеся в этот лимит, были обрезаны или искажены (заменены на нули). Это еще раз подтверждает, что фундаментальные изменения структуры данных (типы, длина, точность) безопаснее проводить в основной конфигурации.
Помимо риска потери данных, существуют функциональные ограничения, о которых стоит знать заранее:
Rls (ограничением доступа) и полнотекстовым поиском для объектов расширения может быть менее стабильной или требовать сложной дополнительной настройки.Несмотря на вышесказанное, бывают ситуации, когда метаданные в расширении — это допустимый компромисс:
Выясним итоговую позицию. Хотя современные версии платформы 8.3 предоставляют огромные возможности по работе с расширениями, не стоит ими злоупотреблять в ущерб надежности. Проанализируем шутливое описание «некачественной» статьи, которое подчеркивает важность лаконичности и полезности кода:
Статья = Новый Структура;
Статья.Вставить("Нытье", Истина);
Статья.Вставить("Избыточность", Истина);
Статья.Вставить("Лаконичность", Ложь);
Статья.Вставить("Полезность", Ложь);
Чтобы ваша разработка не превратилась в подобную «структуру», всегда оценивайте стоимость владения системой. Основная конфигурация для структуры, расширение для логики — это золотое правило, которое убережет вас от ночных звонков из-за потерянных данных и сделает поддержку системы предсказуемой.