Вопрос о том, стоит ли вносить изменения напрямую в конфигурацию 1С или использовать механизм расширений, является стратегическим для любого проекта автоматизации. С одной стороны, расширения обещают «чистую» конфигурацию на замке и простое обновление. С другой — разработчики часто выставляют значительно большие счета за реализацию тех же задач через расширения. Разберем подробно, почему возникает такая разница в оценке, какие риски несут расширения и в каких ситуациях их использование действительно оправдано.
Ситуация, когда задача оценивается в 6–8 часов при доработке в конфигурации и в 20–24 часа при использовании расширения, является типичной. Проанализируем причины такого разрыва. В основной конфигурации все объекты и связи уже существуют. Чтобы подключить, например, механизм подбора номенклатуры, программисту достаточно вызвать стандартную форму. В расширении же контекст ограничен. Чтобы механизм заработал, часто требуется заимствовать в расширение десятки связанных объектов: справочники, общие модули, перечисления, картинки и даже роли.
Рассмотрим по шагам, на что уходит время при работе с расширением:
&Перед, &После и особенно &Вместо требует глубокого анализа типового кода, чтобы не нарушить логику работы платформы.Существует миф, что расширения упрощают жизнь при обновлении. Проанализируем ситуацию глубже. При обновлении конфигурации, снятой с поддержки, разработчик видит окно сравнения и объединения. Это прозрачный инструмент: слева — код поставщика, справа — ваш код, посередине — результат. Вы четко видите, если 1С изменила ту же строку, которую правили вы.
В случае с расширениями ситуация иная. Платформа проверяет только техническую возможность применения расширения (не удалены ли заимствованные объекты). Однако она не проверяет логическую целостность. Если фирма 1С переписала процедуру, которую вы перехватываете через &Вместо, расширение применится успешно, но данные в базе начнут портиться или функции перестанут работать. Выясним основные минусы поддержки расширений:
Разберем ситуацию с новыми объектами. Если вы создаете абсолютно новый документ, который не связан с типовыми регистрами, его можно разместить и в расширении. Однако помните о проблеме миграции данных. Объекты в расширении имеют свою область имен. Если через два года вы поймете, что расширение стало слишком тяжелым, и решите перенести документ в основную конфигурацию, вы не сможете сделать это простым копированием с сохранением ссылок (GUID). Это фактически создаст новый объект, и данные придется переносить специальными обработками.
Также важно учитывать Безопасный режим. По умолчанию расширения работают в нем, что накладывает ограничения на:
Проанализировав опыт внедрений, мы можем сформулировать следующие правила выбора метода доработки:
Если вы все же решили использовать расширение для модификации поведения системы, старайтесь избегать аннотации &Вместо, так как она полностью подменяет код поставщика. Рассмотрим более безопасный вариант с использованием &После:
&НаСервере
&После("ПриСозданииНаСервере")
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Добавляем свою кнопку программно, чтобы не заимствовать форму целиком
НоваяКнопка = Элементы.Добавить("Расш1_КнопкаДействия", Тип("КнопкаФормы"), Элементы.КоманднаяПанель);
НоваяКнопка.Заголовок = "Дополнительная обработка";
НоваяКнопка.ИмяКоманды = "Расш1_КомандаДействия";
КонецПроцедуры
Такой подход позволяет минимизировать количество заимствованных объектов и снижает вероятность того, что форма «развалится» после обновления интерфейса в типовом релизе. Мы рекомендуем всегда добавлять уникальный префикс (например, Расш1_) ко всем создаваемым объектам и процедурам, чтобы избежать конфликтов имен в будущем.
Подводя итог, можно сказать: исполнитель не всегда лукавит, называя большие сроки для расширений. Это плата за сохранение «типового» статуса основной базы. Если ваша конфигурация уже снята с поддержки (даже для одной мелкой правки), экономический смысл делать все последующие доработки строго в расширениях часто исчезает. В таких случаях грамотнее вносить серьезные изменения в основную конфигурацию, следуя правилам «горизонтальной поддержки» (использование префиксов, вынос своего кода в отдельные модули), а расширения оставить для оперативных правок и временных решений.