Работа в крупной компании над стандартной конфигурацией, такой как 1С:Зарплата и управление персоналом (ЗУП), накладывает серьезные требования к организации процесса разработки. Когда в команде более трех программистов, классический подход «один разработчик — одно расширение» перестает работать и превращается в источник постоянных конфликтов, потерь кода и сложностей при обновлении релизов. Разберем подробно, как перестроить процессы, чтобы масштабировать команду без потери качества.
Проанализируем ситуацию, когда за каждым программистом закреплено отдельное расширение. На первый взгляд это кажется удобным: каждый отвечает за свой участок кода. Однако на практике мы сталкиваемся с критическими минусами:
Рассмотрим более правильную архитектуру. Вместо персонализации расширений внедрим разделение по функциональным блокам или проектам. Проанализируем, как это реализовать:
Разделим все доработки на логические группы, например:
При таком подходе программисты работают не в «своих» расширениях, а в тех, которые соответствуют решаемой задаче. Это позволяет избежать дублирования заимствованных объектов и упрощает понимание структуры системы.
Выясним, как технически обеспечить одновременную работу нескольких человек над одним расширением. Начиная с версии платформы 8.3.13, реализована поддержка Хранилища конфигурации для расширений.
Для каждого расширения создается свое отдельное хранилище. Процесс работы выглядит следующим образом:
НачислениеЗарплаты).Это исключает ситуацию, когда два человека одновременно меняют один и тот же код в рамках одного расширения, и позволяет отслеживать историю изменений по каждому сотруднику. Важно: если объект захвачен одним разработчиком в одном расширении, это не блокирует его захват в другом расширении, поэтому архитектурный контроль со стороны ведущего разработчика остается необходимым.
Разберем самый болезненный вопрос: как накатывать новые релизы ЗУП, если расширение общее? В ситуации с 5–10 разработчиками ручное тестирование становится невозможным. Рассмотрим стратегию автоматизации:
1. Назначение ответственного (Релиз-менеджера): Выделим самого опытного сотрудника, который будет курировать процесс обновления. Его задача — не править код за всеми, а координировать исправления.
2. Внедрение автотестов: Посмотрим в сторону инструментов сценарного тестирования, таких как Vanessa Automation. Подготовим набор «дымовых тестов», которые проверяют базовую работоспособность (открытие форм, проведение документов) после наката нового релиза. Это позволит мгновенно выявить, в каком блоке произошел сбой.
3. Использование аннотаций: Проанализируем использование &Вместо. Это самая опасная аннотация при обновлениях. В командной разработке постараемся максимально использовать &Перед и &После. Использование &Вместо должно быть разрешено только в исключительных случаях с обязательным Code Review.
Если штат разработчиков продолжает расти, рассмотрим переход на 1C:EDT (Enterprise Development Tools). Это позволит отказаться от классического Хранилища в пользу Git. Проанализируем преимущества этого подхода:
Для поддержания порядка в общем коде введем жесткий регламент комментирования. Разберем пример оформления доработок в общих модулях расширения:
// + ИмяРазработчика_Задача_123_Начало
// Описание: Добавление расчета надбавки за выслугу лет
Процедура РасчитатьНадбавку()
// Логика доработки
КонецПроцедуры
// - ИмяРазработчика_Задача_123_Конец
Такая разметка позволяет быстро найти ответственного за конкретный участок кода, даже если расширение стало «общим». Также это значительно упрощает визуальный поиск изменений при сравнении модулей во время обновления конфигурации.
Выясним, влияет ли количество расширений на скорость работы ЗУП. Платформа 1С:Предприятие компилирует все расширения в единый слой при запуске сеанса. Основное замедление может происходить на этапе инициализации (запуска программы). Чтобы минимизировать риски:
Сотрудники, если вам нужно только изменить заголовок формы.Подводя итог, отметим, что ключ к успешной командной работе в ЗУП — это стандартизация. Переход от модели «личного владения кодом» к коллективной ответственности через общие расширения и хранилища — единственный путь к стабильной и поддерживаемой системе.