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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важные вещи:

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

Наконец, вам нужно желание работать вместе над выполнением плана. Зачастую это самое трудное.

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

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

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

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

На этой ноте я настоятельно рекомендую изучить хотя бы несколько VCS, и у Джоэла Спольски есть отличный вводный учебник по Mercurial. Bazaar (мой личный выбор) похож, а Git - следующий по сходству, но, вероятно, более популярен, чем любой из них (по крайней мере, ATM). После этого у вас есть SVN, который довольно слаб в сравнении.

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

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

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

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

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

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

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

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

Все, что другие упоминали в своих ответах (план, система контроля версий, система отслеживания проблем, система уведомлений, система сборки, набор тестов), можно найти в этих проектах OpenSource.

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

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

Хорошим введением в метод использования системы управления версиями является HOWTO по управлению исходным кодом Эрика Синка http://www.ericsink.com/scm/source_control.html

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