Для начала давайте обсудим, что представляет собой групповая разработка обменов с использованием конвертации данных 2.1. Мы имеем в виду опыт, полученный на одном из наших проектов в процессе начального переноса данных из 1С:УПП в 1С:УСО. С какими основными проблемами мы столкнулись?
Когда разрабатывается правило конвертации, оно становится достаточно сложным и состоит из множества элементов, блоков и модулей. Когда над ним работают несколько программистов, существует риск того, что не будет соблюдаться единая стилистика и не будут достигнуты общие цели технического решения. Именно поэтому на проекте обязательно должен быть технический руководитель, который будет следить за этим процессом и помогать разработчикам в случае необходимости.
Часто в разных правилах конвертации используются одни и те же приемы и алгоритмы. Чтобы избежать их дублирования и различных интерпретаций, необходимо уделять особое внимание выделению общедоступных и общеизвестных элементов и блоков для их использования. Иначе разные разработчики могут создавать автономные алгоритмы для одного и того же механизма, что приведет к различиям в реализации и повышению риска ошибок. Это, в свою очередь, усложняет и удорожает поддержание актуальности правил конвертации и их безошибочную работу. Поэтому на проекте снова требуется кто-то, кто будет следить за этими техническими аспектами и минимизировать разногласия между участниками.
Следует отметить, что правила конвертации представляют собой совокупность взаимосвязанных объектов и сущностей. Например, если выгружается какой-то документ, у него может быть множество реквизитов, таких как контрагент, договор и организация. Эти же реквизиты присутствуют и в других документах, правила конвертации которых разрабатывают другие программисты. В результате возможна ситуация, когда правила конвертации одного свойства, созданные одним программистом, не удовлетворяют потребностям другого при работе над другой задачей.
Как это может проявляться? Например, если в документе заполняется реквизит договора, разработчик, заполняя это свойство, проверяет наличие уже разработанных правил конвертации для него. Однако существует опасность, что правила, созданные одним разработчиком, могут не удовлетворить требования другого, и он попытается внести в них изменения. Разработчик, разрабатывающий правила конвертации документа, может увидеть уже существующие правила для конвертации договоров и использовать их в своих правилах. Но в результате договор, созданный по этим правилам, может оказаться не подходящим для разработчика.
Поэтому я считаю, что при групповой разработке необходимо придерживаться правила: если существующие правила конвертации, используемые в вашей задаче, вас не устраивают, то один разработчик не должен вносить изменения в правила, разработанные другим. В таком случае нужно создать копию или параллельно разработать другие правила конвертации, подходящие для конкретной задачи. Это позволит избежать ошибок, вызванных изменениями в правилах, разработанных другими разработчиками, и избежать ошибок при конвертации.
При обычной групповой разработке, когда мы работаем с кодом конфигурации, такие ситуации, как правило, исключены. Или, по крайней мере, по коду обычно видно, где используются какие алгоритмы, и проще проанализировать последствия их доработки.
В правилах конвертации всё не так просто. Многие модули и правила используются в различных других модулях, поэтому если какой-то функционал должен отличаться, необходимо создать другие правила, чтобы не нарушать работу других разработчиков.
Особенность разработки правил конвертации заключается в том, что она ведётся в отдельной конфигурации. Это, по сути, такая же база данных, как и база данных, с которыми работают наши клиенты и заказчики. Однако информация, содержащаяся в ней, представляет собой набор правил конвертации. Это накладывает свои ограничения. Разработка не может вестись, как в случае с обычной разработкой, с использованием различных систем конвертации. Отслеживание версий, таких как расширение конфигурации через Git, также может вызвать проблемы. И возможно, доработки разных программистов потребуют изменения одних и тех же объектов. Хотя такое случается нечасто, но вероятность всё же существует.
Поэтому на это тоже стоит обратить внимание. Технический руководитель проекта должен распределять работу между программистами таким образом, чтобы минимизировать пересечение объектов правил конвертации между задачами над ними.
