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

ОБНОВЛЕНИЕ
Я работаю в небольшой команде разработчиков, 4 парня. Все они использовали систему контроля версий. Большинство из них не могут выдержать контроль над исходным кодом и предпочитают не использовать его. Я твердо верю, что контроль источников является необходимой частью профессионального развития. Из-за нескольких проблем очень трудно убедить их использовать систему контроля версий:

• Команда не привыкла использовать TFS . У меня было 2 тренировки, но было отведено только 1 час, что недостаточно.
• Члены команды напрямую изменяют код на сервере. Это держит код не синхронизированным. Требование сравнения только для того, чтобы убедиться, что вы работаете с последним кодом. И возникают сложные проблемы слияния
• Оценки времени, предлагаемые разработчиками, исключают время, необходимое для устранения любой из этих проблем. Поэтому, если я скажу «ноно», это займет в 10 раз больше ... Я должен постоянно объяснять эти проблемы и рисковать собой, потому что теперь руководство может воспринимать меня как «медленного».
• Физические файлы на сервере отличаются неизвестным образом более чем на 100 файлов. Слияние требует знания проекта и, следовательно, сотрудничества с разработчиками, которое я не могу получить.
• Другие проекты не синхронизированы. Разработчики продолжают испытывать недоверие к управлению источниками и поэтому усугубляют проблему, не используя систему контроля версий.
• Разработчики утверждают, что использование управления исходными кодами расточительно, потому что объединение подвержено ошибкам и затруднено. С этим трудно спорить, потому что, когда контроль источника настолько плохо используется, а контроль источника постоянно игнорируется, он действительно подвержен ошибкам. Поэтому доказательства "говорят сами за себя" по их мнению.
• Разработчики утверждают, что прямое изменение серверного кода в обход TFS экономит время. С этим также сложно поспорить. Поскольку слияние необходимо синхронизировать код , чтобы начать с отнимает много времени. Умножьте это на 10+ проектов, которыми мы управляем.
• Постоянные файлы часто хранятся в том же каталоге, что и веб-проект. Таким образом, публикация (полная публикация) стирает эти файлы, которые не находятся под контролем исходного кода. Это также вызывает недоверие к управлению источниками. Потому что «публикация разрушает проект». Исправление этого (перемещение сохраненных файлов из подпапок решения) занимает много времени и отладки, поскольку эти местоположения не заданы в web.config и часто существуют в нескольких кодовых точках.

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

Что можно сделать в этой ситуации?

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

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

Неужели система заставляет их усложнять жизнь? Узнайте, что это такое, и измените систему, чтобы аннулировать возражение. Повторите, пока не сделано.

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

Слияние потребовало бы не только большого знания проекта

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

На вашем месте я бы пересмотрел свои карьерные перспективы ...

Иногда проблемы реального мира делают его нецелесообразным.

Ложь.

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

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

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

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

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

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

Что можно сделать в такой ситуации?

Начните обучать всех, как использовать контроль исходного кода.

Обновить

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

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

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

Единственный способ преодолеть эту систему вознаграждений - это

А) Определите, что долгосрочная стоимость выше, чем кажущаяся краткосрочная стоимость.

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

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

D) Обучите людей наградам, которые вы нашли для долгосрочной ценности; значение, которое явно больше, чем краткосрочный быстрый ответ.

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

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

Это PITA в те дни, когда вы не можете воспроизвести ошибку локально, но кроме этого лучше работать, регистрироваться и двигаться дальше, зная, что CI-сервер автоматически отправит ее на dev.

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

Вы объяснили, что с плоской структурой команды сдвинуть изменения сверху вниз, возможно, не лучший способ приблизиться к ситуации. Один из методов, который стоит попробовать, - это получить бай-ин непосредственно от одного или двух других разработчиков, чтобы позволить концепции набрать обороты. Как только у вас появится еще один разработчик, вам будет гораздо проще распространить его среди остальных членов команды. Медленно познакомьте их с концепцией, скажем, начните работать над небольшим сайд-проектом, запустите его и перейдите в Git , или даже добавьте что-нибудь, размещенное на GitHub .

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

Если это не удается, запустите.

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

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

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

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

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

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

Шаг 1 - уволить некомпетентного менеджера!

Если вы не можете выполнить шаг 1, попробуйте заставить менеджера ограничить развертывание только теми скриптами, которые взяты из системы контроля версий. Если разработчики (которым не нужно иметь права на производство на prod, см. Шаг 1, если они этого хотят) хотят, чтобы их материалы были развернуты, это должно происходить из системы контроля версий. Это решило проблему не очень хорошего управления исходным кодом, когда мы впервые перешли на использование его для работы с базами данных, а также для кода C #.

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

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

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

У вас может возникнуть соблазн раскошелиться на проект, чтобы создать чистую версию, в то время как грязная версия обрабатывается этими ежедневными исправлениями; но наиболее вероятным результатом является то, что через несколько месяцев, когда закончится «чистая» версия, никто не сможет сказать вам, какие исправления и изменения были внесены после разветвления (потому что тот же образ мышления, который позволяет людям использовать такие методы, делает маловероятным, что они хранят записи об изменениях, которые они делают). Чистая версия устарела, грязная версия все еще работает, что происходит? Чистая версия сбрасывается, Naysays доказал право.

Кроме очевидного Найти новую работу, я думаю, что ответ больше всего выше.

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

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

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

Исходя из моего опыта, первый шаг, который должен быть выполнен немедленно, - это синхронизация контроля версий с производственным сервером. Этот шаг может быть таким же простым, как получение копии производственного кода и его проверка - код продукта, вероятно, является основой, которую разрабатывает ваша команда. Этот шаг может быть дополнен слиянием с кодом, существующим в существующей системе контроля версий. Код должен перетекать из dev в интеграцию / QA (или оба), а затем либо в стадию, либо в стадию / производство.

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

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

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

Для вашего удобства я бы предложил установить Git или другую DVCS на свой компьютер, чтобы вы могли отслеживать изменения. Часто импортируйте изменения ваших коллег в ваш репозиторий. Разрешите конфликты как можно лучше. Это частично защитит вас от безумия ваших коллег.

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

Заблокируйте любой сервер, кроме их разработки. Используйте менеджер конфигурации. Делайте регулярные идентифицируемые сборки (против тегов). Пометить каждый набор изменений (т.е. 1 набор изменений на ошибку). Мы также ставим тег на каждой сборке. Иметь систему типа QA между разработчиком и производством (как минимум). Делайте сборки в систему QA, используя правильный тег сборки. Дайте им горе за то, что они «сломали сборку».

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

Мы сделали проект с кучей ковбойских подрядчиков, которые сделали все эти плохие вещи. Я потратил 4 недели на уборку после этого и затем применил вышеуказанные методы. С тех пор у проекта не было проблем ни с одной из этих вещей.

Цитата:

Команда не привыкла использовать TFS

TFS оказывается Microsoft Team Foundation Server.

Мой первый инстинкт говорит: «Это последний выпуск Microsoft Visual SourceSafe»

Я был бы на стороне ваших коллег и действительно пошел бы против этого.