Проанализируем частую ситуацию в практике разработчиков 1С: имеется типовая конфигурация, которая годами дорабатывалась путем внесения изменений непосредственно в основную конфигурацию поставщика. Возникает закономерное желание упростить процесс будущих обновлений, вырезав все свои доработки (сравнив с исходной типовой версией) и перенеся их в отдельное расширение. Разберем по шагам, как правильно подойти к этой задаче, какие инструменты использовать и каких архитектурных ошибок следует избегать.
Многие программисты надеются найти в стандартном Конфигураторе кнопку, которая автоматически сравнит две конфигурации, найдет все отличия и в один клик перенесет их в расширение. Выясним причину, почему это невозможно. Подход к доработке внутри конфигурации и доработке при помощи расширения принципиально отличаются. Конфигуратор не обладает инструментарием для автоматического рефакторинга кода, распределения объектов и связей. Если вы попытаетесь сделать это только средствами Конфигуратора, вам придется переносить каждый реквизит, каждую процедуру и каждую форму исключительно "руками", тщательно проверяя зависимости.
Более того, прямое копирование метаданных в расширение таит в себе множество подводных камней, начиная от проблем с производительностью и заканчивая риском потери данных пользователей.
Рассмотрим подробнее важнейший архитектурный принцип, который сформировался в сообществе 1С при работе с расширениями. Расширения данных (когда новые справочники, документы или реквизиты создаются прямо в расширении) имеют серьезный недостаток: если расширение по какой-то причине "слетит" после обновления платформы или будет случайно отключено/удалено администратором, все добавленные в нем физические таблицы в базе данных SQL будут безвозвратно уничтожены.
Чтобы избежать этого, применим гибридный метод:
МойПрефикс_НовыйРеквизит).Такой подход гарантирует, что даже при полном крахе расширения, данные пользователей останутся целыми в базе данных SQL. Также стоит помнить, что добавление реквизита в расширение создает дополнительную таблицу в SQL. Если раньше справочник состоял из одной таблицы, то с реквизитом из расширения системе придется неявно соединять уже две таблицы, что может привести к деградации производительности.
Посмотрим на современные инструменты, которые значительно облегчают процесс разделения конфигураций. То, что мучительно долго делать в Конфигураторе, гораздо проще реализовать в 1C:Enterprise Development Tools (1C:EDT).
Разберем основные преимущества использования EDT для нашей задачи:
Однако, будьте готовы к строгим проверкам. EDT проводит более жесткий синтаксический контроль. Проанализируем пример использования аннотаций в расширениях:
&ИзменениеИКонтроль("ОбработкаПроведения")
Процедура МойПрефикс_ОбработкаПроведения(Отказ, РежимПроведения)
#Вставка
// Ваш новый код проведения
#КонецВставки
// ... оригинальный код ...
КонецПроцедуры
При использовании директив #Вставка или #Удаление внутри сложных циклов или условных операторов, EDT может подсвечивать ложные синтаксические ошибки, так как анализирует код до этапа применения патча (в отличие от Конфигуратора). Это нормальное поведение, которое нужно учитывать при переносе кода.
Если вы всё же принимаете решение вынести существующий доработанный объект (например, справочник) из основной конфигурации полностью в расширение, или наоборот, перенести его в основную конфигурацию с новым именем/префиксом, вам предстоит работа с уже накопленными данными.
Рассмотрим два основных пути решения этой задачи:
1. Написание многопоточных обработок по замене ссылок:
Вам потребуется написать обработку, которая сначала скопирует сами данные из старого объекта в новый, а затем выполнит глобальный поиск и замену всех ссылок в базе данных. Для баз крупного размера (где количество ссылок может превышать миллионы) последовательная замена займет неприемлемо много времени.
Рекомендуется распараллеливать этот процесс с использованием фоновых заданий:
// Примерный концепт запуска фонового задания для замены ссылок
ПараметрыЗадания = Новый Массив;
ПараметрыЗадания.Добавить(МассивСтарыхСсылок);
ПараметрыЗадания.Добавить(НовыйОбъектСсылка);
РегламентныеЗадания.СоздатьРегламентноеЗадание("МойПрефикс_ЗаменаСсылокВФоне");
// Настройка и запуск...
2. Использование XML-выгрузки (Трюк с автозаменой):
Для быстрого переноса существующих документов вместе с их движениями по регистрам можно применить нестандартный подход. Выгрузите данные нужного периода с помощью стандартной обработки «Выгрузка/Загрузка данных в формате XML». Затем откройте полученный XML-файл в продвинутом текстовом редакторе, выполните массовую автозамену имени старого метаданного на новое (уже с префиксом) и загрузите файл обратно. Это позволит избежать написания сложного кода по переносу движений документов.
Наконец, проанализируем ситуацию после того, как вы успешно вынесли доработки в расширения. Главная боль разработчиков — это обновления типовой конфигурации поставщиком, которые ломают переопределенные в расширениях методы и формы.
Чтобы обновление не превращалось в ад из неожиданных ошибок, необходимо внедрять практики CI/CD. Создайте отдельные репозитории под конфигурацию поставщика и ваши расширения. Настройте пайплайн (например, с использованием GitLab CI и Vanessa Automation), который при каждом коммите нового релиза от поставщика будет автоматически собирать базу, накатывать ваши расширения и запускать автоматические дымовые тесты.
Только такой комплексный подход: правильная архитектура данных, использование мощных сред разработки (EDT) и автоматическое тестирование — позволит успешно вырезать доработки из "грязной" конфигурации и перейти на современный процесс разработки через расширения.