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

[ecto]

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

...веб сайт это приложение...
Тема к РНР не имеет прямого отношения, но очень важна.
Очень часто приложение разрабатывает один программист,
он сам занимается управлением и использованием ресурсов, отпимизацией и т.д.
Но как правило это программисты одиночки или небольшие фирмы.
Когда над одним приложением работают несколько программистов возникает ряд проблемм,
которые могут только увеличить время разработки.
Основные из них:
1 совместное использование одного ресурса
- например база данных
- у каждого свой способ работы с базой
- свой класс, библиотека
2 дублирование кода
- два программиста написали функцию делающую одно и тоже
- в одном проекте
3 понимание чужого кода
+ как правило решается соглашением
+ о названиях и комментариях
4 архитектура приложения
- предлагаютстя различные решения для одной проблеммы
- встает вопрос выбора и никто не хочет уступать

Отдел программистов столкнулся с этими проблеммами.
большинство из них были решены -

1 сели все вместе за один компьютер и написали свой класс работы с базой
2 Создали банк классов и функций со стандартом описания и гибким поиском.
прежде чем писать новую функцию - сначала ищешь ее в банке.
3 было взято готовое соглашение о кодировании
4 100 процентного решения не найдено
иногда это эксперимент на производительность,
иногда это простое логическое доказательство
или ссылка на готовое решение.

система программирования была выбрана eXtere Programming
с адаптированием под наши условия

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

 

[Фанат]

Большая часть перечисленных вопросов легко решается введением в эту разношерстную команду должности проджект-менеджера

 

[Krishna]

1. Должен быть единый на всех класс, с одним ответственным за его работу человеком.
2. Имхо, довольно редкий случай, если они занимаются разными частями пректа. Иначе, это результат неправильного сегментирования задачи руководителем проекта.
3. Есть же общепринятые стандарты
4. Такие ситуации должен разрешать тот же рукводитель проекта (прожект-менеджер)

В общем, действительно, Фанат прав - похоже у вас его просто нет

 

[Ilya Bous]

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

 

[jonjonson]

При работе над любым сайтовым php проектом я бы выделил следующие задачи:
- взаимодействие с клиентом по поводу проекта и создание ТЗ;
- разработка архитектуры приложения (это самое критичное и к этому не допускается клиент);
- разработка дизайна;
- прототипирование и верстка;
- разработка API;
- кодинг;
- тестирование;
- документирование.

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

При этом стоит придерживатся одинаковых правил оформления кода и документирования.

Необходимо воспользоватся системой ведения версий кода.

 

[Johannes]

1. Нащет РМ-а Фанат прав как всегда (почти )
2. Если грамотно разработан дизайн и архитектура проекта – никаких вышеописаных проблем быть не может.
3. Разделять и еще раз разделять. это о MVC. Тоесть: работа з данными, бизнес-логика и вывод должны быть максимально независимыми.
4. Использование CVS и CASE-систем для управления проектом. Для РНР есть замечатльная вещь: Sparx Enterprise Architect.

 

[Raziel[SD]]

Johannes

Для РНР есть замечатльная вещь: Sparx Enterprise Architect.

чем она замечательна для PHP ?

 

[Johannes]

1. С помощью ЕА можно управлять всем цыклом разработки ПО.
2. UML 2.0
3. Поддержка РНР4 для реинжениринга и генерации кода.
4. Поддержка контроля версий.
5. Встроеный документатор
и моного другого.
Детально смотри на www.sparx.com