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

Question

Я всегда программировал один, я все еще студент, поэтому я никогда не программировал ни с кем другим, я даже раньше не использовал систему контроля версий.

Сейчас я работаю над проектомэто требует знания того, как программисты работают вместе над программным обеспечением в компании.

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

Что-нибудь подойдет.

Answer 1

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

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

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

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

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

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

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

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

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

Примеры:

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

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

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

Ответ на ваш вопрос «кто решает основной дизайн проекта?»

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

Краткий ответ - «Зависит».

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

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

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

Answer 9

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

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

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

Answer 10

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