一个好的程序员有可能从未使用过版本控制吗？[关闭]

我正在寻找专业的程序员来帮助解决困难的情况。

到目前为止，采访令人惊讶地令人失望。到目前为止，最好的候选人是从未使用过版本控制软件的，经验丰富的程序员。

问题本身可能并不太严重，因为可以在短时间内了解到这一点。

但是还有一个更深层次的方面，这让我担心：

如何在不需要版本控制的情况下主动开发10-15年的软件？

本身不寻找解决跟踪问题的解决方案的事实本身是否表明对编程态度不正确？

我在不使用源代码控制的公司工作了大约11年。我们进行了管理（主要是通过注释更改并将代码保留在可以恢复到任何日期的中央服务器上）。我们从来没有真正问过是否有更好的方法。就是说，这也是我将整个MSDN库以书本形式放在桌子上的日子。

是的，在互联网之前就有编程。

我很难理解您现在如何在行业中度过10年以上而又没有遇到源代码控制。但是，我会有些同情，我相信这是有可能的，我不会仅就这一细节拒绝候选人。我将进行调查，找出候选人如何做到这一点。

另外，我可能会问我的面试过程是否是问题所在。他以哪种方式是最好的候选人？还有其他我没有问的正确的编程技巧吗？如果我提出正确的问题，其他候选人会发光吗？

最后要注意的是，如果您有担心，不要害怕拒绝所有候选人。重新开始很耗时，但是雇用错误的人则更耗时。

我认为这取决于他的态度。如果他是一个非常有经验的程序员，又是一个优秀的程序员，我认为他将能够迅速使用版本控制系统。他可以用两种方式谈论它：

• 好

  我从未使用过版本控制，但是我很高兴学习，并且它似乎确实有助于提高开发效率。我并不需要那么多，因为我只从事过项目。

• 坏

  版本控制只是一个流行词，在行业中正在逐渐消失。我高于版本控制。

让我给您提供20多年来在DOS和Windows中进行软件开发的一些观点。

在90年代中期，Windows / PC世界中的版本控制软件通常不可靠。Visual Sourcesafe（VSS）大约是最好的基于Windows的Windows，但它可能很古怪，许多程序员都讨厌它。有些团队在处理这种情况后根本不会娱乐他们。

当时，大多数其他VCS选项都不基于Windows，因此在Windows开发团队中很少使用。其中一些是昂贵的解决方案，开放源代码解决方案没有像今天这样容易接受。

在许多情况下，在90年代末，00年代初，如果Windows团队不使用VSS，则除了内部约定外，他们不使用任何东西进行源代码控制。尽管Team Foundation Server（TFS）非常先进，并且还有git和SVN等出色的免费选项，但其中许多仍然没有使用VCS。

在小型Windows开发团队中工作了多年的人可能没有使用VCS。我在一些不使用它们或对它们使用非常随意的地方进行了采访，甚至完成了合同工作。

因此，我认为您的候选人在这方面的经验不足不是绝对的“否”，但您可能想深入研究他们以前的工作状况，以找出为什么他们的经验中缺少这方面的知识。您还需要探索他们对版本控制的态度。他们是否认为这是个好主意，但不允许他们在以前的职位上追求它，还是认为这浪费时间？

没有版本控制软件，您是否无法进行版本控制？询问他们如何管理代码。也许已经有一个本地系统。

想要手动做事，重新发明轮子和抵制变化对编程来说并不是什么新鲜事物。您是否会因为使用Visual Source Safe和“仅” VSS的候选人而流口水？

在寻找人才时，您必须能够分辨出：不能，没有和不会之间的区别。

没有使用版本控制的任何借口，即使是由单个开发人员开发的小型项目也没有。设置本地版本控制非常简单，收益巨大。任何不知道这不能被认为是好的也没有经验的开发人员。

至于将版本控制视为“新颖”的公司，他们不愿意引入：

• SCCS于1972年发布（40年前）
• RCS于1982年（30年前）发布，它是完全开源和免费的
• CVS于1990年（21年前）发布，也是完全开源和免费的

从未使用过版本控制的程序员可能从未与其他程序员合作过。我可能永远不会考虑雇用这样的程序员，而不管其他任何凭据。

看起来像个红旗，但请深入了解为什么他没有使用它。我仍然希望一个开发人员可以在十年内使用版本控制，但是与他在团队中工作甚至从未尝试引入版本控制相比，我会更宽容。

我不会因为缺乏版本控制经验而虔诚。这只是一个工具。最后，您可以在一两天内掌握svn或git的基础知识。其余的您会随着时间的流逝。而且我不敢相信，如果一个半得体的候选人要在使用源代码控制的环境中工作，他将无法适应。

使用源代码控制更多的是习惯而不是技能。从未使用过它的人可能会夸大所需的工作，却低估了所获得的收益。毕竟，他到目前为止还不错。只有真正使用了源代码控制之后，他才会逐渐欣赏它。

您应该问的问题是，在没有源代码控制的情况下，他是如何进行管理的？这可以告诉您有关他的一些信息以及他如何管理他的工作。

您忽略了许多有关他的经历的信息。

基本上，我想说一个程序员很有可能具有10-15年的经验，而不必了解版本控制。十年的编码并不等于十年来不断学习新的编程技术。

我还很年轻，我见过经验丰富的老软件工程师，他们的代码是我永远都不想碰的。话虽如此，他可能很有才华，但从他所提供的信息来看，我可能会从很少的信息中猜测。

祝好运。

就我个人而言，最令人担忧的是，候选人从未遇到过版本控制系统这一概念，或者认为它不值得使用。我发现第一种情况极不可能，但如果是这种情况，那么我就可以假设该候选人在其职业生涯中已经被严重隔离，这将严重怀疑他们作为团队成员的价值。具体来说，他们可能对如何做某些事情非常奇怪，而对做事的“正确”方法一无所知。

如果是第二种情况，他们已经主动决定反对版本控制，那么我就认为他们要么从不从事任何有意义的工作，要么极其自大。或者，充其量，他们拥有一种非常糟糕的方式来维护代码，例如注释掉块，并将每一行代码归因于作者，日期和错误号。

我在这里看到一些相当有判断力的答案，但实际上并没有考虑到被判断的人。

我个人认为版本控制软件是非常宝贵的工具。但是，我们并不是所有人都可以选择和控制工作环境中使用的工具和流程。自1990年以来，我一直从事Windows开发工作。正如其他人所发表的那样，当时Windows中没有太多可用于VCS的工具。我们不会为了获得VCS而引入UNIX服务器。那使我成为一个不好的程序员吗？在我职业生涯的后期，我在一家拥有垂直市场商业产品的公司工作，在该公司中，版本控制不是一个过程，而是一个工具。那使我成为一个不好的程序员吗？我的前三个工作都非常依赖VCS工具。那使我成为一名优秀的程序员吗？

如果我们所有人都只使用最新最好的工具，语言和技术，那就太好了。但是软件开发行业并不总是这样。说“如果他们不这样做，我会立即离开工作...”或“我永远不会接受不使用的工作...”或“我会强迫他们使用，这有点理想主义。 ..”。我们并没有被无限的工作机会所包围，那里的一切都可以按照我们的意愿进行。我们有要支付的账单，需要一份工作，所以我们要处理周围的事情。

最后，对您的问题的答案是：用其技能，思想和决策来判断该程序员，而不是主管人员在其先前的工作中所做出的决策（可能是误导）。

直到我开始专业赚钱之前，我从未认为自己是“程序员”。

我已经创造了很多赚钱的系统，可以使客户赚更多的钱。我是否是“好”开发人员是主观的。

我可以快速进行GSD（完成某件事），这对于Web开发通常使我的客户满意。他们可能看不到幕后的一些丑陋代码，缺少注释等。

直到今年我才使用过Git，也没有Github的个人资料，就现代程序员标准而言，我觉得它已经“落后于时代”。在过去只做过PHP，Flash和iOS之后，我也刚开始做Rails和Django项目。从那以后，我就已经为客户和我自己找到了开发站点的合同，在30岁和几年的编程生涯中学习所有新知识并不是很痛苦。

在当今社会，太多的事情都集中在跟上琼斯和关心别人的想法上。如果您可以摆脱束缚，并考虑您的软件开发需要什么（速度/上市时间，优化的资源管理，文档完善的代码，可伸缩性等），那么这可能比某人是否知道Mercurial，SVN更为重要。 ，Git或任何其他版本控制系统。

我更喜欢问开发者候选人，他们热衷于什么，他们认为有史以来最酷的系统是什么，以及他们将空闲时间用来发展技能的东西是什么。如果人们没有在自己的时间里提高自己的技能，这让我比其他事情更害怕，但这并不意味着它必须吓到你。

我认为您已经从这里的人们那里得到了关于该问题的一些很好的答案，这将有助于您根据自己的需求做出明智的决定。

我发现令人难以置信的是，软件专业人员从未使用过源代码控制，因此我对雇用他感到非常紧张。

他有什么经验。我想知道他还不知道您到目前为止还没有发现什么。

您自己的软件开发经验是什么？您是否可以向他询问有关体系结构，设计模式，常见软件开发问题，系统性能问题，系统安全性问题等？

如果他在这类事情上表现出色，那么也许我可以忽略缺乏源代码控制知识的情况。

一个好的程序员有可能从未使用过版本控制吗？

是。许多具有自学成才的程序员的小公司不使用它。

如何在不需要版本控制的情况下主动开发10-15年的软件？

我亲自向2家小型公司介绍了版本控制，已将1家中型公司从令人难以置信的版本升级为SVN（当时是最佳选择），并在另一家只有一些VC的小型公司中工作，并为某些代码编写了自己的VC解决方案，有很多代码，只是没有任何VC。

本身不寻找解决跟踪问题的解决方案的事实本身是否表明对编程态度不正确？

好吧，这不是一时的失败，但是我肯定会问很多后续问题。像：

您是否尝试过任何VC软件？什么？你觉得怎么样？有什么理由不使用它吗？您以前使用什么来管理代码？您是否曾经在同一代码库上与任何人一起工作过，并且使用了什么方法来避免冲突？

我想同意爆炸药（但我的代表太低了，自动柜员机……）……态度要重要得多。

我认为有几件事情值得追求，以实现卓越的编程：

1. 通讯
2. 创造力
3. 同情心（说什么？）

而且，通常情况下，不止是一点OCD。

您知道类型...坐在那里敲打问题的人，在探索选择时完全迷失了自己的代码。这些人会在执行过程中做笔记，在代码中留下注释，以确保他们理解自己的逻辑路径（并为自己或将来可能需要处理代码的其他程序员提供思路。 ...，因此，在上面的列表中是“同情”！），并迅速清晰地向链上的决策者传达复杂的想法，以便可以有效地解决问题。

一个优秀的程序员可能被困在多年的环境中，要么要么不接受VCS的想法，要么在VCS（la VSS）方面有不好的经验，这使他们不敢尝试新系统，但是我保证在这种情况下，一个优秀的程序员仍然会建立某种例程来保护自己，以免自己的工作因几次糟糕的设计迭代而丢失。

因此，要提防的那种编程人员是声称从来不需要 VCS，也没有采取任何措施避免不可避免的破坏的程序员。他们的态度是“好吧，我造就了，所以这不会错”。与那些刚从大学毕业的新手相比，我更害怕这些，因为新手可以了解到VCS的优势，因为他们意识到自己实际上并不了解。

如何在不需要版本控制的情况下主动开发10-15年的软件？

如果他来自那些由一个人管理小项目的老学校团队，那很有可能。他可能在相同的技术领域拥有10年的经验，而没有学习和提高自己。

本身不寻找解决跟踪问题的解决方案的事实本身是否表明对编程态度不正确？

如果您的候选人曾经在团队开发（至少4个或更多的程序员）环境中，那么这是一个琐碎的问题。但是，程序员之间可能存在工作区分开来处理仅分配给他们的模块，这可能减少了对源代码进行控制的需求。

但是，没有听说互联网时代的源代码控制确实是令人惊讶的情况。因此，我将看看他愿意学习新事物（关于您的开发环境）以及他对动态工作环境的开放程度。

经验很重要，而且您可以很快地学会使用源代码控制工具的技巧，这是正确的。但您正确地看到一个危险信号。

• 您的应聘者是否与该行业及其趋势隔离？
• 是否还需要学习团队合作的许多其他方面？

对我来说，关于版本控制的问题更多的是症状而不是疾病。原因可能会有所不同，并且是良性的。许多临时程序员刚开始做他们认为有意义的事情，从几本关于编程的书开始，而没有对软件开发进行系统的研究。有时，在过去更是如此，计算机科学专业的学生可能会毕业，而无需使用源代码控制系统，因为他们的所有项目都是单独的项目，而且他们去了软件流程高度不成熟的公司。

但是他到了那里，如果他已经成为孤独的狼十多年或更久了，这可能会使人们难以相处。

可能值得询问您的候选人是否还有其他一些探索性问题。

• 告诉我您作为团队成员工作过的时间吗？
• 告诉我您合作过的团队在团队成员之间发生冲突的时间吗？
• 告诉我有关您何时从另一个开发人员那里接收代码并使他的项目继续进行的时间吗？
• 告诉我，您和团队中的其他成员在一起创建代码时如何保持彼此远离？
• 告诉我一个客户报告的问题，该问题与以前可以使用的功能有关，但在更高版本中不起作用？您是如何解决的？
• 您喜欢在团队中工作吗？

他可能还习惯于对其方法，过程进行几乎完全的控制，并且担任唯一的软件专家。您将需要一个愿意接受新的工作方式的人。更多问题：

• 告诉我您使用或帮助创建编码标准的时间吗？
• 您想在编码标准中看到什么？
• 您对重写别人的代码有什么感觉？
• 告诉我您有一段时间参与软件或文档的同行评审吗？
• 您能告诉我有关您参与编写的软件开发的建议或合同吗？
• 告诉我您最喜欢的软件经理或主管吗？
• 告诉我您最喜欢的同事或下属吗？

在2012年，对于具有15年行业经验的人来说，从未使用过版本控制是一个危险信号。如果年份是1982年甚至1992年，它可能不是一个危险的信号。但是，今天，对于该开发人员背景中的这一令人困惑的差距，最好有一个很好的解释。

特殊情况需要特殊说明。

这有点像汽车修理工，他声称自己修理汽车已有15年了，但从未像自己身上那样沾上一点油脂。

当然，用油脂涂抹不会固定变速箱，并且维修手册中没有任何步骤要求这样做，但这不是重点。关键是，吱吱作响的清洁与汽车修理工在工作时的实际外观明显不一致。在这项工作中，您身上会沾上油脂。

如果您正在采访的某个经验丰富的人承认自己没有版本控制经验，那么他可能会夸大或捏造自己的一些经验（甚至不知道版本控制是被广泛使用和重要的东西，他还应该撒谎！ ）

有可能在面试中看到各种小丑。我见过的人不能绘制链表的图表，也不能编写在链表的开头插入节点的函数。然而，他们声称拥有20年的工作经验。

甚至可以期望计算机科学领域的新毕业生也对版本控制产生被动的了解，即使他们尚未广泛使用它。

我会觉得很奇怪，但是对于一个有经验的程序从未使用过专用的源代码控制，这并非没有可能。在与我合作的一家公司中，他们将源代码控制广泛用于其传统的C＃和VB代码。但是，尽管有两名专业的SQL开发人员（其主要工作是编写，维护和执行纯数据库代码），但是纯数据库代码（存储过程和脚本以及表定义）不在源代码控制中。我拥护那里的数据库实体的源代码控制，但仅取得部分成功。

在另一家公司中，开发团队很小（一个人花了很长时间，然后是两个人）。以前的开发人员的源代码控件具有多个源文件副本，并在末尾添加了日期。除了缺乏更好的源代码控制系统之外，我的前任肯定还有能力和聪明的人。

在我成为专业人士之前，我是一名业余爱好者，根本没有使用任何源代码控制，我隐约知道它是什么，但没有打扰。

简而言之，我认为专业人士对此不太熟悉，这很奇怪，但是特别是如果他习惯于很小的团队，那么没有它肯定可以胜任。在招聘时，我不会反对他。不过，我绝对不愿意学习并开始在针对他的工作中使用它。

我自己的2分是取决于他对被问到VC的反应。可能的反应可能是：

1. ?？那是什么
2. 不，我们做了
3. 没有尴尬的洗牌，管理层不允许我们
4. 没有尴尬的洗牌，但我进行了一些自我调查，认为这似乎是我们应该做的事情。

在4的情况下，这个家伙会从我这里获得通过，他的态度正确，并且可能会接受。在3的情况下，他因应理解这是应该做的事情而不是4的功劳而获得赞誉。 d以此作为某种好奇心的证据，并可能超越他。

如果他回答1或2，也就是说，如果他确实知道并不想知道VC，我将严重质疑候选人的判断。他将需要使用其他工具（错误跟踪，质量指标，构建自动化等），如果他不愿意尝试新的工具，那么您可能会发现在所有这些问题上都面临艰巨的挑战方法。

像这里的大多数人一样，我认为不利于应聘者是不公平的，因为他们的雇主没有跟上步伐。对我来说，这完全取决于他们对此有何反应。

回想起来，写些改变是好的。当我找出问题所在时，它为我节省了很多时间，而且由于我将其写下来，因此很快就解决了很多问题。我认为，保留日志是一件好事。尤其是当您与更多人一起编程时。

如果您正在编写Web应用程序，则可以不添加版本控制地继续添加功能，因为您一直在不断向其中添加新内容。但是也许您会用新的东西写日志或新闻帖子。

这一切都与您正在编写的内容有关。

我曾在12到18个月的软件批准过程中工作过。如果尚未将其列入批准的软件列表中，则无法在计算机上获取它。CD / DVD驱动器被锁定，并且机器未连接到Internet。

我首先遇到源代码控制解决方案的是，在准备好测试多年项目的时候，开发人员自己编写了自己的解决方案。他们赌从头开始编写它比批准过程要快。

我遇到此问题的第二个地方在头几个月确实使用了源代码控制，但随后客户希望在其内部网络上进行所有开发。他们再次锁定了所有内容，因此又回到了许多压缩文件夹中。

我知道只有在这些条件下才能工作的开发人员。他们想使用这些工具，他们很乐意使用这些工具，但不允许他们使用这些工具。

调查他们为什么不使用它们。由于零经验，不了解程序与拒绝工具有很大不同。

我在过去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中正确注释的代码库的价值远远超过没有注释的代码库。可以跟踪和理解每次更改的原因，从而使维护人员可以更深入地了解他们需要知道的内容。不能做到这一点是不专业的，唯一的借口是他/她在上一份工作中受到贫穷经理的束缚。即使那样，他们是否不应该为私有项目使用版本控制？