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

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

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

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

Все, что подойдет.

75 голосов | спросил Leo Jweda 8 J0000006Europe/Moscow 2010, 22:33:55

13 ответов


0

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

Лучшие практики, которые всегда полезны

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

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

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

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

Еще немного мыслей

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

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

Примеры:

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

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

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

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

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

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

ответил Venemo 8 J0000006Europe/Moscow 2010, 23:00:21
0

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

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

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

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

ответил Elaina R 8 J0000006Europe/Moscow 2010, 23:41:37
0

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

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

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

ответил Donal Fellows 9 J0000006Europe/Moscow 2010, 00:00:22
0

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

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

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

ответил danben 8 J0000006Europe/Moscow 2010, 22:37:25
0
  

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

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

Comic

ответил Andomar 9 J0000006Europe/Moscow 2010, 16:27:16
0

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

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

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

ответил jfawcett 8 J0000006Europe/Moscow 2010, 22:43:38
0

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

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

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

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

ответил Wayne Werner 8 J0000006Europe/Moscow 2010, 22:45:46
0

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

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

ответил gclello 9 J0000006Europe/Moscow 2010, 02:18:53
0

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

ответил Hardryv 8 J0000006Europe/Moscow 2010, 22:35:20
0

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

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

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

ответил Shyam 8 J0000006Europe/Moscow 2010, 23:32:02
0

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

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

ответил Donald Miner 8 J0000006Europe/Moscow 2010, 22:38:08
0

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

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

ответил ManiacZX 10 J0000006Europe/Moscow 2010, 11:23:38
0

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

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

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

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

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

ответил claws 14 J0000006Europe/Moscow 2010, 14:14:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132