Как работает работа в команде (в ОО-проекте)? [закрыто]

Я сам программирую на Java, в очень оригинальном стиле. Никогда не было возможности работать с другими программистами (по крайней мере, я не профессионал).

Из любопытства я хотел спросить: как работает работа с командой над проектом, особенно при работе над ОО-проектом?

Как работает разделение задач? Как вы разрабатываете что-то, что будет успешно работать с тем, что разработал другой программист? Как и когда общаются программисты?

Благодарность

Надеюсь, я смогу вам немного помочь, или, по крайней мере, покажу вам правильное направление!

Тем не менее, это небольшой отказ от ответственности, это огромная тема, и я думаю, что для ее глубокого понимания требуется « вбрасывание ». Тем не менее, я дам краткий обзор двух основных вопросов:

1. Код и контроль исходного кода
2. Коммуникации и некоторые советы.

Что касается проектов ООП конкретно - я, честно говоря, не вижу слишком много проблем, специфичных для ООП, которых нет в других местах.

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

Абстракции, которые может предоставить ООП, потрясающие в команде.

Управления источником

Должно быть центральное место для хранения проекта, и это позволяет нескольким разработчикам одновременно получать доступ к базе кода. Это где системы, такие как 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.

Последнее слово предупреждения

Если вы нашли себя , работая в команде , которая управляет , чтобы сделать все это право .. вы будете ненавидеть быть где - нибудь еще ..! Возьмите это от меня, как только у вас появится хорошая команда, внезапно проблемы в другом месте действительно могут затянуть вас. (Это история для другого поста!)