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

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

• Команда не звикла використовувати TFS . У мене було 2 тренування, але було відведено лише 1 годину, що недостатньо.
• Учасники команди безпосередньо змінюють код на сервері. Це не дозволяє синхронізувати код. Потрібне порівняння, щоб бути впевненим, що ви працюєте з останнім кодом. І виникають складні проблеми злиття
• Прогнози часу, запропоновані розробниками, виключають час, необхідний для вирішення будь-якої з цих проблем. Отже, якщо я скажу, що ні, це займе 10 разів більше ... я повинен постійно пояснювати ці проблеми і ризикувати, тому що зараз менеджмент може сприймати мене як "повільний".
• Фізичні файли на сервері відрізняються невідомими способами понад ~ 100 файлів. Об'єднання вимагає знань про проект, що знаходиться під рукою, а отже, співпраця з розробниками, яку я не в змозі отримати.
• Інші проекти випадають із синхронізації. Розробники продовжують відчувати недовіру до контролю над джерелами, а тому поглиблюють проблему, не використовуючи керування джерелами.
• Розробники стверджують, що використання контролю над джерелами є марним, оскільки об'єднання є схильним до помилок і є складним. Це важко стверджувати, оскільки, коли керування джерелами настільки погано використовується і керування джерелом постійно обходить стороною, воно справді схильне до помилок. Тому докази "говорять самі за себе" на їх думку.
• Розробники стверджують, що безпосередньо модифікація коду сервера, минаючи TFS, економить час. З цим також важко сперечатися. Оскільки злиття, необхідне для синхронізації коду, для початку потрібно багато часу. Помножте це на 10+ проектів, якими ми управляємо.
• Постійні файли часто зберігаються в тому ж каталозі, що і веб-проект. Тож публікація (повна публікація) видаляє ці файли, які не перебувають у контролі джерела. Це також викликає недовіру до контролю джерел. Тому що "видавництво ламає проект". Виправлення цього (переміщення збережених файлів із папок рішення) займає багато часу та налагодження, оскільки ці місця не встановлені у web.config і часто існують у кількох кодових точках.

Отже, культура зберігається. Погана практика спричиняє більше поганої практики. Погані рішення призводять до нових хакерів, щоб "виправити" набагато глибше, набагато більше часу, що забирає проблеми. Сервери, простір на жорсткому диску надзвичайно важко підійти. Однак очікування користувачів зростають.

Що можна зробити в цій ситуації?

Це не питання навчання, це питання людських факторів. Вони не хочуть, а створюють дорожні блоки. Зробіть справу з порушеною груповою динамікою, що є першопричиною їх заперечення - зазвичай це страх, це просто страх перед змінами чи це більш зловісно.

Жоден професійний розробник сьогодні чи протягом останніх 20 років не чинив опір контролю над джерелами. Колись, приблизно 30 чи 40 років тому, коли комп’ютери були повільними, управління джерелами ще повільніше, а програми складалися з одного 500-рядкового файлу, це було болем і були поважні причини не використовувати його. Ці заперечення можуть виходити лише від найгіршого ковбоя, про який я можу придумати.

Чи змушена система якось ускладнювати їхнє життя? Дізнайтеся, що це таке, і змініть систему, щоб скасувати заперечення. Повторіть до готовності.

Я пропоную переглянути GIT або Mercurial. Ви можете створити сховище у кожному дереві вихідного коду, вони навіть не помітять і можуть продовжувати хакнути так, як це роблять зараз. Ви можете відслідковувати зміни, які вони зламали в кодовій базі, вносити комісії, об'єднувати їх у інші дерева-джерела тощо. Коли вони побачать, що за кілька секунд ви зробите зусилля, котрі витрачають зусилля, на інший продукт, вони можуть змінити свої ідеї. Коли ви відкатуєте одну з їх гвинтів з однією командою і зберігаєте їхню дупу, вони можуть навіть вам подякувати (не розраховуйте на це). У гіршому випадку ти добре виглядаєш перед начальником і, за бонус, робиш їх схожими на ковбоїв, якими вони є.

Об'єднання знадобило б не лише чудові знання проекту

У такому випадку я боюся, що ти піднімаєшся до прославної річки без весла. Якщо злиття не є варіантом, а також не реалізує його, тож ви говорите, що більше не можете додавати функції, які ви вже маєте в одній гілці (термін, що використовується вільно), в інший.

Якби я був ти, я б переглянув свої перспективи кар'єри ...

Іноді проблеми з реальним світом роблять непрактичним використання.

Помилковий.

Якщо команда не звикла використовувати джерело управління, можуть виникнути проблеми з навчанням

Це не має нічого спільного з контролем вихідного коду і всім пов'язаним з навчанням. Навчання просте, дешеве, ефективне та проводиться за лічені години. Якщо не використовувати управління вихідним кодом, це дорого, ризиковано, неефективно, а проблеми зберігаються назавжди .

Якщо член команди безпосередньо змінює код на сервері, можуть виникнути різні проблеми.

Це питання навчання. Знову. Немає нічого спільного з контролем вихідного коду і всім пов'язаним з навчанням.

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

Їх потрібно навчити використовувати управління керуванням вихідним кодом. Це знижує вартість, зменшує ризик, спрощує речі та є більш ефективними. Це разова інвестиція, яка щомісяця виплачує дивіденди.

Що можливо зробити в подібній ситуації?

Почніть навчати усіх щодо використання керування вихідним кодом.

Оновлення

Розробники стверджують, що безпосередньо модифікація джерела управління економить час.

Оскільки вони помиляються, важливо зібрати дані, щоб точно продемонструвати, наскільки це неправильно.

Однак, на жаль, керівництво, як видається, винагородить негайну відповідь, яка в довгостроковій перспективі дорого коштує.

Єдиний спосіб подолати цю систему винагород - це

А) Визначте, що довгострокова вартість вища, ніж зовнішня короткострокова вартість.

B) Визначте фактичні винагороди, які фактично існують за короткострокову корупцію (тобто прямі зміни) здаються більш цінними, ніж довготривалий правильний контроль вихідного коду. Хто отримує погладжування по голові за те, що робить неправильну справу? Якого погладжування по голові вони отримують? Хто дає? Для того, щоб виправити речі, ви повинні назвати речі, які неправильно, а конкретний менеджер (-и), який (є) насправді заохочує людей.

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

Г) тренуйте людей у ​​нагородах, які ви знайшли за довгострокову цінність; значення, яке явно перевищує короткочасну швидку реакцію.

Розробники, які відмовляються від використання джерела / керування версіями, повинні бути звільнені, просто. Як ви вже зазначали, властиві ризики та витрати НЕ використовувати його переважають будь-які накладні витрати, які він несе на багато-багато порядків. Кожен, хто намагається аргументувати це, просто не повинен брати участь у розробці програмного забезпечення, і я б відмовився від роботи з такими людьми.

Ми вирішили цю проблему спочатку, встановивши сервер безперервної інтеграції для побудови нашого джерела управління в dev. По-друге, заблокуйте доступ до папки лише для читання, щоб люди не обходили контроль джерела та змінювали файли безпосередньо.

Це PITA в дні, коли ви не можете відтворити помилку локально, але крім того, що приємніше працювати, перевіряти та рухатися далі, знаючи, що CI-сервер буде автоматично висунутий у розробник.

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

Завдяки структурі команди з плоскоземельних ділянок ви пояснили, що зміна, натиснута зверху вниз, може бути не найкращим способом наближення до ситуації. Один із методів, який варто спробувати, - це придбати безпосередньо один чи два інших диска, щоб концепція набрала обертів. Якщо у вас навіть один інший розробник на борту, буде набагато простіше поширити його на решту команди. Повільно ознайомте їх з концепцією, скажіть, почніть працювати над невеликим побічним проектом, встаньте його та переходьте в Git або навіть філіюйте щось, що розміщується на GitHub .

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

Якщо це не вдається, запустіть.

Ви, очевидно, володієте технічними навичками для виявлення та виправлення своєї ситуації, ваші проблеми пов’язані з людьми та процесами.

Люди, як правило, реагують набагато краще на приклад, ніж зір, тому я б запропонував "виправити" це самостійно:

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

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

Вам також доведеться створити себе як зберігача Джерела - оскільки, здається, ви єдиний, хто турбується, ви повинні змусити людей (за допомогою будь-яких технічних чи психологічних засобів у вашому розпорядженні) дотримуватися план. Переконайтесь, що єдине, що йде до замовника, походить від вбудованої машини поза контролем джерела. Ритуально принижуйте людей, які порушують правила і викликають хаос. Підкупіть їх пончиками ... що б не спрацювало.

Якщо все це здасться занадто великим зусиллям (як це було сказано майже в кожній іншій відповіді) - знайдіть іншу роботу. Вони не варті вашого часу.

Крок 1 - звільнити некомпетентного менеджера!

Якщо ви не можете виконати крок 1, спробуйте дозволити менеджеру обмежувати розгортання на додаток лише до скриптів, взятих з керування джерелом. Якщо розробники (які не повинні мати прав на виробництво продукту, див. Крок 1, якщо вони є) хочуть, щоб їх розгорнуто, вони повинні надходити з контролю джерел. Це вирішило нашу проблему не використовувати джерело управління досить приємно ще коли ми вперше перейшли до використання його для баз даних, а також коду C #.

Як хтось не може бажати різних версій своїх файлів та можливості бачити відмінності? Забудьте про розгалуження та будь-який складний матеріал. Вони навіть не отримують основ. Безпосередньо змінювати виробничий файл, не вносячи найбільш рудиментарних змін у тестове середовище, божевільно. Я працював з деякими людьми і, на щастя, ми ніколи не працювали над одними і тими ж проектами.

Ваші колеги занадто дурні, щоб лінуватися. Це марна трата часу. Все, що ви можете сподіватися, - це навчити свого менеджера. Керівництво повинно подобатися контролю над джерелами, оскільки вони люблять усі форми контролю. Змушує їх відчувати себе важливими. Закрутіть інші; виправити лідера - ваша єдина надія, оскільки ви не зможете його замінити. Почніть спілкуватися з іншими компетентними розробниками, або намагайтеся змусити їх приєднатися до вашої команди, коли у вас є відкриття, або змусьте їх найняти вас у їхньому магазині.

Це хороший приклад проекту, в якому погані практики використовуються настільки всенаситно, що виправити це стає практично неможливо. Для його фіксації знадобиться заморозка, тому все можна очистити без перебоїв. На жаль, такі проекти зазвичай (з очевидних причин) занадто баггі, щоб їх заморожувати протягом декількох місяців, критичні помилки потрібно виправляти через день.

Можливо, ви б спокусилися розібрати проект, щоб створити чисту версію, поки брудна версія обробляється цими щоденними помилками; але найімовірнішим результатом є те, що через кілька місяців, коли "чиста" версія закінчена, ніхто не може сказати вам, які помилки та зміни були включені з моменту вилки (адже той самий розум, який дозволяє людям ковзати в таких практиках, робить малоймовірним, що вони ведуть облік змін, які вони вносять). Чиста версія застаріла, брудна версія як і раніше працює, так що ж відбувається? Чиста версія скидається, найясніше доведено правильно.

Окрім очевидного пошуку нової роботи, я думаю, що відповідь більше всього вище.

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

Інший варіант - переконатися, що на сервері є найновіше (що вам потрібно зробити незалежно) та запустити нове сховище зовсім з останнього. Ви втратите історію, але в цьому місці це маленька картопля.

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

З мого досвіду, перший крок, який повинен відбутися негайно, - це синхронізувати керування джерелами з виробничим сервером. Цей крок може бути настільки ж простим, як взяти копію виробничого коду та перевірити його - код продукту, мабуть, є базою, яку розробляє ваша команда. Цей крок може знадобитися доповнити злиттям з кодом, який плаває навколо в існуючій системі управління джерелами. Код повинен переходити від dev до інтеграції / QA (або обох), а потім на будь-який етап або етап / виробництво.

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

Керівництву, безумовно, потрібно краще впоратися з питаннями тут - підтримка розвитку буде майже неможливою, якщо код застосовуватиметься безпосередньо до prod (а не потрапляти в контроль джерел).

Справжня проблема не в тому, що ковбойські кодери не використовують контроль версій. Справжня проблема полягає в тому, що вони вже обрали якийсь спосіб робити, і ви намагаєтесь змінити їх процес. Обраний процес не включає контроль версій. Всі зміни процесу важкі, якщо самі програмісти не помітять проблеми. Якщо є відчуття, що існуюча система достатньо хороша, намагатися нав’язати якусь іншу систему - просто марно. Ми борг, ви будете асимільовані. Звичайно, вони намагаються боротися, стаючи боргами.

Для вашого розуму я б запропонував налаштувати Git або інший DVCS на власній машині, щоб ви могли відслідковувати зміни. Імпортуйте зміни ваших колег у ваше сховище часто. Вирішуйте конфлікти якнайкраще. Це частково захистить вас від божевілля ваших колег.

Ви згадали, що керівництво заявляє, що розробники повинні використовувати управління джерелами. Якщо ви хочете бути злими, ви можете це застосувати, перевіряючи зміни в TFS та періодично публікуючи сховище, тим самим припиняючи будь-які зміни, яких немає в TFS. (Якщо ви також підтримуєте свій власний DVCS, вам слід зберегти два синхронізовані.) Ваше виправдання для цього полягає в тому, що ви виконуєте доручення керівництва. Якщо ваші колеги втомилися від перезапис своїх змін, запросіть їх використовувати TFS. І продовжуйте змінити клопоти, які не були зареєстровані. Продовжуйте, поки ваші колеги не звільняться або вас не звільнять.

Блокуйте будь-який сервер, окрім їх розробки. Використовуйте менеджер конфігурації. Робіть регулярні ідентифікуючі складання (проти тегів). Позначте кожен набір змін (тобто 1 набір змін на помилку). Також ми ставимо тег на кожну збірку. Майте систему QA між розробкою та виробництвом (як мінімум). Робити збірки в системі якості, використовуючи правильний тег збірки. Подайте їм горе за те, що "зламали збірку".

Я ніколи не стикався з ситуацією, коли я не зміг би створити / виправити проблему (що відображається лише на виробництві). Так, я витратив години на те, щоб проблему відтворити в системі розвитку (плюс, коли ви зрозумієте, ви можете додати її до свого тесту на регресію).

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

Цитата:

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

TFS виявляється сервером Microsoft Team Foundation Server.

Перший мій інстинкт говорить: "це остання версія Microsoft Visual SourceSafe"

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