Вопрос 7. Групповая разработка, управление версиями

Управление версиями:

Visual Source safe, PVCS….

Храним версии в едином репозитории. Для уменьшения пространства можно применять иерархическую структуру версий и хранить только отличающиеся файлы.

Применяем операции CheckOut (берем файл из репозитория и монополизируем доступ к нему до окончания процесса исправления), CheckIn (возвращает измененный файл в репозиторий).

//Замечание:

Для предотвращения ситуации, когда разноверсионные модули одного и того же приложения работают с разными типами (разметками) данных, эти разметки тоже необходимо хранить в репозитории, а модулям назначать CRC. Доступ к данным при записи/чтении можно монополизировать, но это может грозить приостановкой работы всего приложения (особенно если используется единая БД, ибо придется строить транзитивное замыкание графа процессов и ресурсов, с которыми они работают, которое может охватить все ресурсы.). Решение – разбить программу на объекты, которые содержат как данные, так и код, общение между объектами (запрос данных) – при помощи сообщений. Каждый объект может разрабатываться независимо от других, следовательно возможна групповая разработка. //Проблема – посылка сообщения – трудоемкая операция, но можно выстроить объекты в конвейер.

Вопрос 8. Организация коллектива разработчиков.

Иерархическая: проблема – интерфейсы, комплексная отладка занимает много времени, теряется время на коммуникацию (осуществляется через верхние уровни), теряется смысл сообщений. Минус: все решения принимаются одним человеком, но он может заблуждаться, может знать меньше.

Ядро: один пишет прототип, потом из него возникает продукт. Проблема: сложен переход.

Матричная модель: в ней есть узкие специалисты, которые заняты сразу в нескольких проектах.

Проблема – люди зацикливаются на своей работе, структуризация продукта, не все могут быть одинаково загружены.

"Хирургическая" схема: главный "хирург", зам. гл. "хирурга", подмастерья (документатор, специалист по оптимизации, менеджер). Работает для небольших комплексов, для больших проектов – плохо.

+: нет проблемы согласования, программа получается концептуально целой и грамотной

-: увеличение рисков, все хотят быть главными хирургами, но не подмастерьями.