Как программисты работают вместе над проектом?

Ответ 1

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

Рекомендации, которые всегда полезны

• Все исходный код проекта и все, что требуется для его создания, находится под контролем версий (также называемым источником управления). Любой должен иметь возможность построить весь проект одним щелчком мыши.
  Кроме того, ненужные файлы (объектные файлы или скомпилированные двоичные файлы) должны быть добавлены не в репозиторий, так как их можно легко регенерировать и просто потерять пространство в репо.
• Каждый разработчик должен обновлять и фиксировать несколько раз в день. В основном, когда они завершили задачу, над которой они работают, и протестировали ее достаточно, чтобы они знали, что она не содержит тривиальных ошибок.
• Снова: любой должен иметь возможность создавать проект одним щелчком мыши. Это важно и позволяет легко тестировать всех. Большое преимущество, если не программисты (например, босс) тоже могут это сделать. (Это заставляет их чувствовать, что они могут видеть, над чем работает команда.)
• Каждый разработчик должен протестировать новую функцию или исправление ошибок, добавляя до, которые они передают в репозиторий.
• Настройте сервер, который регулярно (в предопределенные интервалы времени) обновляется из репозитория и пытается создать все в полном проекте. Если он терпит неудачу, он отправляет сообщения электронной почты в команду вместе с последними коммитами контроля версий (с тех пор, как фиксация не была выполнена), чтобы помочь отладить проблему.
  Эта практика называется непрерывной интеграцией, а сборки также называются ночными сборками.
  (Это не означает, что разработчики не должны создавать и тестировать код на своих машинах. Как уже упоминалось выше, они должны это делать.)
• Очевидно, каждый должен быть знаком с базовым дизайном/архитектурой проекта, поэтому, если что-то необходимо, различным членам команды не нужно изобретать колесо. Написание многоразового кода - это хорошо.
• Между членами команды требуется связь. Каждый должен знать, что делают другие, по крайней мере, немного. Чем больше, тем лучше. Вот почему ежедневный standup полезен в командах SCRUM.
• Тестирование модулей - это очень хорошая практика, которая автоматически проверяет базовые функциональные возможности вашего кода.
• Программное обеспечение отслеживания ошибок (иногда называемое программным обеспечением для отслеживания времени) - это очень хороший способ отслеживать, какие ошибки существуют и какие задачи имеют разные члены команды. Это также хорошо для тестирования: альфа-бета-тестеры вашего проекта могут общаться с командой разработчиков таким образом.

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

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

Если этого недостаточно, вы можете настроить его также на автоматическое тестирование, если это возможно с данным проектом.

Еще несколько мыслей

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

Некоторые полезные ссылки:
Непрерывная интеграция, Ежедневные сборки - ваши друзья, Контроль версий, Тестирование устройств

Примеры:

Для контроля версий я стараюсь использовать Git для моих личных проектов в наши дни. Subversion также является популярным, и, например, VisualSVN довольно легко настроить, если вы используете сервер Windows. Для клиента TortoiseSVN работает лучше всего для многих людей. Ниже приведено сравнение между Git и SVN.

Для программного обеспечения для отслеживания ошибок Jira и Bugzilla очень популярны. Мы также использовали Mantis на предыдущем рабочем месте.

Для программного обеспечения для непрерывной интеграции существует Teamcity для одного (также CruiseControl и . NET-сопоставление).

Отвечайте на свой вопрос "кто решает основной проект проекта?"

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

Это сложная задача, и обычно задействовано более одного человека. Иногда членам команды также предлагается принять участие или провести мозговой штурм о дизайне всего проекта или конкретных частей.

Ответ 2

Я тоже студент, который недавно закончил курс по разработке программного обеспечения, где весь семестр состоял из проекта гигантской группы. Позвольте мне начать с того, что мы могли бы сделать с 3 людьми, что нам понадобилось 12 из нас в течение всего семестра. Работа с людьми - это непростая задача. Связь является ключевой.

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

** Я также рекомендую отслеживать ошибки, такие как Redmine. Вы можете настраивать учетные записи для всех и назначать людям задачи с разными приоритетами, а также отслеживать и следить, не заботятся ли люди о некоторых проблемах, или, если больше пришло.

И, как уже было сказано, модульное тестирование очень поможет. Удачи! Надеюсь, это помогло: -)

Ответ 3

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

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

Вам может потребоваться изучить документацию для системы управления версиями (одна из Subversion, CVS, Git и т.д.) и для системы сборки (например, на Java есть Ant и Maven).

Ответ 4

Большие вещи:

• План. Если люди не знают, куда они идут, они никуда не пойдут. Поэтому для начала любого проекта необходимо, чтобы несколько человек (часто серые секиры проекта) попадали в кучу и придумывали план; план не обязательно должен быть очень подробным, но он по-прежнему необходим.
• Система управления версиями. Без этого вы не работаете вместе. Вам также необходимо твердое обязательство, что если вещи не совершены, они не учитываются. "О, это в одном из моих песочниц" - просто изнурительное оправдание.
• Отслеживание ошибок. Вы не можете отслеживать эти вещи по папкам электронной почты. Обязательно поддерживайте базу данных.
• Система уведомлений. Люди должны знать, когда делаются коды, которые они поддерживают, или комментарии сделаны к ошибкам, за которые они несут ответственность. Электронная почта может работать для этого, как и IRC (если все используют его, конечно).
• Сборка системы. На самом деле не имеет значения, как это происходит, поскольку при одном действии вы можете получить полную сборку текущего состояния вещей, как вашей изолированной программной среды, так и основной репозиторий. Лучший вариант для этого зависит от того, какой язык вы используете.
• Набор тестов. Набор тестов помогает людям избегать глупых ошибок. Он должен быть так же прост в запуске, как и сборка (быть частью сборки хорошо). Обратите внимание, что тесты являются лишь грубой заменой правильности, но они намного лучше, чем ничего.

Наконец, вам нужна готовность работать вместе над выполнением плана. Это слишком часто трудная часть.

Ответ 5

как программисты работают вместе над часть программного обеспечения в компании

Разработчики никогда не работают в команде. Команды сосут. Dilbert смешно не потому, что он комический персонаж, такой как Гуфи. Он забавен, потому что он настоящий, и люди осознают ситуации, в которых он был.

Ответ 6

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

В крупных организациях может быть специальный инженер и процесс сборки. Обычно такая организация обычно делает официальную сборку на регулярной основе, скажем один раз в день, используя любой исходный код. Процесс также будет включать BVT (тесты проверки сборки) и, возможно, некоторые регрессионные тесты. Разработчики будут проверять код из репозитория, работать на собственной части локально, а затем проверять его.

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

Ответ 7

Короткий ответ - "Это зависит".

В настоящее время я сам работаю над проектом, поэтому я тот, кто строит/использует VCS. Я знаю о других местах, в которых у вас есть команды, работающие над проектом вместе, содрогнувшись по электронной почте. Или большие (+5) команды, использующие VCS.

В этой заметке я настоятельно рекомендую изучить хотя бы некоторые VCS, а Joel Spolsky имеет отличный вводный учебник для Mercurial. Базар (мой личный выбор) похож, а затем Git является ближайшим с точки зрения сходства, но, вероятно, более популярен, чем любой (по крайней мере, ATM). После этого у вас есть SVN, который довольно слаб в сравнении.

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

Ответ 8

Нет никакой поваренной книги для работы с разработкой программного обеспечения, но в целом система контроля версий должна быть сердцем вашей системы сборки, даже если вы работаете в проекте, где вы единственный разработчик. Даже в этом случае возможность вернуть версии и прочитать журнал версий очень приветствует помощь в исправлении ошибок. Это не единственная функция системы управления версиями, но это само по себе оправдывает установку, настройку и обслуживание системы контроля версий.

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

Ответ 9

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

Ответ 10

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

Позвольте мне рассказать вам об этом. Вы находитесь в команде строителей. Архитектор приходит с планом здания, мастер смотрит, что нужно построить, а затем нанимает конструкторов. Каменщик делает стены, проверяет их на прочность и красит их. Электрик делает всю проводку внутри здания, так что электричество может течь. У каждого человека есть своя работа. Иногда электрик может захотеть обсудить с каменщиком, если некоторые стены можно вырезать, но всегда в сочетании с мастером.

Надеюсь, это поможет вам!

Ответ 11

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

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

Ответ 12

Хорошим введением в метод использования управления источником является Eric Sink Source Control HOWTO http://www.ericsink.com/scm/source_control.html

В своих примерах он использует SourceGear Vault, так как он написал его и все, но методы могут применяться к другим системам управления версиями.

Ответ 13

Это еще одна веская причина, по которой нужно смотреть в проекты с открытым исходным кодом.

Ведущие разработчики, которые работают в больших проектах OpenSource (например, Chromium, Mozilla Firefox, MySQL, Popular Gnu Software), являются профессионалами. У них много опыта, и эти проекты эволюционировали в течение многих лет с идеями сотен таких профессионалов.

Все остальные, упомянутые в их ответах (Plan, Version control system, Issue tracker, Notification system, Build system, Test suite), можно найти в этих проектах OpenSource.

Если вы действительно хотите получить опыт работы, я настоятельно рекомендую вам пройти через некоторые популярные и большие проекты OpenSource, а затем получить Source из любого проекта (используя Control Version) и создать его самостоятельно.

PS: Я также участвую в проектах OpenSource, это лучшее, что я когда-либо делал в своей жизни. Доверьтесь мне! вы также почувствуете то же самое.