При внедрении и сопровождении типовых решений на платформе «1С:Предприятие 8.3» перед разработчиком неизбежно встает дилемма: использовать ли механизм расширений или вносить изменения непосредственно в основную конфигурацию, включив возможность изменений. Этот выбор становится критически важным, когда объем доработок значителен (затрагивает более 30% функционала). В данной статье мы подробно проанализируем оба подхода, разберем технические нюансы обновления и сформируем оптимальную стратегию развития системы.
Прежде всего, проанализируем терминологию, так как часто возникает путаница между «снятием с поддержки» и «включением возможности изменений». Профессиональное сообщество подчеркивает: полное снятие с поддержки (удаление конфигурации поставщика) — это крайняя мера, которая лишает нас возможности использовать штатный механизм сравнения и объединения при выходе новых релизов.
Рассмотрим правильный алгоритм работы с основной конфигурацией:
Поддержка -> Обновить конфигурацию мы можем использовать режим «Показывать только дважды измененные объекты». Это позволяет четко видеть, где наши правки пересекаются с изменениями вендора.Выясним причину, почему нельзя использовать только один инструмент. Выбор метода зависит от сложности и типа вносимых изменений. Проанализируем основные критерии:
1. Сложность и глубина изменений в модулях.
Если нам нужно внести правки в начало или конец процедуры/функции, расширение с директивами &Перед или &После — идеальный вариант. Однако, если требуется серьезная переработка логики внутри метода, использование директивы &Вместо в расширении становится опасным. В этом случае мы берем на себя полную ответственность за код, и если 1С изменит типовой алгоритм, расширение продолжит исполнять старый код, что приведет к ошибкам. Здесь на помощь приходит аннотация &ИзменениеИКонтроль.
2. Хранение данных.
Это один из самых важных моментов. Проанализируем ситуацию: если мы добавляем новые справочники, документы или реквизиты в расширение, существует риск потери данных. Если администратор или клиент по ошибке удалит расширение (а не просто отключит его), все данные, хранящиеся в этих таблицах СУБД, будут безвозвратно удалены. Поэтому для критически важных данных рекомендуется создавать объекты в основной конфигурации.
3. Взаимосвязь объектов.
В расширениях сложно работать с запросами, если они обращаются к метаданным других расширений. Также существуют ограничения при работе с внешними обработками, которым нужны типы данных, определенные только в расширении. Если ваша доработка — это «надстройка», которая слабо связана с ядром, используйте расширение. Если вы «перепахиваете» фундамент — используйте основную конфигурацию.
Разберем подробнее механизм &ИзменениеИКонтроль, который появился в современных версиях платформы. Это компромиссное решение, позволяющее изменять часть кода, сохраняя контроль над остальным текстом метода. Рассмотрим на примере, как это работает:
Платформа запоминает «эталонный» текст метода. Если при обновлении типовой конфигурации вендор изменит этот текст, расширение выдаст ошибку при подключении. Это заставит разработчика проанализировать изменения и обновить «эталон» в расширении.
Пример структуры кода при использовании этой аннотации:
&Вместо("ТиповаяПроцедура")
&ИзменениеИКонтроль("ТиповаяПроцедура")
Процедура Моя_ТиповаяПроцедура(Параметр1)
// Содержимое типовой процедуры с нашими вставками
// #Вставка
Если МоеУсловие Тогда
ВыполнитьДействие();
КонецЕсли;
// #КонецВставки
КонецПроцедуры
Чтобы минимизировать головную боль при обновлениях, рассмотрим стратегию, которую применяют опытные архитекторы 1С. Основная цель — сделать конфигурацию «легко обновляемой» даже при больших объемах доработок.
Шаг 1. Использование подписок на события.
Вместо того чтобы вписывать логику в модуль объекта (например, перед записью документа), создадим ПодпискаНаСобытие в основной конфигурации. Это позволит выполнять ваш код, вообще не трогая текст типового модуля. Ваш код будет жить в отдельном общем модуле, который не конфликтует с обновлениями.
Шаг 2. Вынос логики в отдельные модули.
Если вам нужно дополнить работу блока, создайте свой общий модуль. Старайтесь минимизировать количество заимствованных объектов в расширении. В конфигурациях на базе БСП (Библиотека стандартных подсистем) обратите внимание на модули с постфиксом Переопределяемый. Они специально предназначены для кода разработчика и остаются пустыми в типовых поставках.
Шаг 3. Программное изменение форм.
Вместо того чтобы менять структуру формы в редакторе (что часто ведет к конфликтам при обновлении интерфейса вендором), используйте программное создание элементов в событии ПриСозданииНаСервере. Рассмотрим пример:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Добавляем новый реквизит и элемент формы программно
НовыйЭлемент = ЭтаФорма.Элементы.Добавить("МояКнопка", Тип("КнопкаФормы"), ЭтаФорма.Элементы.ГруппаКоманд);
НовыйЭлемент.Заголовок = "Выполнить спец. действие";
НовыйЭлемент.ИмяКоманды = "КомандаСпецДействие";
КонецПроцедуры
Проанализируем современный технологический стек. Если объем изменений достигает 1/3 базы, стандартный Конфигуратор может стать узким местом. Рассмотрим переход на 1C:EDT (Enterprise Development Tool).
Использование EDT в связке с системой контроля версий Git позволяет:
Посмотрим на ситуацию со стороны системного администрирования. Каждое подключенное расширение требует дополнительных ресурсов сервера 1С при компиляции модулей и запуске сеанса. Если у вас 20-30 тяжелых расширений, время открытия программы для пользователя может существенно вырасти. В таких случаях оправдан перенос стабильного, годами не меняющегося функционала из расширений в основную конфигурацию.
Подводя итог, сформируем оптимальный гибридный подход для серьезных доработок:
&ИзменениеИКонтроль.Помните, что главной метрикой качества вашей работы является не «красота» использования расширений, а TCO (Total Cost of Ownership) — совокупная стоимость владения системой, которая напрямую зависит от того, насколько быстро и дешево клиент сможет обновляться на новые релизы 1С.