← На главную

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

Оптимизация архитектуры: разделение ответственности

Прежде чем внедрять инструменты, проанализируем архитектуру вашего решения. Часто конфликты захвата — это следствие нарушения принципа модульности.

1. Вынос логики: Старайтесь не писать бизнес-логику непосредственно в модулях объектов (справочников, документов). Используйте Общие модули. В объектах метаданных должны оставаться лишь «точки входа» — короткие вызовы функций из Общих модулей. Это снижает вероятность того, что двум разработчикам потребуется одновременно менять один и тот же объект.
2. Минимизация захвата: Придерживайтесь правила «чистого рабочего стола». Захватывайте объекты только на время написания кода. Если вы вынуждены держать объект захваченным долго — это повод разбить задачу на более мелкие итерации.

Использование методики разветвленной разработки

Если проект крупный, использование одного Хранилища для всей команды становится «узким горлышком». Рекомендуется применять подход с разветвленной разработкой, описанный в стандартах 1С:

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

Переход на Git: стандарт современной разработки

Для профессиональных команд переход на Git является наиболее эффективным решением. Хранилище 1С обладает рядом ограничений, которые Git нивелирует за счет механизмов веток и инструментов сравнения кода.

Рассмотрим этапы внедрения Git в разработку на 1С:

1. Выгрузка в файлы: Платформа 1С позволяет выгрузить конфигурацию в исходные файлы (формат XML/BSL). Используйте возможности платформы для автоматизации этого процесса.
2. Работа с ветками: Каждый разработчик работает в своей «ветке» (branch). Это физически исключает конфликты внутри одного репозитория, пока не придет время «слияния» (merge).
3. Прозрачность изменений: Вы всегда сможете увидеть, кто именно изменил конкретную строку кода и в рамках какой задачи (через комментарии к коммитам).

Регламенты и автоматизация процесса

Если вы продолжаете использовать Хранилище, сделайте процесс максимально прозрачным с помощью административных мер:

• Обязательное описание: Введите жесткое правило: при помещении изменений в Хранилище в комментарии обязательно указывается номер заявки из вашей системы учета задач (например, Jira или Redmine).
• Скриптование: Вы можете настроить проверку комментариев при помещении. Например, если в комментарии нет ссылки на задачу, Хранилище отклоняет операцию.
• Матрица ответственности: Закрепите за ключевыми объектами конфигурации ответственных разработчиков. Любое изменение в «критическом» модуле должно проходить обязательное ревью с ответственным за этот модуль специалистом.

Подводим итоги

Для обеспечения удобной разработки в большой команде следуйте этому алгоритму:

• Проведите рефакторинг кода: вынесите логику в Общие модули.
• Внедрите обязательную привязку коммитов/помещений к номеру задачи в системе трекинга.
• При масштабных задачах используйте отдельные «проекты-хранилища» для изоляции правок.
• Рассмотрите возможность перехода на Git с использованием инструментов для выгрузки конфигурации в файлы, что даст вам полноценный контроль версий и удобный инструмент для разрешения конфликтов при объединении кода.

Помните, что инструменты — это лишь способ реализации процессов. Основная задача команды — выстроить коммуникацию так, чтобы зоны ответственности разработчиков минимально пересекались, а каждое изменение имело понятную историю происхождения.