Коллективная разработка.

  Представим себе, что над одним проектом работает небольшая команда разработчиков. Для того, чтобы не мешать друг другу, и случайно не удалить результаты чужого труда, им необходимо как-то координировать свои действия. Для этого желательно использовать хорошую систему контроля версий (например, CVS, Perforce, ClearCase). Однако такие системы либо требуют значительного времени на их изучение, либо стоят довольно дорого; либо и то, и другое.

  При работе над небольшим проектом очень удобно использовать ZSKSoft Synchronizer. В нем отсутствует большинство специальных возможностей, характерных для систем такого рода (поддержка ветвей, меток и т.д.), и поэтому работать с ним легко и просто. Не надо тратить дополнительное время на изучение: все достигается штатными средствами ZSync; модель работы простая и понятная; поэтому конечная цель достигается быстро и с минимумом затрат.

У каждого разработчика есть личная копия проекта, с которой он работает; и есть общая копия, расположенная на сервере, или просто на общем ресурсе одного из компьютеров. Например:

Разработчик1             Разработчик2            Общая копия
  BACKUP                  BACKUP                  исходные файлы
  TEST                    TEST1
  исходные файлы          TRASH
  промежуточные файлы     исходные файлы
  готовое приложение      промежуточные файлы
                          готовое приложение

  У каждого разработчика есть личная копия исходных файлов. Кроме этого, разработчики могут создавать в своей копии проекта дополнительные подкаталоги - для резервного копирования, тестовых наборов данных, и прочих других целей, не всегда поддающихся внятному описанию. Такие подкаталоги нередко возникают для какой-нибудь сиюминутной надобности, и после этого на всякий случай остаются навсегда  - вдруг эта надобность возникнет еще раз.

  В процессе работы разработчик что-то изменяет в своих исходных файлах, затем собирает готовое приложение (при этом образуются промежуточные файлы - .dcu, .obj и им подобные), и проверяет, как это готовое приложение работает. Убедившись, что оно работает правильно, разработчик публикует свои изменения в общую копию. Кроме того, он забирает из общей копии исходные файлы, которые публикуют другие разработчики; эти файлы нужны ему для работы и для сборки приложения.

  Свои файлы разработчик копирует из личной копии в общую, чужие наоборот - из общей копии в личную. Кроме того, часто бывает, что в некоторые файлы могут вносить изменения несколько разработчиков. Например, это может быть модуль с общими функциями, у которого нет четкого владельца - кому понадобилась новая функция, тот ее и добавил; либо модуль состоит из нескольких частей, принадлежащих разным авторам; либо у этого модуля несколько владельцев, в соответствии с модной сейчас методологией экстремального программирования. Такие файлы могут копироваться в обе стороны: если разработчик что-то в нем исправил, то надо будет скопировать в общую копию; а если исправил кто-то другой (изменился файл в общей копии), то надо будет скопировать к себе, в личную копию. Ну а если файл изменился и там, и там, надо об этом просигнализировать, и ничего не делать, ждать, пока разработчики разберутся между собой.

  Дополнительные подкаталоги, промежуточные файлы и готовое приложение никуда не копируются.

  На рисунке изображен пример экрана ZSync одного из разработчиков. Как видите, все выглядит так-же, как обычно, за одним исключением: в категориях по-именам появились дополнительные закладки (мои, чужие и совместные). Благодаря этому разработчик может отдельно контролировать синхронизацию своих файлов, чужих, и разрабатываемых совместно с коллегами. И настроить им отдельные потоки для изменений:

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

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

  Первоначально пример проекта включал в себя еще несколько подкаталогов, и, в результате, приходилось каждый раз делать оговорки: "исходные файлы и/или содержимое подкаталогов, относящихся к общей части проекта..." Текст получился слишком громоздкий, и подкаталоги из примера пришлось убрать, оставив только исходные файлы. Но, разумеется, ZSync так же легко синхронизирует проекты и с любой вложенностью подкаталогов, надо просто не убирать их в "игнор".

  Каждый из разработчиков собирает свою копию готового приложения, но эта рабочая копия, в нее входят модули, которые еще не опубликованы, т.е. не не протестированы разработчиком до конца. Для того, чтобы в любой момент можно было собрать "товарное" приложение, полезно завести еще одну копию проекта, специально для сборки; и с помощью отдельной схемы копировать в нее исходные файлы из общей копии. Копию для сборки можно разместить на компьютере разработчика, которому это поручено, или на общем ресурсе, чтобы собрать окончательный вариант приложения мог любой из разработчиков. Разумеется, можно делать сборку непосредственно в общей копии; недостатки этого варианта чисто эстетические: общая копия загромождается промежуточными файлами, их надо игнорировать при настройке резервного копирования, и т.д. В общем, это дело вкуса.

  Для того, чтобы коллективная разработка протекала гладко, эффективно и без накладок, самое главное - это вовсе не программное обеспечение, а организационные мероприятия. Иначе говоря, надо прежде всего стараться правильно распределять участки работы между разработчиками. Это не такое простое дело, как может показаться на первый взгляд: необходимо учитывать, что у разработчиков, специализирующихся на какой-то технологии (например, ввод данных, отчеты, коммуникации и т.д.), выше производительность - но с другой стороны, "многостаночники" имеют более широкий кругозор; есть и  много других факторов, которые в двух словах рассмотреть невозможно. ZSync легко решает задачу распределения модулей, даже слишком легко, позволяя пустить процесс на самотек - но пусть эта легкость не ввводит Вас в заблуждение. Не забывайте приложить хотя бы минимальные усилия для организации работы.