Возможно ли, чтобы хороший программист никогда не использовал контроль версий? [закрыто]

Я ищу опытного программиста, который поможет решить сложную ситуацию.

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

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

Но есть более глубокий аспект, который меня беспокоит:

Как можно активно разрабатывать программное обеспечение в течение 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 Server (TFS) и отличные бесплатные опции, такие как git и SVN.

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

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

Разве у вас не может быть контроль версий без программного обеспечения для контроля версий? Спросите, как они управляли своим кодом. Может быть, уже существовала доморощенная система.

Желание делать что-то вручную, изобретать велосипед и быть стойким к изменениям - не новость в программировании. Собираетесь ли вы пускать слюни на кандидата, который использует Visual Source Safe и «только» VSS?

Пытаясь найти талант, вы должны понимать разницу между: не может, не имеет и не будет.

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

Что касается компаний, воспринимающих контроль версий как «новинку», которую они не готовы внедрять:

• SCCS был выпущен в 1972 году ( 40 лет назад )
• RCS был выпущен в 1982 году ( 30 лет назад ) и является полностью открытым и бесплатным
• CVS был выпущен в 1990 году ( 21 год назад ), также полностью с открытым исходным кодом и бесплатно

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

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

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

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

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

Вы оставляете много информации о своем опыте.

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

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

Удачи.

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

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

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

Я лично считаю, что программное обеспечение для контроля версий является бесценным инструментом. Но у нас не все есть выбор и контроль над инструментами и процессами, которые используются в нашей рабочей среде. Я занимался разработкой Windows с 1990 года. Как сообщали другие, в то время для Windows было не так много возможностей для VCS. Мы не собирались вводить серверы UNIX просто для того, чтобы получить VCS. Это сделало меня плохим программистом? Позже в моей карьере я работал в компании с коммерческим продуктом вертикального рынка, где контроль версий был процессом, а не инструментом. Это сделало меня плохим программистом? Мои последние три работы в значительной степени опирались на инструменты VCS. Это делает меня хорошим программистом?

Было бы здорово, если бы мы все использовали только самые современные и лучшие инструменты, языки и технологии. Но профессия разработчиков программного обеспечения не всегда работает таким образом. Немного идеалистично говорить: «Я бы немедленно ушел с работы, если бы они не ...» или «Я бы никогда не взял работу, которая не использовала ...» или «Я бы заставил их использовать. .. ". Мы не все окружены бесконечным количеством рабочих мест, где все работает именно так, как мы хотим. У нас есть счета для оплаты и нам нужна работа, поэтому мы имеем дело с тем, что нас окружает.

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

Я никогда не считал себя «программистом», пока не начал зарабатывать, делая это профессионально.

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

Я быстро могу GSD (Get Something Done), что для веб-разработки обычно радует моих клиентов. Они могут не видеть некрасивый код за кулисами, отсутствие комментариев и т. Д.

Я не использовал Git и не имел профиля Github до этого года, что, как мне кажется, отстает от времени с точки зрения современных стандартов программирования. Я также только начал заниматься проектами Rails и Django только после того, как делал в прошлом PHP, Flash и iOS. С тех пор я заключил контракты на разработку сайтов как для клиентов, так и для меня, было совсем не больно узнавать что-то новое в возрасте 30 лет и несколько лет от программирования.

В современном обществе слишком много внимания уделяется тому, чтобы идти в ногу с Джонсом и заботиться о том, что думают другие. Если вы можете разорвать эти оковы и подумать, что вам нужно для разработки программного обеспечения (скорость / время выхода на рынок, оптимизированное управление ресурсами, хорошо документированный код, масштабируемость и т. Д.), То это может иметь гораздо большее значение, чем то, знает ли кто-нибудь Mercurial, SVN Git или любые другие системы контроля версий.

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

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

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

Какой опыт он имеет. Интересно, а что еще он не знает, что вы до сих пор не узнали.

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

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

Возможно ли, чтобы хороший программист никогда не использовал контроль версий?

Да. Многие небольшие компании с программистами-самоучками не используют его.

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

Я лично ввел контроль версий для 2 небольших компаний, перевел одну среднюю компанию с чего-то ужасного до SVN (лучший вариант в то время) и работал в другой небольшой компании, у которой было только несколько VC, написал свое собственное решение VC для некоторого кода и было много кода просто нет ни в одном VC.

Является ли сам факт отсутствия решения проблемы отслеживания изменений признаком неправильного отношения к программированию?

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

Вы когда-нибудь пробовали какое-либо программное обеспечение VC? Какая? Что вы думаете об этом? Есть ли какая-то причина, по которой вы бы не использовали его? Что вы использовали раньше для управления кодом? Работали ли вы с кем-либо раньше над одной и той же кодовой базой, и какие методы вы использовали, чтобы избежать конфликтов?

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

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

1. связь
2. Креативность
3. Сострадание (скажи что?)

И, зачастую, больше, чем немного ОКР.

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

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

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

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

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

Является ли сам факт отсутствия решения проблемы отслеживания изменений признаком неправильного отношения к программированию?

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

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

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

• Ваш кандидат изолирован от профессии и ее тенденций?
• Нужно ли учиться многим другим аспектам работы в команде?

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

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

Возможно, стоит спросить у вашего кандидата еще несколько зондирующих вопросов.

• Расскажите мне о времени, когда вы работали в команде?
• Расскажите мне о том времени, когда в команде, в которой вы работали, был конфликт между членами команды?
• Расскажите мне о времени, когда вы получили код от другого разработчика и продвинули его проект?
• Скажите, как вы и другие члены вашей команды держались в стороне друг от друга, когда создавали код вместе?
• Расскажите мне о проблеме, о которой сообщил клиент, связанной с функцией, которая раньше работала, но не работала в более поздней версии? Как ты это решил?
• Что вам нравится в работе в команде?

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

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

В 2012 году для человека с 15-летним опытом работы в отрасли никогда не использовался контроль версий - это красный флаг. Это может быть не такой красный флаг, если бы это был 1982 год или даже 1992 год. Но сегодня лучше найти отличное объяснение этого загадочного разрыва на фоне этого разработчика.

Чрезвычайные ситуации требуют неординарных объяснений.

Это похоже на автомеханика, который утверждает, что он ремонтировал машины в течение 15 лет, но никогда не получал так много места, как жир.

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

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

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

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

Я нахожу странным, но не невозможным для опытной программы никогда не использовать выделенный контроль исходного кода. В одной компании, с которой я работал, они широко использовали контроль исходного кода для своего традиционного кода на C # и VB. Но чистый код базы данных (хранимые процедуры и сценарии, а также определения таблиц) не контролировался исходным кодом, несмотря на наличие двух профессиональных разработчиков SQL, основной задачей которых было написание, поддержка и выполнение чистого кода базы данных. Я отстаивал управление исходным кодом для объектов базы данных там и был только частично успешным.

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

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

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

Мой собственный 2с - это то, как он отреагировал на вопрос о ВК. Возможные реакции могут быть:

1. А? Что это
2. Нет, мы сделали вместо
3. Никаких смущений , руководство не позволит нам
4. Никаких смущений , но я немного исследовал и подумал, что это похоже на то, что мы должны делать.

В случае с 4, парень получит пропуск от меня, у него правильное отношение и, вероятно, он подберет его. В случае с 3, он получает кредит за понимание того, что это то, что должно быть сделано, но не так много, как за 4. Если он смог назвать пару фактоидов о VC (перечислите некоторые из пакетов VC там), я ' Я принял это как доказательство некоторого любопытства и мог бы передать его.

Если бы он ответил 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, стоит гораздо больше, чем та, которой нет. Причину каждого изменения можно отслеживать и понимать, что позволяет сопровождающим получить более глубокое понимание того, что им нужно знать. Неспособность сделать это непрофессионально, и единственным оправданием для этого может быть, если он / она были ограничены плохими менеджерами на его / ее предыдущей работе. Даже тогда, разве они не должны использовать управление версиями для своих частных проектов?