Чи можливий хороший програміст ніколи не використовував контроль версій? [зачинено]

Я шукаю експерта-програміста, який допоможе вирішити складну ситуацію.

Інтерв'ю поки що не дивно розчаровувало. Найкращий кандидат поки що - це досвідчений програміст, який ніколи не використовував програмне забезпечення для управління версіями.

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

Але є більш глибокий аспект, який мене хвилює:

Як можна активно розробляти програмне забезпечення протягом 10-15 років, не потребуючи контролю над версіями?

Чи сам факт не шукати рішення проблеми відстеження змін є ознакою неправильного ставлення до програмування?

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

Так, перед Інтернетом було програмування.

Я намагаюся бачити, як ви можете провести 10+ років у галузі зараз, не натрапивши на контроль над джерелами. Але я мав би певну симпатію, я вважаю, що це можливо, і я не відкидаю кандидата лише на одній деталі. Я б проаналізував і дізнався, як кандидат впорався з цим.

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

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

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

• Добре

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

• Поганий

  Контроль версій - це лише казкове слово, яке повільно вмирає у промисловості. Я над контролем версій.

Дозвольте дати вам певну перспективу щодо розробки програмного забезпечення в DOS та Windows протягом 20 років.

Програмне забезпечення управління версіями у світі Windows / PC часто було ненадійним на початку середини 90-х. Visual Sourcesafe (VSS) був про найкращий Windows, який базувався навколо, але це могло бути химерним, і багато програмістів ненавиділи це. Деякі команди просто не забавлялися б їх використанням після вирішення цієї ситуації.

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

У багатьох випадках, наприкінці 90-х, початку 00-х, якщо команда Windows не використовувала VSS, вони не використовували нічого для управління джерелами, окрім внутрішніх конвенцій. Деякі з них досі не використовують VCS, незважаючи на витонченість сервера Team Foundation (TFS) та чудових безкоштовних варіантів, таких як git та SVN.

Можливо, хтось, хто роками працював у невеликій команді розробників Windows, не використовував VCS. Я брав інтерв'ю у та навіть робив контрактну роботу в деяких місцях, які їх не використовували, або які були дуже неприємними щодо їх використання.

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

Ви не можете керувати версіями без програмного забезпечення для управління версіями? Запитайте, як вони керували своїм кодом. Можливо, вже була створена домашня система.

Бажаючи робити речі вручну, винаходити колесо і бути стійкими до змін - це нічого нового для програмування. Чи збираєтесь ви зависати над кандидатом, який використовує безпечну програму Visual Source та "лише" VSS?

Намагаючись знайти талант, ви повинні вміти розрізняти різницю між: не можна, не хочу і не хочу .

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

Що стосується компаній, які сприймають контроль над версіями як "новинку", яку вони не бажають вводити:

• SCCS був випущений у 1972 році ( 40 років тому )
• RCS був випущений в 1982 році ( 30 років тому ), і це повністю з відкритим кодом і безкоштовно
• CVS був випущений в 1990 році ( 21 рік тому ), також повністю з відкритим кодом та безкоштовним

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

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

Я б не був релігійним через відсутність досвіду контролю версій. Це лише інструмент. Зрештою, ви можете підібрати основи svn або git через день-два. Решту ви збираєте з часом. І я не можу повірити, що жоден напівпристойний кандидат не зміг би вписатися, якби він працював у середовищі, яке використовує контроль над джерелами.

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

Питання, яке ви повинні задати, полягає в тому, як він керував за відсутності джерела контролю? Це може сказати вам щось про нього та про те, як він керує своєю роботою.

Ви залишаєте багато інформації про його досвід.

В основному, я б сказав, що дуже можливо, що програміст може мати 10-15-річний досвід роботи, не знаючи про контроль версій. Кодування протягом 10 років не дорівнює постійному вивченню нових методик програмування протягом 10 років.

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

Удачі.

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

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

Я бачу тут кілька досить судимих ​​відповідей, які насправді не враховують особу, яку судять.

Я особисто вважаю, що програмне забезпечення для управління версіями є безцінним інструментом. Але ми не маємо вибору та контролю над інструментами та процесами, які використовуються в наших робочих умовах. Я працював у розробці Windows з 1990 року. Як опублікували інші, на той час для VCS в Windows не було багато доступних. Ми не збиралися заводити UNIX-сервери лише для того, щоб отримати VCS. Це зробило мене поганим програмістом? Пізніше у своїй кар’єрі я працював у компанії з комерційним продуктом вертикального ринку, де контроль версій був не інструментом. Це зробило мене поганим програмістом? Останні три мої роботи в значній мірі покладалися на інструменти VCS. Це робить мене гарним програмістом?

Було б чудово, якби ми всі мали використовувати лише новітні та найкращі інструменти, мови та технології. Але професія розробки програмного забезпечення не завжди працює таким чином. Трохи ідеалістично сказати: "Я б покинув роботу негайно, якби вони не ..." або "Я ніколи не брав би роботу, яка не використовувалась ..." або "Я змушу їх використовувати. .. ". Ми не всі оточені безмежною кількістю можливостей роботи, де все працює саме так, як ми хочемо. У нас є рахунки для оплати і потрібна робота, тому ми маємо справу з тим, що навколо нас.

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

Я ніколи не вважав себе "програмістом", поки не почав заробляти гроші, роблячи це професійно.

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

Я можу швидко отримати GSD (Get Something Done), що для розробки в Інтернеті зазвичай радувало моїх клієнтів. Вони можуть не побачити якийсь некрасивий код за кадром, відсутність коментарів тощо.

Я не використовував Git і не мав профілю Github до цього року, що, на мою думку, є «відсталим від часів» з точки зору сучасних стандартів програмістів. Я також тільки почав займатися проектами Rails і Django після того, як тільки в минулому зробив PHP, Flash та iOS. З тих пір я підписав контракти на розробку сайтів як для клієнтів, так і для мене, не дуже болісно навчитися чомусь новому в 30-річному віці і через кілька років поза програмуванням.

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

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

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

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

Який досвід він має. Мені було б цікаво, що ще він не знає, що ви досі не дізналися.

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

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

Чи можливий хороший програміст ніколи не використовував контроль версій?

Так. Багато малих компаній з програмістами-самоучками не користуються цим.

Як можна активно розробляти програмне забезпечення протягом 10-15 років, не потребуючи контролю над версіями?

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

Чи сам факт не шукати рішення проблеми відстеження змін є ознакою неправильного ставлення до програмування?

Ну, це не миттєвий збій, але я, безумовно, задавав б багато запитань. Такі речі:

Ви коли-небудь пробували будь-яке програмне забезпечення VC? Що? Що ви думали про це? Чи є якась причина, щоб ви не використовували його? Що ви раніше використовували для управління кодом? Чи працювали ви з ким-небудь раніше на одній і тій же базі коду, і які методи ви використовували, щоб уникнути сутичок?

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

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

1. Зв'язок
2. Творчість
3. Співчуття (скажи що?)

І, часто, більше, ніж трохи OCD.

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

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

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

Як можна активно розробляти програмне забезпечення протягом 10-15 років, не потребуючи контролю над версіями?

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

Чи сам факт не шукати рішення проблеми відстеження змін є ознакою неправильного ставлення до програмування?

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

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

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

• Чи відокремлений ваш кандидат від професії та її тенденцій?
• Чи потрібно також вивчити багато інших аспектів роботи в команді?

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

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

Можливо, варто запитати, чи є у вашого кандидата ще кілька пробних питань.

• Розкажіть про час, коли ви працювали в складі команди?
• Розкажіть про час, коли в команді, над якою працювали, виник конфлікт між членами команди?
• Розкажіть про час, коли ви отримали код від іншого розробника і перенесли його проект вперед?
• Розкажіть, як ви та інші члени вашої команди трималися один від одного, коли створювали код разом?
• Розкажіть про проблему, яку повідомив клієнт, пов’язану з функцією, яка працювала, але не працювала в більш пізній версії? Як ти це вирішив?
• Що вам подобається в роботі в команді?

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

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

У 2012 році для тих, хто має 15-річний досвід роботи в галузі, ніколи не використовував керування версіями, є червоним прапором. Це може бути не таким червоним прапором, якби рік був 1982, а то й 1992 рік. Але сьогодні краще було б пояснити цей дивовижний розрив на фоні розробника.

Надзвичайні ситуації вимагають надзвичайних пояснень.

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

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

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

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

Навіть на нових грамотах з інформатики можна очікувати пасивного ознайомлення з контролем версій, навіть якщо вони ще не широко використовували його.

Мені здасться дивним, але не неможливим, щоб досвідчена програма ніколи не використовувала спеціальний контроль над джерелами. В одній компанії, з якою я працював, вони широко використовували управління джерелами для своїх традиційних кодів C # та VB. Але чистий код бази даних (збережені процедури та сценарії, а також визначення таблиць) не знаходився у контролі джерела, незважаючи на наявність двох професійних розробників SQL, головним завданням яких було написання, підтримка та виконання чистого коду бази даних. Я відстоював контроль над джерелами для об'єктів бази даних і був лише частково успішним.

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

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

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

Мій власний 2с полягає в тому, що це залежить від того, як він відреагував на запитання про ВК. Можливими реакціями можуть бути:

1. Так? Що це
2. Ні, ми натомість
3. Жодне збентежене переміщення , управління не дозволило б нам
4. Ніякого збентеженого перетасування , але я трохи дослідив себе і подумав, що це схоже на те, що ми повинні робити.

У випадку з 4, хлопець отримав би пропуск від мене, він має правильне ставлення і, ймовірно, забере це штрафом. У випадку 3 він отримує заслугу розуміння того, що це щось потрібно робити, але не стільки кредиту, як 4. Якщо він зміг назвати пару фактологій про VC (перерахуйте деякі пакунки VC там) I ' Буду сприймати це як доказ деякої цікавості і може його передати.

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

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

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

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

Це все про те, що ви програмуєте.

Я працював у місцях, де процес затвердження програмного забезпечення був від 12 до 18 місяців. Якщо його ще не було у списку затвердженого програмного забезпечення, не було можливості його отримати на машинах. Приводи CD / DVD були заблоковані, а машини не були підключені до Інтернету.

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

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

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

Дослідіть, чому вони їх не вживали. Нерозуміння процедур через нульовий досвід - це зовсім інше, ніж відкидання інструментів.

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

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

Я фактично не бачив систему управління вихідним кодом, поки не перейшов на SunOS 3 і не став користуватися RCS. У той момент я був надзвичайно сприятливим системним програмістом IBM, дуже продуктивним і дуже хорошим у своїй роботі. Усі версії оброблялися шляхом копіювання резервних копій на стрічку та запису, що було де.

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

Отже, сказати, що хтось за визначенням некомпетентний, тому що він або вона ніколи не використовував контроль над версіями, є чудовим аргументом. Треба викопати і подивитися деталі. Якщо вони заявляють, що є розробником Linux / Unix / Mac OS, але ніколи не використовували керування версіями, це говорить їм менш добре, і вам, можливо, доведеться зважити, чи загальний їхній досвід настільки гарний, що ви хотіли б навчати їх у сучасній інженерії програмного забезпечення. Якщо вони і програміст мейнфреймів старої школи - і це те, що вам потрібно - тоді зосередьтеся на тому, чи володіють вони саме потрібними навичками програмування, які ви хочете, і примиріться з тим, що вам потрібно цього навчити їх. Як говорили інші, їхня відповідь на цю концепцію буде вирішальним фактором у цій справі.

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

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

Є кілька можливих причин не використовувати контроль версій:

1. Робота в компаніях, які не займаються розробкою програмного забезпечення як своєї основної діяльності.
2. Або якщо розробник вирішив використовувати якусь іншу систему - дію лише для досвідчених.
3. Або якщо розробник ще не дізнався, як працює кожна система
4. Або це проблема ставлення до інструментів, які вони незнайомі

Але ви повинні бути обережнішими, коли зустрічаєте людей, які припускають:

1. Що є лише один спосіб зробити щось
2. Або що кожен програміст повинен робити це так само, як це робить
3. Або що практику, яку люди використовують, легко змінити

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

Я думаю, що це не стільки питання "Як можна активно розробляти програмне забезпечення протягом 10-15 років без необхідності контролю версій?", А "Як можна активно розробляти програмне забезпечення протягом останніх 10-15 років без жодного разу потребує контролю версій? ".

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

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