Расширения 1С: хотфикс или костыль?
Эксперты IBS, старший разработчик Арсен Омаров и руководитель региональной группы Галина Носкова, взвешивают за и против механизма расширений 1С и объясняют, в каких случаях их можно и нужно использовать.
Теме расширений 1С был посвящен недавний круглый стол на крупнейшей региональной ИТ-конференции России «Стачка» в Ульяновске. Применение расширений горячо обсуждают с момента появления этого механизма, и у него есть свои ярые сторонники и противники. Стоит сказать, что мы шли на круглый стол с твердым убеждением, что нам будет трудно подобрать аргументы против, но оказалось, что большинству сложнее найти аргументы за.
История развития механизма расширений
1С представила расширения в 2015 году в рамках версии платформы 8.3.6. Механизм расширений создавался как инструмент для исправления, адаптации и доработок типовой функциональности прикладных продуктов на базе 1С под нужды заказчика. Стратегия, предлагаемая расширениями, заключается в том, что изменять основную конфигурацию не нужно: все корректировки выполняются в расширении, которое, по сути, тоже является конфигурацией. После этого расширение просто подключается к типовой конфигурации, а платформа автоматически их объединяет.
Понятно, что на раннем этапе расширения давали весьма ограниченные и тривиальные возможности. Но уже более десяти лет вендор активно развивает эту технологию, и сегодня в расширениях есть даже реализация функциональных блоков.
Ключевые вехи в развитии механизма расширений в разрезе платформы представлены на двух схемах ниже.
Применение расширений
Важной характеристикой расширения, появившейся в версии платформы 8.3.10, является его назначение. Это свойство выбирается из трех предусмотренных значений:
Порядок применения расширений к информационной базе определяется именно их названием. Это важно понимать, чтобы знать, какие доработки будут выполнены системой в первую очередь. Порядок выполнения именно такой: сначала применяются расширения с назначением Исправление, затем Адаптация, а после этого — Дополнение. Такой подход позволяет избежать конфликтов между функциональностью расширений с разным назначением.
Использование расширений в 1С: за и против
В ходе круглого стола участники накидали в общей сложности около 10 плюсов и минусов механизма расширений, причем аргументы за давались, что называется, со скрипом. В таблице мы оставили только самые ключевые:
За | Против |
Упрощение доработки типовых конфигураций и передачи на тестирование | Больше подходит для маленьких проектов и компактных конфигураций (»1С: Бухгалтерия»,»1С: Торговля»,»1С: ЗУП») |
Основная конфигурация недоступна для редактирования и остается закрытой на типовой поддержке, что сокращает время на поддержку | Сложность администрирования, обновления и анализа ошибок при большом количестве расширений |
Возможность исправления ошибок в типовой конфигурации: отличным подспорьем является механизм патчей | Опасность потери данных при изменении структур метаданных и удалении расширения |
Поддержка Фреша: хороший выход для работы »1С: Фреш» в режиме разделения данных | Увеличение сроков разработки за счет ее объема |
Возможность реализации функционала по подсистемам | Невозможность добавить подчиненную систему |
В целом расширения, безусловно, не бесполезный механизм. Как говорил Маяковский, «если звезды зажигают — значит — это кому-нибудь нужно». Или в нашем случае: если вендор придумал механизм расширений — значит — он кому-то упрощает работу. Другое дело, что у этого механизма есть свои подводные камни, ограничения и особенности функционирования, которые нужно всегда держать в голове. Ниже рассмотрим некоторые специфические моменты.
Возможности заимствования объектов и методов из основной конфигурации
№ 1. Добавление в расширение функции общего модуля:
№ 2. Добавление в расширение процедуры общего модуля:
А вот использование глобальных серверных общих модулей в расширении недопустимо:
Очередность применения изменений и несколько расширений
Дано:
Некая процедура основной конфигурации и два зарегистрированных расширения с одним типом назначения, добавленных последовательно в информационную базу. Первым добавлено «Расширение1», вторым — «Расширение2». Ниже отображен порядок перехвата выполняемой процедуры «Расширяемая» из исходной конфигурации:
Далее на примере тех же двух расширений посмотрим, как будет вести себя система с использованием аннотации «Вместо»:
Теперь на примере тех же двух расширений посмотрим, как будет вести себя система с использованием аннотации «Вместо» с использованием «ПродолжитьВызов ()»:
Применение аннотации «ИзменениеИКонтроль, позволяющей удалить часть кода и заменить его другим:
Удаление расширений и необратимость последствий
Если в названии расширения есть реквизит, то при попытке его удаления мы получим следующее предупреждение:
Здесь действительно важно проявить осторожность. Если мы случайно удалим расширение с нужными данными, то при попытке его переподключить восстановить значение реквизита, отсутствовавшего в основной конфигурации, уже не получится.
Ограничения по количеству расширений в одной базе данных
Как выяснилось на «Стачке», для некоторых разработчиков 5 расширений — это уже невообразимое число, когда дело доходит до обновлений, потому что на каждое расширение придется создавать свое хранилище. Других не смущает даже набор из 20 расширений.
Конечно, всему есть предел. Коллеги привели пример из практики, когда обновление системы »1С: Розница 2» со множеством расширений до последнего релиза заняло два месяца и потребовало работы целого отдела. Для понимания: расширений в этом примере было столько, что они заняли сразу два скриншота.
Пример, конечно, экстремальный, но это еще не значит, что на механизме расширений нужно поставить крест. В конце концов, скорость процесса обновления напрямую зависит от выбранных подходов и инструментов обновления.
Использование расширений в 1С: итоги
Кажется, несмотря на бурные дискуссии, все коллеги в итоге остались при своем. Одни считают расширения эффективными хотфиксами, сильно упрощающими жизнь разработчиков; другие соприкоснулись с механизмом в 2015 году, быстро разочаровались ограничениями (например, невозможностью добавить индексирование в регистр) и больше ни разу не давали расширениям шанс. По опыту проведения собеседований в IBS, около 25% кандидатов рассказывают о негативном опыте работы с расширениями и не хотят применять их на своих проектах. Еще 25% не владеют или в принципе не слышали про такой инструмент. Оставшиеся 50% применяют в работе расширения или не против начать.
К какому выводу пришли лично мы? Расширения — это современная адаптивная технология, которая продолжает совершенствоваться. В целом расширения — хороший, быстрый и удобный инструмент, если правильно им пользоваться.
С помощью этого механизма можно выпустить отдельное подсистемное или интеграционное расширение. К примеру, свои расширения выпускает и регулярно обновляет система электронного документооборота Диадок. Их можно просто скачать и дорабатывать с минимальными нагрузками на основную конфигурацию, что гораздо проще, чем пытаться внедрять сам Диадок в типовую конфигурацию.
Тиражное же решение Диадока удобно, хоть и нарушает исходное позиционирование расширений как инструмента для маленьких доработок и багфиксов. Незаметно для нас самих механизм, созданный для определенного размера задач, почему-то стал повсеместно использоваться для крупных проектов и тиражных решений.
Безусловно, у механизма расширений есть и другие темные стороны. Когда мы используем множество расширений, то начинаем в них теряться. Если несколько расширений используют один и тот же объект, то это создает большие проблемы для разработки, отладки и отслеживания ошибок. Выстраивая архитектуру проекта, обязательно нужно контролировать количество расширений, количество используемых метаданных и устанавливать жесткие правила не только для своей команды, но и по возможности для заказчика. Если клиент говорит, что на каждый документ или процесс ему необходимо отдельное расширение, нужно уметь аргументировать, почему такое решение ошибочно и неизбежно повлечет за собой проблемы. Обычно этим, к слову, грешат заказчики, пришедшие с SAP, где механизм расширений работает совершенно иначе.
В целом при использовании расширений нужно придерживаться функциональных, архитектурных стандартов разработки, описанных в »1С: ИТС», и тогда механизм принесет больше пользы, чем сложностей. Для решения каждой конкретной задачи нужно применять лучшую практику, а выбор должен напрямую зависеть от контекста проекта. Когда мы не можем позволить себе полный продуктовый цикл, а изменения нужно внести прямо здесь и сейчас, расширения 1С — блестящий хотфикс.
