Каков наиболее эффективный / эффективный способ разработки приложения с несколькими людьми без контроля исходного кода?

Введение в мою ситуацию

Я работаю в небольшой компании по веб-разработке. У нас есть команда из четырех разработчиков ASP.NET, включая меня. Практически все наши проекты (> 98%) являются проектами с одним человеком, выполнение которых занимает от 1 до 4 недель. Мы не используем источник или контроль версий. Единственное, что у нас есть, это общая папка на локальном сервере, которая содержит последний источник (== источник действующего приложения) всех проектов.

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

Я (и один или два из моих коллег-разработчиков) уже несколько раз говорил своему боссу, что мы должны начать использовать некоторую форму контроля версий и версий, такую ​​как Git, Mercurial или TFS (наш босс очень склонен к Microsoft). К сожалению, мой начальник не видит преимущества перехода на систему управления версиями и источниками, потому что в его глазах сейчас все работает отлично, и он не хочет вкладывать время и деньги в установку новой системы и обеспечение того, чтобы все умеет им пользоваться. Даже после того, как я объяснил ему преимущества (такие как упрощенная совместная работа, разные версии приложения, более безопасный способ изменения кода ...), он все равно не считает, что это то, что нам нужно.

Из четырех разработчиков только двое (включая меня) имеют опыт управления исходным кодом (Git). И этот опыт очень ограничен. Я знаю, как клонировать репозиторий Github на мой компьютер, внести некоторые изменения, зафиксировать их и отправить обратно в Github. Вот и все.

Объяснение моей проблемы / проблемы

Через несколько недель мы начнем работать над довольно большим проектом для наших стандартов. Вероятно, потребуется 2-3 разработчика через несколько месяцев, чтобы завершить его. Я буду руководителем проекта (руководителем проекта и ведущим разработчиком) и буду отвечать за все. У меня была доля проблем с нашим подходом Beyond Compare, и я не хочу идти по этому пути с этим большим проектом, который будет моей ответственностью.

Поскольку я сомневаюсь, что мы сможем

• настроить наш собственный сервер Git,
• научить всех работать с Git и
• успешно использовать Git в этом большом проекте,

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

Обновить

Я хотел бы поблагодарить всех за их ответы и комментарии. Вот план:

1. Проведите встречу с разработчиками, чтобы убедиться, что все технические специалисты одинаково относятся к внедрению контроля версий. Мы сделаем более сильное замечание, когда все за этим стоит.
2. Представьте идею боссу и скажите ему, что нам действительно нужен контроль версий.
3. Реализуйте это как можно скорее.

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

Это не будет потрачено впустую время.

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

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

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

Затем сравните это с затратами на получение контроля версий - ноль (если вы используете открытый исходный код) и настройку - 3 человеко-дня.

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

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

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

Настройте управление исходным кодом, научитесь им пользоваться и не говорите своему боссу. Я обычно не защищаю неподчинение менеджменту, но в этом случае ваш начальник глуп. Если вы действительно думаете, что git займет слишком много времени для изучения, тогда начните с более упрощенной системы контроля версий, такой как svn - она ​​не делает все классные вещи, которые делает git, но еще проще получить базовое понимание.

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

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

У меня есть только ваше резюме, но из этого похоже, что ваш начальник аргументирует время и деньги, а вы аргументируете техническое превосходство. Вы должны быть аргументом время и деньги. Изучите мерзкий способ выполнения задач и отследите некоторое время, которое он может сэкономить, а затем представьте боссу журнал с записями типа «28.03.2011 пришлось ждать 30 минут, чтобы Джо вернулся к скомпилированной сборке так что мы могли бы выполнить команду merge, git merge против его последнего коммита, это было бы примерно 5 секунд "с хорошим итогом внизу.

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

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

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

Это безумие. Вы должны использовать VCS, даже если вы работаете самостоятельно. Не использование VCS в компании должно быть запрещено. Просто сделай это. Сейчас! На самом деле ... Вам не нужны продвинутые вещи с самого начала. GitHub и GitLab очень просты в использовании, но я уверен, что вы можете найти еще несколько хост-сервисов, совместимых с Windows, если ваш босс настаивает (даже если это не сложно настроить и использовать Git в Windows).

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

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

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

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

• Установите контроль версий, который прост в использовании . Я использовал для установки CollabNetSubversion в качестве SVN-сервера, он достаточно быстрый и простой в настройке, если вас не волнует безопасность . Если вы используете Visual Studio, AnkhSvn может быть установлен, чтобы позволить разработчикам легко обновлять / фиксировать исходный код из Visual Studio.

• Убедите своего босса, что тест Джоэла написан человеком, который очень хорошо знает свою работу, и если тест Джоэла предполагает наличие контроля версий, то для этого есть веская причина. В конце концов, он также может решить, что разработчикам не нужны средства подсветки IDE / синтаксиса для написания кода. Блокнот Windows просто отлично, не так ли? А также, почему доступ к интернету? Все, что нам нужно, это очень старый компьютер под управлением Windows 3.1.

• Выйдите из этой компании , так как у меня есть некоторые сомнения, что все, кроме контроля версий, там идеально и профессионально.

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

Любая VCS на несколько порядков лучше, чем ее отсутствие.

Самый простой способ настроить VCS - это получить TortoiseSVN (поскольку вы, похоже, используете C #, я предполагаю, что вы работаете в Windows). Вы создаете репозиторий в выбранной вами локальной папке (перейдите к нему, щелкните правой кнопкой мыши> TortoiseSVN> Создать репозиторий здесь). Предоставьте доступ к этой папке в своей сети (желательно, чтобы она была на компьютере, который всегда доступен) и сделайте заказ с помощью URL file://computername/path/to/that/repository. Загрузка исключена, установка занимает не более минуты.

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

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

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

(-:

Будучи разработчиками ASP.NET, я бы посоветовал вам выбрать один из Subversion, TFS или Mercurial, но, если честно, не имеет значения, какое время вы занимаетесь чем-то. Разработка без контроля версий не имеет никакого смысла - тем более, когда инструменты более или менее бесплатны для развертывания и накладные расходы на их использование минимальны.

TFS даст вам потрясающий уровень интеграции. DVCS (Mercurial или Git), вероятно, даст вам наибольшую гибкость и возможности. Нет веской причины НЕ делать этого.

Если бы я начинал с нуля, это почти наверняка было бы с Mercurial.

Получив контроль версий, вы можете перейти к серверу сборки (TFS, TeamCity) и оттуда к непрерывной интеграции, и с этого момента вы начнете выигрывать в кулак.

Чтобы вернуться к вашей начальной точке:

Я буду руководителем проекта (руководителем проекта и ведущим разработчиком) и буду отвечать за все

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

Как упоминалось выше, вы можете поместить репозиторий в общую папку, которая у вас уже есть. Вам не нужно тратить время на настройку сервера, если вы используете распределенную систему контроля версий, такую ​​как Git, Mercurial или Bazaar.

Я бы посоветовал вам использовать либо Git, как у вас уже есть некоторый опыт, либо Mercurial, который хорошо интегрируется в Visual Studio.

Если в будущем ваш начальник скажет вам перейти на TFS, это все равно лучше, чем вообще не иметь контроля версий.

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

То, что мы сделали, было довольно просто. «Эй, Том, я собираюсь поработать над xyz.pbl. Так что не делай никаких изменений». По большому счету у нас редко возникали какие-либо проблемы.

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

Установите Git или Mercurial на свой компьютер. Версия вашей собственной работы. Когда команда синхронизирует свою работу через процесс Beyond Compare, добавьте изменения в локальное хранилище в качестве нового коммита. Вы всегда сможете получить предыдущую рабочую версию из вашего локального репозитория, если синхронизация команды что-то сломает.

Использование DVCS гарантирует отсутствие необходимости иметь сервер и сложный процесс настройки. Установка Mercurial и начало работы с основами должно занимать не более 30 минут.

Это не идеальное решение, но лучше, чем ничего.

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

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

риск

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

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

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

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

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

Используйте распределенную систему контроля версий, такую ​​как git, и используйте компьютер с общими папками для хранения репозитория ссылок. Вот почему:

Каждый клон является резервной копией

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

Общая ссылка

Наличие основного репозитория с основной веткой позволяет узнать версию с последним словом. Это решает: «Вы проверили свои изменения по сравнению с версией Франка, но были ли у вас и Джона тоже? И как вы их слили?».

Доставить более комфортно

Клиент хочет альфа-версию сегодня? Ну, вы можете проверить, достаточно ли мастер стабилен, и отправить его. Если это не так, и у вас нет времени, чтобы это исправить, просто вернитесь в прошлое и получите более старую, но более стабильную версию. Вы не можете сделать это, если у вас есть только последняя версия.

Вернитесь в прошлое и исправьте свои ошибки

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

Найдите ошибки проще

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

Каждый разработчик несет ответственность за свою работу

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

С VCS, в простом рабочем процессе, разработчик должен заботиться только о своей работе и об одном внешнем источнике изменений: основной ветке. В основной ветке может быть 1 или 100 человек, это то же самое. Чтобы иметь возможность продвигать свои изменения, он / она должен будет адаптировать их к последним изменениям, сделанным другими. Может показаться, что продвижение кода занимает больше времени, но это потому, что вы также выполняете слияние, которое в любом случае заняло бы время.

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

Кто написал этот код?

Здесь есть эта ошибка, но кто написал эту строку кода? Трудно запомнить, особенно если проект длится несколько месяцев. git blameсказал бы вам, кому и когда была написана эта строка, чтобы вы могли спросить нужного человека, и там нет слова «я не помню, как это писал».

Проект становится больше

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

Срочные изменения

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

Сработало 10 минут назад

Вы вносите некоторые изменения локально, и что-то, что работало 10 минут назад, перестало работать. Без VCS вы либо смотрите на код, либо в лучшем случае копируете эталонную версию и анализируете изменения. Ой, подождите, ссылка изменилась с тех пор, как я начал работать, поэтому я не могу больше различаться. И я не думал сохранять нетронутую копию кода, на котором я основывал свои изменения.

С VCS вы просто делаете что-то подобное git diffпрямо сейчас, и ваши изменения по сравнению с правильной версией кода, на котором вы основаны.

Я должен держать свои журналы отладки

Значит, вы плохой парень и не используете логирование? Вы должны были посыпать printfs во всей своей кодовой базе, пока не нашли все эти кусочки этой неприятной ошибки? Теперь вы нашли один, исправили его, но хотите сохранить тщательно продуманный отладочный код для решения оставшихся проблем.

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

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

Большой шарик грязи

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

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

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

вдавливание

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

Вы руководитель проекта

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

Используйте Dropbox, он имеет автоматическую историю версий. Вы можете разделить dropbox-папку между несколькими пользователями.

редактировать

Вы также можете скачать TortoiseSVN-клиент и создать «локальный репозиторий» на сетевом диске. Затем люди могут оформить исходный код по расположению в сетевой папке.