контроль исходного кода при запуске нового проекта

Question

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

как вам удается работать с контролем источников на начальном этапе?

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

Answer 1

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

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

EDIT

Чтобы решить проблему, связанную с несколькими людьми, работающими над одной и той же задачей, я склонен работать в небольших группах, по 2-6 человек; в этой среде у меня был большой успех с scrum подходом, использующим методологию Crystal Clear :

1. Архитектор (ы) / дизайнер (ы) предлагают дизайн высокого уровня
2. Архитектор (ы) / проектировщик (и) определяют итерации / поставки, первая из которых - «каркас проекта», который состоит из архитектурных и серверных компонентов и тонкого фрагмента приложения
3. Ведущий разбивает функции на 1-3 дня / единицы работы (по оценкам)
4. Команда встречается и обсуждает приоритет, сроки и зависимости задач, а также делит первый набор задач
5. Команда ежедневно проводит короткие встречи для обсуждения статуса / приоритетов и зависимостей, а также при необходимости меняет направление

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

Answer 2

Я не думаю, что контроль исходного кода во многом связан с проблемой координации усилий людей (за исключением того, что он может улавливать некоторые "конфликты", когда люди ошибочно пытаются модифицировать одни и те же файлы разными способами - но это не так хорошо, как предотвращение конфликтов, и даже просто «предотвращение конфликтов» само по себе не гарантирует, что все работают над тем, что они должны в идеале работать прямо сейчас, с точки зрения приоритетов). Координация должным образом управляется с помощью практик (и, возможно, инструментов, например, Pivotal Tracker - но использование правильных практик даже важнее, чем использование хороших инструментов! -), которые специально направлены на обеспечение координации. Например, методы, которые Tracker разработан для поддержки и совершенствования, такие как основанное на истории итеративное планирование и другие совместимые, такие как stand-up , предлагают способы удовлетворения этих потребностей.

Answer 3

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