Когда начинать использовать систему контроля версий на ранних стадиях разработки?

Question

В моем магазине 2 типа людей:

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

Я являюсь частью группы 1 и пытаюсь убедить людей из группы 2 вести себя как я. Их аргументы похожи на следующие:

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

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

Answer 1

Вам не нужны «аргументы, чтобы убедить их». Дискурс - это не игра, и вы не должны использовать свою работу в качестве дискуссионной площадки. Для этого и нужен ваш супруг :) Если серьезно, вам нужно объяснить, почему вас волнует, как другие разработчики работают над сольными проектами, в которых другие люди не участвуют. Чего вам не хватает, потому что они не используют управления источником? Вам нужно увидеть их ранние идеи, чтобы понять их более поздний код? Если вы сможете успешно это сделать, вы сможете убедить их.

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

Пока я отвечаю на вопрос вопросом, позвольте мне задать еще один вопрос: должен ли ваш код компилироваться / работать / не ломать сборку для проверки? Мне нравится, когда мои ветки исправны и повреждены, затем исправлены, работают, отлажены и т. Д. В то же время я люблю, чтобы другие разработчики использовали управление исходным кодом так, как они хотят. Филиалы были изобретены именно по этой причине: чтобы люди, которые не могут ладить друг с другом, не сожительствовали.

Answer 2

Когда кто-то попросил веские оправдания не использовать контроль версий , он получил 75 ответов и 45 голосов.

И когда они спросили Зачем моей команде переходить на управление исходным кодом , они получили 26 ответов.

Может быть, вы найдете там что-нибудь полезное.

Answer 3

Вот мой взгляд на ваши очки.

1) Даже разработчикам-одиночкам нужно где-то хранить свой код, когда их компьютер выходит из строя. Что произойдет, если они случайно удалили файл без контроля исходного кода?

2/3) Прототипы принадлежат системе контроля версий, поэтому другие члены команды могут просматривать код. Мы помещаем наш прототип кода в отдельном месте к основной ветке. Мы называем это Спайк. Вот отличная статья о том, почему вы должны хранить код Спайка - http://odetocode.com/Blogs/scott/archive/2008/11/17/12344.aspx

Answer 4

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

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

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

Answer 5

Я стараюсь писать только код, который компилируется (все остальное закомментировано с помощью тега TODO / FIXME) ... и также добавить все в систему контроля версий.

Аргумент 1: Даже будучи одним разработчиком, приятно вернуться к работающей версии, отследить ваш прогресс и т. Д.

Аргумент 2: кого это волнует, если это всего лишь прототип? Вы можете столкнуться с подобной проблемой через шесть месяцев или около того, а затем просто начать искать этот другой код ...

Аргумент 3: Почему бы не использовать более одного репо? Мне нравится подавать разные вещи в мой личный репозиторий.

Answer 6

некоторые люди могут учиться только на опыте.

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

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

Answer 7

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

Answer 8

рано и часто. Как говорят прагматичные программисты, контроль над источниками - это машина времени, и вы никогда не знаете, когда захотите вернуться.

Answer 9

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

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

Мы используем как CVS (для проектов не .NET), так и TFS (для проектов .NET), где я работаю, а в репозитории TFS есть папка «Песочница для разработчиков», где разработчики могут проверять личные экспериментальные проекты (прототипы).

Если и когда проект начинает использоваться в рабочей среде, код перемещается из папки «Песочница разработчика» в собственную папку в главном дереве.

Answer 10

Лично я часто запускаю контроль версий после первой успешной компиляции.

Мне просто интересно, почему никто не упомянул распределенные системы контроля версий в этом контексте: если вам удастся переключиться на распределенную систему (git, bazaar, mercury), большинство аргументов вашей второй группы станут бессмысленными, поскольку они могут просто начать их хранилище локально и отправить его на сервер, когда они хотят (и они также могут просто удалить его, если они хотят перезапустить с нуля).