← На главную

В процессе разработки программных решений на платформе 1С часто возникает необходимость одновременной работы нескольких специалистов над одной и той же конфигурацией или конкретным объектом метаданных (справочником, документом, обработкой). Стандартным инструментом для коллективной разработки является Хранилище конфигурации. Однако бывают ситуации, когда его использование невозможно или ограничено. Проанализируем ситуационную задачу и выясним, какие существует практические способы организации параллельной работы в таких условиях.

Почему нельзя редактировать один объект в одной базе двумя Конфигураторами

Прежде чем рассматривать решения, разберем ситуацию с прямым подключением двух Конфигураторов к одной информационной базе. Платформа 1С не предназначена для одновременной интерактивной правки структуры метаданных или программных модулей одной БД двумя разработчиками без захвата объектов в Хранилище.

Если два специалиста одновременно откроют один и тот же модуль объекта или форму в одной базе, то при сохранении произойдет перезапись изменений. Версия разработчика, который нажмет комбинацию клавиш для сохранения (или вызовет обновление конфигурации БД) последним, перекроет правки первого разработчика. Механизм автоматического слияния (merge) в обычном Конфигураторе при таком подходе отсутствует. Кроме того, одновременное изменение структуры базы двумя сессиями может привести к технологическим сбоям и разрушению метаданных.

Разработка в изолированных базах с последующим объединением

Рассмотрим наиболее распространенный на практике подход, когда Хранилище конфигурации не применяется. Он заключается в разделении среды разработки на отдельные информационные базы и последующем контролируемом слиянии результатов.

Разберем по шагам схему организации процесса:

1. Подготовка рабочих копий: Создаются две независимые копии рабочей информационной базы (или базы разработки). Каждый программист работает в своей локальной или серверной базе.
2. Изолированное внесение изменений: Первый специалист вносит изменения в одну часть объекта (например, пишет алгоритмы в модуле объекта), а второй специалист редактирует другую часть (например, дорабатывает модуль формы или логику в модуле менеджера).
3. Выгрузка результатов: По завершении работы оба разработчика выгружают конфигурации в файлы с расширением .cf (или сохраняют дорабатываемые внешние обработки/отчеты).
4. Слияние в эталонной базе: Используется отдельная техническая база для слияния. В ней поочередно выполняется стандартная операция «Конфигурация — Сравнить, объединить с конфигурацией из файла».
5. Разрешение конфликтов: Ответственный специалист (или сами разработчики) с помощью штатного окна сравнения и объединения 1С визуально анализирует различия в модулях и формах, выставляет флаги для объединения нужных процедур и функций, после чего обновляет конфигурацию БД и передает итоговый файл .cf в рабочую базу.

Архитектурное разделение доработок

Проанализируем ситуацию, когда необходимо свести к минимуму пересечения программистов в одном программном модуле. Для этого применяются архитектурные методы платформы 1С:

1. Использование расширений конфигурации (ПОД)
Вместо изменения объекта непосредственно в основной конфигурации, один из программистов (или оба) создает отдельное расширение. В расширении можно заимствовать форму или сам объект, а доработку программного кода вынести в аннотации перехвата: &Перед, &После или &Вместо. Расширения хранятся и обновляются независимо от основной конфигурации, что полностью исключает блокировку объекта.

2. Использование подписок на события
Если обоим программистам требуется добавить обработку событий объекта (например, при проведении документа или перед записью справочника), код не обязательно писать в самом модуле объекта. Создаются две независимые Подписки на событие. Каждая подписка связывается со своим отдельным ОбщимМодулем, который редактируется конкретным разработчиком. В результате модуль объекта остаётся нетронутым.

3. Декомпозиция логики в общие модули
Вся сложная алгоритмическая часть выносится из модуля объекта во внешние или общие модули. В самом объекте остаются лишь минимальные вызовы соответствующих функций.

Применение среды 1C:EDT и систем контроля версий (Git)

Посмотрим на современный стек разработки 1С. При использовании среды 1C:Enterprise Development Tools (1C:EDT) вся конфигурация хранятся на диске в виде текстовых исходных файлов (код в файлах .bsl, метаданные и формы в формате XML).

Это позволяет организовать параллельную работу следующим образом:

1. Оба программиста создают свои функциональные ветки (branches) в репозитории Git.
2. Каждый специалист редактирует один и тот же файл программного модуля .bsl в своей ветке.
3. При объединении веток система контроля версий проводит автоматическое текстовое слияние. Если строки кода не пересекаются, изменения объединяются без участия человека. При пересечении строк возникший конфликт разрешается вручную в текстовом редакторе или визуальном инструменте сравнения.

Организационные методы: парное программирование

Если задача по объекту имеет высокую сложность и требует немедленного совместного решения двух специалистов без применения сложного инструментария, применяется методика парного программирования. Оба разработчика работают за одним рабочим местом (или в режиме совместного просмотра экрана): один пилот непосредственно пишет код, а второй штурман анализирует архитектуру, ищет ошибки и предлагает оптимальные решения. Это исключает необходимость одновременного редактирования файлов с разных устройств.