Надеюсь, я смогу вам немного помочь, или, по крайней мере, покажу вам правильное направление!
Тем не менее, это небольшой отказ от ответственности, это огромная тема, и я думаю, что для ее глубокого понимания требуется « вбрасывание ». Тем не менее, я дам краткий обзор двух основных вопросов:
- Код и контроль исходного кода
- Коммуникации и некоторые советы.
Что касается проектов ООП конкретно - я, честно говоря, не вижу слишком много проблем, специфичных для ООП, которых нет в других местах.
На самом деле, я думаю, что программирование в стиле ООП невероятно подходит для командной разработки. Одним из ключевых принципов ООП является то, что я не должен знать все детали о каждом объекте, с которым я взаимодействую: мне просто нужно знать, что он может сделать, и как я могу заставить его это сделать.
Абстракции, которые может предоставить ООП, потрясающие в команде.
Управления источником
Должно быть центральное место для хранения проекта, и это позволяет нескольким разработчикам одновременно получать доступ к базе кода. Это где системы, такие как Git (или SVN) вступают в игру.
Я могу говорить только о Git, поскольку я никогда не использовал SVN - однако я понимаю, что они похожи, но с другой терминологией.
Используя Git, я могу создать репозиторий со всем исходным кодом для данного проекта, а затем разрешить моей команде доступ к репозиторию. Для каждой выполняемой функции или исправления ошибки отдельные разработчики могут создавать свои собственные «ветки», что означает, что разработка может происходить параллельными путями.
Как только функция или исправление завершено, их можно « объединить » обратно с базой кода основного проекта. Любые « конфликты » могут быть обнаружены Git и разрешены ответственным разработчиком на исходном уровне.
Я не уверен, что вы использовали Git раньше, но на первый взгляд он может показаться довольно сложным, но благодаря его недавней популярности (отчасти Github ) существует множество учебных пособий и ресурсов.
Если вы не использовали его раньше, то я рекомендую зарегистрироваться на GitHub и почувствовать это таким образом! (В качестве альтернативы, Bitbucket является аналогичной альтернативой, но она позволяет вам иметь частные репозитории бесплатно.)
Git Flow - это отличный рабочий процесс на основе Git, который невероятно полезен для команд. Как и Git в целом, после того, как вы поработаете с ним какое-то время, трудно представить, что вы работаете в команде без него!
связи
Как только вы преодолеете все технические барьеры, вы действительно дойдете до фундаментальной проблемы, которая преследует большинство проектов (технических или нет) - и это общение.
Вся команда должна знать, кто что делает, когда это делает и на что это влияет.
Ответственность должна быть четко определена
Это очевидно, но большинство проектов будут использовать какую-то форму системы тикетов - где регистрируются какие-либо запросы на функции или ошибки, а затем назначаются конкретному сотруднику. ( JIRA , Unfuddle и т. Д.) Часто они встроены в систему управления источниками, что делает жизнь немного проще. (BitBucket и GitHub оба обеспечивают отслеживание проблем для репозиториев Git, размещенных с ними.)
Это останавливает или помогает предотвратить, по крайней мере, разработчиков, случайно работающих над теми же проблемами.
Это не полное исправление, хотя; вам все еще нужно убедиться, что разработчики знают о других обязанностях разработчиков. В прошлом я знал, что исправил другие проблемы, с которыми столкнулся в ходе исправления конкретной ошибки, просто потому, что это имеет смысл. (« Ну, я уже здесь. Это может быть связано с рефакторингом, и, возможно, я смогу проверить любые другие проблемы». ) Затем мне пришлось извиниться перед другими разработчиками, когда они работали над теми другими проблемами, которые я исправлено - трата нашего времени.
В общем те, эти проблемы могут быть исправлены ...
Регулярные встречи
Некоторые методологии управления проектами / разработки диктуют конкретные методы коммуникации или интервалы встреч. В целом, наиболее продуктивными системами, которые я видел, были утренние встречи в режиме ожидания, когда все в команде быстро расскажут о том, что они делают, - если вы ограничитесь этим только для членов команды разработчиков и будете иметь четкие рекомендации по общаться тогда они могут быть невероятно эффективными. Я всегда старался придерживаться:
Я работаю над X,
Чтобы достичь / исправить Y,
Что включает в себя изменение / исправление Z.
Другие члены команды могут сразу понять, что « Фергус работает над исправлением той ошибки, которая была зарегистрирована на днях, однако это означает, что он работает над некоторым кодом, на который мне нужно обратить внимание - я проверю его, прежде чем вносить какие-либо изменения». ».
Архитектурные встречи
Недавно я работал с отличной командой, которая проводила двухнедельный « технический чат », где обсуждались более крупные / архитектурные вопросы. У каждого члена команды было время, чтобы понять более крупные проблемы, стоящие перед проектом, и могли обсудить возможные исправления.
Лично мне это нравилось, я не вносил большой вклад, так как был довольно новым для проекта - но возможность слушать дискуссии дала мне много понимания; довольно скоро я смог понять проект, а также индивидуальные стили мышления.
Коммуникация - это единственная проблема, которая может сломить любую команду. Технически или нет, если люди не знают об общей картине, тогда есть большая вероятность, что они потерпят неудачу.
Другие вопросы
Хорошо, чтобы у всех была одинаковая конфигурация или стиль при работе в команде. Что я имею в виду?
конфигурация
Если вы работаете над проектом Java, то может быть хорошей идеей является обеспечение (по крайней мере для сред разработки, конечно, не для тестирования) версий JVM среди команды? Тогда IDE. В основном это помогает, если вся команда использует Eclipse или NetBeans или предпочитаемую вами IDE.
В веб-проекте может быть так, что всем разработчикам нужен определенный стек; с конкретными версиями Apache или PHP .
Размышление о таких факторах просто позволяет команде «склеиться» немного быстрее.
Стиль
Вкладки против пробелов? CamelCase или spacing_with_underscores? Как бы ни были эти вопросы, когда вы работаете в одиночку, когда вы работаете с большой командой, вы действительно хотите стремиться к общему стилю.
На самом деле, вы не должны знать, кто написал конкретный раздел кода - вы просто должны знать, что он принадлежит .
Вот почему многие проекты с открытым исходным кодом открыто публикуют рекомендации / руководства по стилю в формате исходного кода - чтобы понять, что они содержат, взгляните на Google StyleGuides для своих собственных проектов с открытым исходным кодом.
Задачи и юнит-тесты
Это не ограничивается командами, но я собираюсь быстро коснуться этого по одной конкретной причине: это делает командную жизнь намного проще.
Если у вас сложный рабочий процесс с множеством зависимостей или длительный процесс сборки - тогда часто бывает полезно автоматизировать это с помощью обработчика задач. Для веб-проектов GruntJS великолепен, хотя, исходя из Java, я думаю, Apache Ant может быть очень похожим.
Как частное лицо, я использую GruntJS для создания своего сайта перед его развертыванием на своем FTP-сервере - одна команда Grunt - это все, что мне нужно для компиляции и минимизации моего CSS / Sass, сжатия моих ресурсов и загрузки файлов.
Однако, как член команды, я могу использовать GruntJS, чтобы проверить, что я не сломал ни одного теста - и что я не внес никаких ошибок, не зная полностью о других частях проекта. Это, конечно, в дополнение к преимуществам, которые он дает мне как индивидуальному разработчику.
Я также могу использовать его, чтобы клонировать проект с помощью моего необычного пакета управления версиями (Git) - и запустить одну команду, чтобы установить все мои зависимости. Это большой плюс, поскольку время, затрачиваемое на то, чтобы привести нового разработчика в положение, в котором он действительно может начать разработку, может быть довольно большим - даже без учета времени, которое требуется, чтобы привыкнуть к незнакомой базе кода.
Документация
У лучших проектов, которые я видел, была документация (и часто довольно чрезмерная), предназначенная для разработчиков. Этот вид документов может объяснить такие вещи, как:
1. Среда разработки:
«В настоящее время мы выполняем развертывание на сервере со стеком LAMP , поскольку такие разработчики должны ориентироваться на версии, указанные в…»
2. Рабочий процесс
«Все функции должны быть разработаны в ветке« feature / * »и объединены с веткой« testing »до того, как они будут считаться готовыми к выпуску».
3. Обязанности в команде:
«По вопросам базы данных поговорите со Стивом. По вопросам платформы поговорите с Дэвидом».
4. « Трубопровод » на будущее
«При разработке нового кода помните , что по состоянию на июнь 2014 года мы хотим реализовать й - унаследованный код , возможно , придется пересмотреть , прежде чем это произойдет.»
Примеры
Возможно, стоит взглянуть на рабочий процесс проекта с открытым исходным кодом, чтобы понять, как он работает - будь то установленный проект со своим собственным рабочим процессом (часто тщательно документированным) или один из многих примеров на GitHub.
Последнее слово предупреждения
Если вы нашли себя , работая в команде , которая управляет , чтобы сделать все это право .. вы будете ненавидеть быть где - нибудь еще ..! Возьмите это от меня, как только у вас появится хорошая команда, внезапно проблемы в другом месте действительно могут затянуть вас. (Это история для другого поста!)