Расширения 1С — Когда стоит использовать и чего остерегаться
В этой статье мы расскажем о преимуществах и подводных камнях использования расширений в разработке на 1С. Поделитесь этой статьей с тем, кто работает на 1С или только задумался об использовании 1С. Он скажет Вам спасибо))
И подпишитесь на наш ТГ-канал О внедрении и поддержке 1С без ошибок, где мы пишем о потребностях, проблемах и ошибках бизнеса при автоматизации на 1С, публикуем кейсы готовых внедрений и решений.
Введение
При работе с 1С:Предприятие многие компании сталкиваются с необходимостью адаптировать систему под свои уникальные бизнес-процессы. Однако любые изменения в стандартной конфигурации могут привести к проблемам с обновлениями и увеличению затрат на поддержку системы. Чтобы избежать этого, в 1С разработали инструмент расширений конфигурации, который позволяет вносить изменения, не затрагивая основной код.
Расширения открывают множество возможностей для кастомизации и добавления нового функционала, сохраняя при этом совместимость с типовыми обновлениями. Однако, несмотря на все преимущества, есть и определённые ограничения и риски, связанные с их использованием. В этой статье мы подробно рассмотрим, в чём заключаются основные плюсы и минусы расширений в 1С, чтобы помочь вам принять взвешенное решение о их использовании.
Когда появился механизм расширений в 1С?
Механизм расширений в 1С появился в 2014 году с выпуском версии 1С:Предприятие 8.3.5. Он был создан, чтобы упростить доработку системы и облегчить её обновление, сохраняя все сделанные изменения.
Зачем был нужен этот механизм?
Легче обновлять систему
Раньше, если нужно было что-то изменить в 1С, приходилось менять саму конфигурацию, и при обновлении эти изменения могли пропасть или вызвать ошибки. С расширениями это стало проще — все доработки сохраняются отдельно, и обновления устанавливаются без проблем.
Безопасность для основной конфигурации
Расширения позволяют добавлять новые функции и менять систему, не трогая основной код. Это снижает риск появления ошибок при обновлениях и упрощает тестирование.
Больше гибкости
С помощью расширений можно настроить 1С под нужды конкретной компании, не дожидаясь изменений от разработчиков. Это даёт возможность быстрее получить нужный функционал. В итоге механизм расширений был создан, чтобы помочь компаниям легко настраивать 1С под себя, но при этом продолжать получать обновления и поддержку без проблем.
Существуют разные типы расширений?
В зависимости от целей, расширения делятся на несколько типов: Исправление (патч), Адаптация и Дополнение. Для каждого из типов расширений установлен свой порядок их применения. В первую очередь применяются расширения с назначением Исправление, затем Адаптация, а после – Дополнение. Итак, какой тип расширения выбрать?
- Исправление – этот тип расширений, как следует из названия, используется для исправления ошибок или недочётов в типовой конфигурации. Применяют данный тип, чтобы оперативно внести изменения, не дожидаясь нового релиза или патча от 1С.
- Адаптация – этот тип расширения предназначается для доработок, которые на постоянной основе изменяют базовую логику работы без добавления нового функционала. Применяют данный тип расширения для подстройки конфигурации под особенности предприятия. Это может быть добавление новых реквизитов, изменение шаблонов документов или настройка прав доступа.
- Дополнение – этот тип расширения используют для добавления в конфигурацию новой функциональности, не затрагивая стандартную логику работы системы. Применяют данный тип, когда нужно внедрить что-то новое, чего изначально не было в системе, например, новый отчет, документ или регистр.
Контроль использования расширений не предусмотрен, и вся ответственность за варианты применения лежит на разработчике расширений. Порядок же применения расширений равен порядку в общем списке расширений конфигурации. Список разделён на три группы и каждое новое расширение добавляется в конец одной из групп в зависимости от выбранного назначения расширения:
Статья «Поговорим о расширениях» на сайте infostart.ru
https://infostart.ru/1c/articles/2033431/?ysclid=m1yl47src3456974205
Эксперты IBS на портале Habr вывели по десять плюсов и минусов использования механизма расширений, при этом отметив, что аргументы за было давать затруднительно. В таблице остались только самые ключевые:
| За | Против |
| Упрощение доработки типовых конфигураций и передачи на тестирование | Больше подходит для маленьких проектов и компактных конфигураций («1С:Бухгалтерия», «1С:Управление торговлей», «1С:Управление нашей фирмой») |
| Основная конфигурация недоступна для редактирования и остается закрытой на типовой поддержке, что сокращает время на поддержку и обновление. | Сложность администрирования, обновления и анализа ошибок при большом количестве расширений. |
| Возможность исправления ошибок в типовой конфигурации: отличным подспорьем является механизм патчей | Опасность потери данных при изменении структур метаданных и удалении расширения |
| Поддержка Фреша: хороший выход для работы «1С:Фреш» в режиме разделения данных | Увеличение сроков разработки за счет ее объема |
| Возможность реализации функционала по подсистемам | Невозможность добавить подчиненную систему |
Таблица «Использование расширений в 1С: за и против» на портале habr.com
https://habr.com/ru/companies/ibs/articles/824942/
Далее мы рассмотрим эти и другие аргументы за и против использования расширений в 1С, а также советы от рядовых программистов.
Какие ограничения существуют?
Регламентные задания в расширениях.
В версии 8.3.23 от 08.2022 появилась возможность создавать регламентные задания в расширениях конфигурации. Однако они не работают в режиме совместимости. В режиме совместимости конфигурация ограничена функциональностью более старых версий платформы, и регламентные задания, которые требуют точного управления временем и серверными ресурсами, не могут быть добавлены или изменены через расширения. Это сделано для предотвращения потенциальных сбоев в работе системы и обеспечения стабильной работы основной конфигурации.
Нельзя менять тип объекта метаданных.
Расширениями конфигурации нельзя менять тип объекта метаданных. Это ограничение связано с тем, что тип метаданных в 1С (например, справочник, документ, регистр сведений) определяет базовую структуру, поведение и способы хранения данных, которые система жёстко фиксирует. Такие изменения возможны только при доработке основной конфигурации.
Не рекомендуется добавлять новые метаданные в расширении.
Все новые объекты (документы, справочники, регистры и т.д.), а также новые реквизиты, измерения и ресурсы к уже существующим объектам основной конфигурации рекомендуется добавлять в основной конфигурации.
И хотя проблема с данными в расширениях на новых релизах частично решена (платформа видит, что данные внесены, и выдаст предупреждение об их потере при удалении расширения, а при отключении данные сохраняются, пока расширение не будет подключено вновь), в некоторых компаниях установлено «табу» на добавление новых реквизитов или метаданных в расширение.
Невозможно программно обращаться к объектам основной конфигурации, нужно переносить их в расширение.
Расширение не может напрямую обращаться к объектам основной конфигурации. Это ограничение введено для безопасности и предотвращения конфликтов, чтобы расширения работали отдельно и не нарушали основную логику программы. В результате расширение не может использовать модули, методы и свойства некоторых объектов конфигурации напрямую.
Чтобы обойти это, приходится переносить нужные объекты и код в расширение. Например, если нужно использовать общий модуль, приходится создавать его копию внутри расширения., но такой подход создает сложности: увеличивает объем кода, требует дублирования, усложняет обновление и поддержку.
Поэтому переносить нужно только действительно необходимые объекты и код, чтобы минимизировать сложность и сохранить работоспособность всей системы.
Невозможно анализировать изменения при обновлении.
При доработке конфигураций, находящихся на поддержке через расширения, возникают проблемы при выпуске вендором новых версий основной конфигурации. Часть проблем можно решить, используя директиву &ИзменениеиКонтроль, однако при использовании директив &Вместо, &После и &Перед нет типовых средств, позволяющих понять, а не потеряло ли расширение актуальность, не требуется ли доработка переопределенных методов.
Также типовая проверка применимости не учитывает переопределение событий форм и их реквизитов (вместо переопределения методов модуля).
Решить данную проблему предлагает автор в статье «Анализ изменений в расширении при обновлении основной конфигурации» на сайте infostart.ru
Данные, хранящиеся в расширении, могу быть потеряны при его обновлении и удалении.
Удаление расширения – это ответственная операция. При удалении расширения, если оно хранит данные в информационной базе, они будут безвозвратно утеряны. Перед удалением приложение выведет соответствующее предупреждение и рекомендацию сделать резервную копию перед удалением:
Если расширение отключить, то данные сохранятся, но будут недоступны, пока расширение не будет включено снова. Если расширение перестаёт подключаться, то данные также не будут утеряны, но будут недоступны, пока Вы не исправите причину этого.
Обновление расширения не должно приводить к потере данных, однако нет гарантии, что это не произойдёт. Не редки случаи, когда во время обновления расширение удалялось и данные пропадали. Всегда делайте резервную копию перед началом работ с информационной базой.
Подробнее об обновлении и удалении расширений можно прочесть в заметках разработчиков 1С (Заметки из Зазеркалья): https://wonderland.v8.1c.ru/blog/rasshirenie-dannykh/ А также в комментариях пользователей на форуме Инфостарт Расширение конфигурации (Собственные объекты): Расширение конфигурации (Собственные объекты) — Форум.Инфостарт
Использование директивы &Вместо
Директива &Вместо позволяет переопределить существующий код в конфигурации, заменяя метод или другой элемент системы на свой собственный. Многие доработки не реализовать без данной директивы, но в расширениях её лучше не использовать вообще, так как её использование может нести ряд проблем, особенно при работе с обновлениями и несколькими расширениями одновременно.
Подробнее об этом можно прочитать в статье «Расширение модулей» на сайте разработчиков 1С wonderland.v8.1c.ru в разделе «Что лучше, &Перед, &После или &Вместо?», а также интересный кейс от архитектора 1С Юрия Былинкина в статье «Как выжить, если у тебя в базе 1С 50+ расширений» на сайте infostart.ru, в которой он буквально называет директиву &Вместо «Злом».
Когда многое не работает проще удалить и ждать, когда напишут, что что-то сломалось.
Во время написания статьи нам довелось пообщаться со штатным программистом нашего клиента, который активно переносил доработки из расширений в основную конфигурацию. Поэтому я решил включить его рассуждения и кейсы в эту статью.
Внимание!
Дальнейший текст написан на языке программистов 1С и приведены цитаты штатного программиста нашего клиента
Формы — это больное место.
— «Есть форма, в неё добавили изменения графически, поковырялись в коде. Та же форма есть и в расширении: также изменена графически, внесены изменения в код, изменены события, добавлены &Перед и &После. Сколько бы я ни искал, 1С просто не предоставляет никаких инструментов для сравнения, чем они отличаются. В конфигурации я могу это сравнить: вижу код, адаптирую, а то, что реквизиты добавлялись интерактивным способом, 1С не показывает. Приходится либо объединять с приоритетом, либо заменять. Искал способы решения данной проблемы, но нашёл только жалобы программистов.»
— «Форма в расширении перекрывает форму из основной конфигурации. В основной конфигурации обновили, но то, что в расширении есть эта же форма, программа не предупреждает. Изменения не прошли, либо прошли, но с ошибкой. Обновляю форму в расширении — ошибка меняется на другую».
— «Сравнить, что есть в расширении, а что в конфигурации, можно, но для этого нужно специально создавать другое расширение, выгружать туда нужные объекты из конфигурации и уже затем сопоставлять расширение с расширением.»
— «Хочешь к чему-то обратиться, а не видишь это, потому что оно находится в расширении. Расширение видит основную базу, а вот расширения друг друга уже нет. По крайней мере, не всегда.»
— «Была ошибка, от которой не помогло ни обновление формы, ни объединение с приоритетом. Я убрал форму из расширения и перенёс с неё доработки на основную конфигурацию. Графические изменения перенёс в виде кода. В результате получилось, что для этой формы теперь можно спокойно сравнивать код, а саму форму просто объединять с заменой на то, что придёт с обновлением.»
Два преимущества
— «Случилось что-то критическое, и нужно добавить новый объект. База просит реструктуризацию, и приходится выгонять всех пользователей, чтобы внести изменения. Кто-то может случайно вмешаться в процесс обновления, и само по себе наличие пользователей в базе может привести к неожиданным последствиям. В расширении этого делать не нужно (выгонять пользователей — прим. автора). Кому нужно — перезайдут в базу, и у них всё будет работать. Однако после этого желательно перенести всё из расширения в основную конфигурацию, чтобы не хранить новые реквизиты или справочники в расширении.»
— «Сам не проверял, но говорят, что если хранить данные в расширении, оно нагружает работу системы и снижает скорость, по сравнению с хранением этих данных в основной базе. После того, как я удалил много данных из расширений и перенёс их в основную базу, по словам коллег, система стала работать быстрее и занимать значительно меньше места.»
— «Преимущество базы, находящейся на поддержке без возможности изменений, в том, что её можно обновлять типовым методом. В этом случае все изменения придётся вносить через расширения, но после обновления всё равно потребуется проверить их работу. Однако если база уже изменена как только возможно, смысла в расширениях больше нет.»
Нюансы повреждённой базы
— «В силу специфики работы у нас была очень доработанная форма заявок на расходование денежных средств и любое, малейшее, изменение (даже поменять местами два реквизита на форме) приводило к тому, что она не открывалась с неопознанной ошибкой. Было очень много сбоев, возможно потому, что расширение делали давно и, может быть, что-то повредилось. То есть расширения ещё и могут быть повреждёнными и выяснить это можно будет только тогда, когда что-то поменяется, пройдёт изменение структуры. В этом случае пришлось удалять форму, потому что доработать что-то или чуть-чуть изменить я уже не мог.»
Хромающее расширение
— «У нас было очень сильно хромающее расширение. Какие-то вещи не работа настолько, что их было проще удалить и ждать заказов, что что-то там перестало работать, чем разбираться как это всё починить. И не факт, что это нужно. Я спрашиваю коллег: «Это нужно?». Мне отвечают: «Да». Переспрашиваю: «А Вы пробовали это открыть?». Открывают, а там ошибка! Пустой справочник, пустой документ, реквизит, который не заполнен ни в одном из десятков тысяч документов – всё это говорит о том, что некоторые вещи проще удалить, а потом уже сделать заново. Главное, что аккуратно нужно делать – это реквизиты и документы. Формы можно удалять. Форма – это внешний вид, если что её можно вернуть не повредим данные. Регистры, документы, справочники, реквизиты уже хранят данные и если их удалить – теряется информация, которая в них записана.»
— «Ещё есть большая проблема с переносом реквизитов. Когда кто-то сделал реквизит в расширении приходится делать такой же реквизит в базе, только с другим наименованием. Иначе будет конфликт. Далее нужно делать обработку, которая всё это перенесёт.»
Что можно посоветовать тем, кто уже использует расширения?
- Не дробить расширения для одного объекта конфигурации.
Если изменения касаются одной формы, создавайте одно расширение и дополняйте его при последующих задачах, вместо создания новых. Изменить последовательность исполнения расширений сложно, особенно если они содержат данные. Хорошим решением будет объединять расширения по функциональности, а не только по объектам, но это требует продуманного подхода в начале доработок. При добавлении одинакового функционала в несколько объектов может быть лучше объединить его в одно расширение, хотя это нарушает принцип «одно расширение — один объект». - Изменения расширяемых форм делать программно.
Изменения в расширяемых формах лучше делать программно, не полагаясь на автоматическое обновление через «Обновить расширение формы». Отходить от этого правила можно, если расширение — временное исправление ошибки, ожидаемой к устранению в следующем релизе. - Минимизирован использование аннотации &Вместо.
Избегайте аннотации &Вместо, где возможно, заменяя её на &Перед или &После, чтобы не перехватывать полностью исходную логику и избежать проблем при обновлении конфигурации. В версиях 8.3.15+ появилась аннотация &ИзменениеИКонтроль, которая позволяет менять отдельные строки в процедуре без полной замены. Платформа будет отслеживать изменения исходного кода и оповещать при необходимости анализа ваших дополнений. - Делать независимые друг от друга расширения.
Да, из одного расширения можно вызвать функцию другого — это удобно для создания общего набора процедур, используемых в других расширениях. Однако такой подход создаёт зависимость: изменения в общем расширении могут повлиять на все остальные. Если контролировать изменения, это допустимо, но требует осторожности. - Новые объекты конфигурации, предполагающие хранение данных, добавлять в основную конфигурацию. Несмотря на улучшения безопасности в расширениях, данные критической важности (справочники, документы, регистры) лучше хранить в основной конфигурации для облегчения обновлений. В расширениях можно хранить менее важные данные, такие как настройки и логи.
- Вести реестр расширений.
Документирование всех изменений в типовой конфигурации — обязательно, чтобы избежать сложностей при обновлениях. Важно также вести реестр всех расширений с их описанием и указанием процедур и функций, особенно тех, что используют аннотацию &Вместо — это упростит обновления. Мы, например, ведем реестр в OneNote с ссылками на ТЗ и GIT-хранилище. Формат можно выбирать по удобству, но главное — обеспечить понимание для других специалистов.
Все вышеперечисленные пункты рассмотреть подробнее можно в статье «О расширениях замолвите слово…» на сайте infostart.ru
Что по итогу?
Механизм расширений так или иначе неотъемлемая часть разработки 1С, которая постоянно развивается и возможно, в следующих релизах те или иные ограничения канут в Лету. К тому же нельзя не отметить такие очевидные плюсы, как возможность реализовывать на расширениях хотфиксы – быстрые исправления или же лёгкость их передачи и установки для клиента. А для облачных баз это может быть единственным способом реализации доработок.
Однако расширения конфигурации всё же не лучший вариант для ведения полноценной разработки. По крайней мере сейчас.