Совместная разработка приложений

Создать простую прикладную настройку по силам одному человеку, но рано или поздно вы приступите к решению задач, которые потребуют одновременного участия нескольких разработчиков. Ниже приводится список правил, следование которым позволит существенно снизить трудозатраты при совместной разработке, избежать путаницы и непроизвольных потерь макросов и данных.

• Первое правило относится не только к проектам на платформе Гедымин, а является общим для любого проекта по созданию программного обеспечения. Перед началом кодирования вы должны иметь четкое представление о том, что должно получиться на выходе. Совместно с заказчиком составьте подробное техническое задание. Исходя из него, разработайте принципиальную схему будущей программы. Из каких модулей она будет состоять? Какие структуры данных потребуются? Как будет осуществляться взаимодействие между модулями? Как будет организован пользовательский интерфейс? Какие выходные формы потребуются?

  Имея на руках подробную документацию, вы будете в состоянии разбить весь объем работ на отдельные задания и распределить их среди членов команды. Назначьте регулярное совещание для того, чтобы отслеживать ход выполнения проекта.

• Выберите префикс для своего проекта. Используйте этот префикс в наименованиях объектов базы данных, макросов, отчетов и т.п.
• Если в разработке принимает участие несколько человек, то важно избежать путаницы, которая может возникнуть, когда два разработчика присвоят своим объектам одинаковые наименования. Как правило, в большом проекте, каждый из программистов трудится над своей подсистемой. В таком случае, можно предложить использовать свой префикс для каждой из подсистем. Таким образом, имя объекта будет иметь два префикса: сначала — префикс проекта, затем — подсистемы. Например, если для разрабатываемого проекта был выбран префикс X_, а для подсистемы — Y_, то функция AddParam, логически относящаяся к указанной подсистеме, получит полное имя X_Y_AddParam.
• Каждый разработчик должен работать со своим экземпляром базы данных.
• Объекты, разрабатываемые одним разработчиком, должны группироваться в одну или несколько настроек. Эта настройка (настройки) может зависеть от других настроек, в том числе и созданных другими разработчиками, но не должна включать объекты, над которыми работают другие разработчики.
• Рекомендуется имена файлов настроек, относящихся к одному проекту, начинать с имени этого проекта. Например, «Зарплата и Кадры. Метаданные.gsf», «Зарплата и Кадры. Макросы.gsf». Зачем? Когда на базе данных загружено несколько проектов, список настроек в соответствующем окне может содержать десятки и даже сотни позиций. Правильное именование файлов, позволит легко сгруппировать настройки, относящиеся к одному проекту, просто упорядочив их список по имени.
• Для упрощения процесса загрузки настроек на эталонную базу данных следует создать пакет и указать связи между зависимыми настройками.
• По выполнении определенного объема работ, все разработчики должны сформировать свои настройки и сохранить их на диске. Рекомендуется использовать систему контроля версий, например, Borland StarTeam, для хранения истории изменения настроек.
• Следует постоянно контролировать, чтобы, во-первых, в настройки попадали все необходимые объекты, а во-вторых, чтобы не возникало конфликтов, между объектами, созданными разными разработчиками. Для осуществления контроля рекомендуется периодически выполнять следующее:
  • Загрузить на чистую, эталонную базу данных последние версии всех настроек;
  • Заменить полученной таким образом базой рабочие базы у всех разработчиков. Перед заменой, каждый разработчик должен создать архивную копию своей базы!
  • Если в процессе дальнейшей работы выяснится, что какой-то объект не попал в настройку, то следует восстановить базу из архивной копии, включить объект в настройку, переформировать ее и сохранить в файле. Повторить все действия, начиная с пункта а).
• Если вам необходимо передать базу данных клиенту или к вашей команде присоединился еще один разработчик, у вас может возникнуть соблазн скопировать одну из существующих рабочих баз. Никогда не делайте этого! Возьмите чистый эталон и загрузите на него последние версии ваших настроек.
• Каждая база должна иметь свой уникальный идентификатор — DBID. Если вам необходимо получить копию базы, то добиться присвоения нового уникального кода можно:
  • Создав архивную копию базы и выполнив затем восстановление из архива с установленным флагом «Присваивать уникальный ИД базы»;
  • Подключиться к базе данных, открыть окно «SQL редактора» и с помощью команды «SET GENERATOR GD_G_DBID TO 0» присвоить значение 0 генератору. Новый уникальный идентификатор будет присвоен базе данных при следующем подключении к ней.
• После того, как вы начнете, бета-тестирование проекта, часто будет возникать ситуация, когда изменения, сделанные на клиентской базе данных, необходимо перенести в настройки проекта. В таком случае рекомендуется поступать следующим образом:
  • Макросы, отчеты и структуры данных, измененные или созданные на клиентской базе, включаются в отдельную временную настройку;
  • Эта настройка формируется и сохраняется в файле;
  • На той базе данных, на которой ведется разработка, настройка загружается и активизируется;
  • Объекты, перенесенные с помощью временной настройки, включаются в настройки проекта, после чего она удаляется из списка;

04.07.2005