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

73

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

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

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

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

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

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

lortabac
источник
25
Кто сказал, что ему не нужен контроль версий? Он нуждался в этом, и я думаю, что он сделал это вручную. Сказал, что программист, который делает это, кажется, очень устойчив к изучению чего-то нового - будьте к этому готовы.
Док Браун
6
@ e-MEE зависит, вы можете научиться обновлять / разрешать / фиксировать в течение 30-60 минут, но никто не узнает, как (d) vcs работает за час. Большинство людей, которые используют его годами, все еще не понимают этого.
Атаманроман
3
@ConradFrix Carrot Cake :)
Чад Харрисон,
7
Хороший программист может никогда не использовать контроль версий, если в календаре написано, что сегодня 1981.
Каз
7
Это похоже на классический случай человека, у которого нет 10-летнего опыта, а 1 год опыта повторяется 10 раз.
Жанна Пиндар

Ответы:

90

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

Да, до Интернета было программирование.

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

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

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

мин
источник
17
+1, это интересный ответ. Однако я не совсем согласен с тем, что «в те дни контроль над источниками стоил хороших денег» . RCS существует около 30 лет, CVS - 21 год; Оба с открытым исходным кодом.
vartec
8
+1: Я до сих пор работаю здесь . В этом году мы наконец-то получаем управляемый контроль версий (во многом благодаря мне). Я не думаю, что мы все ужасные разработчики из-за того, что этого не было до сих пор, но я оооочень рад, что это произойдет
oliver-clare
3
Если кандидат понимает принципы Source Control, то я не вижу проблем. Опытный разработчик должен уметь быстро выбирать «синтаксис» любой системы, которую вы используете. Один вопрос, который я хотел бы задать - весь этот опыт на одном сайте? Если так, то, возможно, у него не было полномочий для введения системы. Если бы его опыт был в разных компаниях, я бы покопался немного дальше. Количество компаний с группами разработчиков, которые не используют систему контроля версий, в настоящее время должно быть минимальным.
BIDeveloper
4
+1 за пункт о том, чтобы задавать правильные вопросы. Интересно, что сделало его лучшим кандидатом?
shambulator
3
@Ramhound: а вы полагаете, что при ручном управлении исходным кодом вам нужно меньше оборудования и меньше времени для резервного копирования? По моему опыту, все наоборот.
Док Браун
49

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

  • Хороший

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

  • Плохо

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

Таблетки взрыва
источник
17
Я бы согласился, что это могло быть в силе 10 лет назад, но в настоящее время? Я бы сказал, что это не «хорошо / плохо», а «плохо / ужасно»
vartec
24
Даже если вы работаете в одиночку, использование VCS чрезвычайно ценно. После того, как проект перешел от «он почти работает» к тому, что он снова не заработал, и у меня не было возможности вернуться к «почти работающей» версии, я пообещал поместить все в VCS независимо от того, насколько мал проект ,
Alroc
11
«Я очень взволнован, чтобы узнать», - это не какой-то дорогой коммерческий продукт, как Coherence. Контроль источников - это то, с чем может познакомиться каждый. Если вы читаете какие-либо блоги по разработке программного обеспечения, вы должны знать об этом.
Энди загружается
7
+1 за этот ответ. Это не признак хорошего программиста, что он / она имеет все навыки. Это то, что он / она может подобрать любой необходимый навык.
Стивен
2
@ Стивен: Нет. Совсем нет. По этой логике можно было бы нанять 8 лет, потому что они могли заниматься программированием. IMO Есть или должны быть базовые навыки, необходимые для того, чтобы считаться программистом. Знание языка программирования - это одно, знание и использование любого VCS - это другое. Есть еще.
Стивен Эверс
34

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

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

jfrankcarr
источник
18
VSS не был "причудливым" - это было просто плохо. Поврежденные репозитории и потеря данных были обычным явлением, но вы можете не обнаружить их в течение нескольких недель или месяцев после возникновения проблемы, если только вы не выполняли ежедневную проверку целостности (и даже тогда удачи выздоравливали). Блокировка и обмен файлами были ужасными. Программисты ненавидели это, потому что это сделало их жизнь адом - полная противоположность тому, что должна делать VCS.
Alroc
@alroc - Хотите верьте, хотите нет, но были и менее надежные и более причудливые. Я имел несчастье использовать один примерно в 1995 году. У меня никогда не было серьезных проблем с надежностью VSS, но я слышал истории о горе от других. Я знаю некоторые организации, которые прекратили использовать любые VCS после неудачного опыта с VSS.
jfrankcarr
UGGH, мы попробовали контроль источника Powerbuilder назад в тот же день. Это активно заставляло нас терять исходный код. PB потерпит крах, и любой извлеченный pbl станет недоступным для всех остальных. Какая это была шутка.
GrandmasterB
Я работал 1,5 года в магазине, в котором использовался Visual Source Safe. Один из лучших программистов разрушал репозиторий каждый раз, когда пытался проверить свой код по телефону (да, это было недавно). Одна из моих наименее любимых систем VCS.
ГленПетерсон
Мы использовали tlib ( burtonsys.com/index.html ) на одной работе в среде DOS. Конечно, это было в 2005 году, но казалось, что они использовали его некоторое время.
Даг Т.
29

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

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

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

JeffO
источник
Прежде, чем я узнал о контроле версий и его полезности (я обнаружил это после 2 лет непрофессионального, увлеченного программированием), я нередко имел пять папок с «резервными копиями» вех проекта - примитивной VCS.
orlp
«Не могу, не хочу, не позволю» Я слышал о местах, где не соглашались управлять исходным кодом, потому что им нравились джунгли, которыми были их сетевые диски.
Филипп
19

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

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

  • SCCS был выпущен в 1972 году ( 40 лет назад )
  • RCS был выпущен в 1982 году ( 30 лет назад ) и является полностью открытым и бесплатным
  • CVS был выпущен в 1990 году ( 21 год назад ), также полностью с открытым исходным кодом и бесплатно
vartec
источник
20
Не уверен, что SVN - лучший пример для «за тривиальной» настройки. Некоторые из этих файлов, которые вы должны редактировать, прямо в репозитории, могут быть неудобными. Настройка локальной DVCS не является тривиальной. А настроить учетную запись BitBucket / GitHub и клонировать репозитории из нее не намного сложнее
pdr
9
@vartec: Что за тривиальным git init. Ссылка на страницу может заставить меня убежать, так как она кажется довольно сложной.
Maaartinus
7
@vartec: Я бы сказал, что git и hg легче понять новичку VCS, чем человеку, который годами использовал централизованную VCS, и проще, чем CVCS для новичка. Просто посмотрите на раздел «Расположение репозитория» на этой странице, как будто вы его еще не поняли. Затем подумайте: «У меня есть хранилище, я хочу клонировать его здесь».
PDR
8
@vartec: Хм. Не могу согласиться. Мне нравится иметь возможность ветвиться и клонироваться, даже когда я работаю один. Иногда у меня есть идеи. И иногда они плохие :).
PDR
4
Я работал в компаниях, где руководство отказалось от контроля над версией. Это был не вариант. И мы сделали интересные и сложные проекты. Я не думаю, что я худший разработчик из-за этого. Дома я тоже этим не пользуюсь, хотя, признаюсь, я это уже обдумал.
Picarus
14

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

JesperE
источник
34
Я не согласен. Отказ от использования контроля исходного кода потребует гораздо более высокого уровня сотрудничества с другими программистами, чем обычно. Я мог бы даже пойти так далеко, чтобы сказать, что если вы пришли из среды, где нет контроля над источниками, то вы действительно знаете важность сотрудничества
oliver-clare
12
Это великолепно широкое заявление и явно не соответствует действительности.
Murph
3
Я просто не хотел бы нанимать программиста, который не знает, как использовать современные инструменты. Он / она может знать, как писать невероятно хороший код, но я бы посчитал, что хотя бы базовые знания по контролю версий абсолютно необходимы.
JesperE
6
Многие люди здесь, кажется, смущаются тем, что не знакомы с VCS, и активно отказываются использовать его на своей новой работе. Что, если это просто никогда не приходило ему в голову на их прежнем рабочем месте или было дословно руководством? Тем не менее, это было бы критической проблемой, если бы я занимался наймом, и их желание учиться было бы жестким требованием для меня.
Дьёрдь Андрасек
5
Страшно видеть, что здесь так много людей на самом деле считают отсутствие контроля над источником нормальным или приемлемым.
JesperE
12

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

Эойн Кэрролл
источник
6
+1: я был бы в ужасе, если бы я был безработным просто потому, что мой нынешний менеджер не видел важность контроля над источниками. По крайней мере, я использую управление исходным кодом для всех моих личных проектов, так что я не был бы полностью
облажен
2
@LordScree - Работать на крупномасштабном веб-сайте может быть сложно сделать самостоятельно, но вы все равно можете научиться использовать контроль источников вне своей работы.
JeffO
9

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

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

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

scrwtp
источник
4
Определенно нужно выяснить, как он управлял обновлениями, выпусками и т. Д. Без контроля версий
ChrisF
4

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

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

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

Удачи.

cubsink
источник
4

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

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

brianmearns
источник
4

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

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

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

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

cdkMoose
источник
4
Если вы работали с идиотами только 15 лет и не делали никаких интеллектуальных открытых источников на стороне, это, вероятно, отразится на вашем наборе навыков и подходе. Люди сформированы их средой. Если бы это было не так, зачем бы нам даже смотреть на чью-то историю трудоустройства?
Каз
@Kaz Мы смотрим на их историю трудоустройства не за вклад коллег, а за их собственный. Не могу судить кого-то по области, в которой они выросли, иначе мы могли бы также начать опрашивать соседей.
Джеймс Хоури
Да, но мы не определяются нашими средами. Я просто предлагаю, чтобы ОП в полной мере посмотрел на программиста и не делал резких суждений на основе одного критерия.
cdkMoose
4

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

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

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

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

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

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

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

ljs.dev
источник
2

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

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

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

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

Ozz
источник
2

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

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

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

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

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

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

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

Джеймс
источник
1
Ничего нового в этом ответе.
PDR
1
Умные программисты-самоучки сегодня все знают о контроле версий и используют его. У остальных где-то застряли головы.
Каз
@ Каз Не согласен. Я думаю, это то, что мы хотели бы думать, но я встречал программистов, которых я считал бы умными, которые этого не делали, как говорит мой личный опыт. Неиспользование контроля версий является большим предупреждением о том, что у них может быть где-то застрявшая голова [очаровательная фраза :-)], но это не всегда так.
Джеймс
2

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

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

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

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

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

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

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

Джейсон М. Бэтчелор
источник
2

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

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

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

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

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

ЭльЮсубов
источник
Не все читают блоги по программированию / и т.д. В частности, кто-то, чья карьера целиком и полностью работала с единственной устаревшей платформой, не сможет получить от них много непосредственной выгоды. Сколько блогов о мэйнфреймах / COBOL / RPG (не играх) вам известно? Программирование этих платформ не сильно изменилось за последние 30 лет, и многие из лучших источников информации для них почти наверняка все еще в формате мертвого дерева. Если программирование - это ваша работа, в отличие от того, вокруг чего вращается ваша жизнь, то при работе в этих областях чтение технических блогов и т. Д. Не принесет значительных краткосрочных инвестиций.
Дэн Нили,
1
Даже в проекте с одним человеком вы получаете преимущества от контроля версий. Если обнаружена ошибка, вы можете указать «что было введено в версии 3.13», и это влияет на пользователей версии 3.13 и выше. Вы также можете легко сделать патч для разных версий, для людей, которые не хотят переходить на последнюю версию. Если вы можете делать эти вещи без контроля версий, то вы делаете де-факто специальный контроль версий. Вы ожидаете, что ваши пользователи будут использовать ваше программное обеспечение для устранения кропотливой и подверженной ошибкам ручной работы, но вы, программист, не делаете этого сами! ЛОЛ.
Каз
2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каз
источник
Лучшее, на что вы можете постоянно надеяться от новых выпускников, это «О, я слышал об этом». У нас было недельное введение в то, что это было, основанное на Subversion, но мы никогда не использовали контроль версий ни для чего.
Изката
Да, и поскольку они - новые выпускники, мы «покупаем» это и идем дальше.
Каз
«мимолетное знакомство» (что, я думаю, вы имели в виду в ответе) подразумевает, что они использовали его в какой-то момент; Я указываю, что вы даже не можете этого ожидать.
Изката
Я бы сказал, что если выпускники CS не использовали контроль версий, то кафедре их alma mater не удалось внедрить адекватный обязательный курс по разработке программного обеспечения, в котором студенты не только изучают концепции разработки программного обеспечения, но и работают над командным проектом (с версией контроль и все). Я хотел бы поговорить пару слов с руководителем этого отдела.
Каз
Я профессионально программирую почти 20 лет. Я знаю, что такое связанный список, и почему они будут использоваться. Я никогда не использовал один, и, вероятно, будет бороться с тонкостями написания вашей функции. Я думаю, просто потому, что вы используете 30-летние методы, сказать, что все остальные должны быть немного несправедливыми.
DefenestrationDay
1

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

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

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

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

TimothyAWiseman
источник
попросите администратора базы данных сгенерировать сценарии SQL из базы данных, а затем он может поместить эти сценарии в систему контроля версий.
Linquize
@ linquize О, согласился. Это один из лучших способов сделать это (хотя и не единственный). Я просто упоминаю, что встречался со многими компетентными профессионалами и опытными любителями, у которых не было опыта управления исходным кодом, особенно на стороне администратора баз данных. При приеме на работу я неохотно изучал бы контроль над источниками против потенциального нового найма, но я не был бы слишком удивлен тем, что не использовал его раньше, особенно если они использовались для небольшой команды и были в основном на стороне базы данных.
TimothyAWiseman
1

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

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

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

Если бы он ответил 1 или 2, то есть если бы он знал и не хотел знать о ВК, я бы серьезно усомнился в суждении кандидата. Будут другие инструменты (отслеживание ошибок, показатели качества, автоматизация сборки и т. Д.), С которыми ему придется работать, и вы, вероятно, обнаружите, что у вас тяжелая борьба по всем этим вопросам, если он не готов попробовать новые. подходы.

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

PhilDin
источник
1

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

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

Это все о том, что вы программируете.

Джейсон Стэкхаус
источник
0

Я работал в местах, где процесс получения утвержденного программного обеспечения составлял от 12 до 18 месяцев. Если его не было в списке утвержденного программного обеспечения, его нельзя было найти на компьютерах. Дисководы CD / DVD были заблокированы, а машины не подключены к Интернету.

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

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

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

Расследуйте, почему они не использовали их. Непонимание процедур из-за отсутствия опыта значительно отличается от отказа от инструментов.

mhoran_psprep
источник
Ничего нового в этом ответе.
PDR
0

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

Тогда
источник
У меня был противоположный опыт: некоторые люди забавно смотрят на меня, когда я говорю, что я использую контроль версий в небольших проектах, где я являюсь единственным разработчиком. Может быть, в наше время и не так, потому что контроль версий используется для размещения проектов с открытым исходным кодом, и поэтому он понимается как метод развертывания.
Каз
2
Вы должны изменить свое отношение и посмотреть на контроль версий, потому что он позволяет вам легко делать много вещей. Например, gitсистема контроля версий имеет автоматизированный рабочий процесс ( git bisect) для поиска ошибки регрессии. Это выполняет бинарный поиск по истории версий проекта, чтобы попытаться найти набор изменений, который привел к ошибке. Все, что вы делаете, это перестраиваете, запускаете тест и сообщаете git, хорошо это или плохо; затем он выбирает и извлекает базовую линию, которая будет проверена следующей.
Каз
В gitвы можете внести некоторые экспериментальные изменения, а затем поместить их в stash. Ваша работа возвращается к оригиналу, а изменения сохраняются. Позже вы можете изучить свой тайник и повторно применить эти изменения, чтобы продолжать экспериментировать с ними, или выбросить их. И, конечно же, любая приличная система управления версиями имеет ветвление, с помощью которого вы можете разрабатывать функцию изолированной стабильной версии. Или вернитесь и исправьте ошибку в выпуске (чтобы дать патч клиентам) и легко объедините это изменение с текущей версией разработки.
Каз
0

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

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

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

Поэтому говорить, что кто-то по определению некомпетентен, потому что он или она никогда не использовал контроль версий, является показным аргументом. Надо копаться и смотреть на детали. Если они утверждают, что являются разработчиком Linux / Unix / Mac OS, но никогда не использовали контроль версий, это говорит о них не очень хорошо, и вам, возможно, придется взвесить, насколько их общий опыт настолько хорош, что вы захотите обучить их современной разработке программного обеспечения. Если они и являются программистом мэйнфреймов старой школы - и это то, что вам нужно, - сконцентрируйтесь на том, обладают ли они именно необходимыми навыками программирования, которые вам нужны, и смиритесь с тем фактом, что вам нужно будет научить их этому. Как уже говорили другие, их реакция на концепцию будет решающим фактором в этом случае.

Джо МакМахон
источник
0

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

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

Филипп Дупанович
источник
-1

Есть несколько возможных причин не использовать контроль версий:

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

Но вы должны быть осторожны, когда вы встречаете людей, которые предполагают:

  1. Что есть только один способ сделать что-то
  2. Или что каждый программист должен делать это так же, как они
  3. Или что практики, которые используют люди, легко изменить
ТР1
источник
-2

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

aserwin
источник
-2

Я думаю, что вопрос не столько в том, «Как можно активно разрабатывать программное обеспечение в течение 10–15 лет без необходимости контроля версий?», Но в том, «Как можно активно разрабатывать программное обеспечение в течение последних 10–15 лет, не прибегая к нужен контроль версий?

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

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

Доминик Кронин
источник