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


73

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

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

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

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

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

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


25
谁说他不需要版本控制?他需要它,我想他是手动完成的。话虽如此,一位程序员这样做似乎很抵制学习新知识-为此做好准备。
布朗

6
@ e-MEE取决于您,您可能会在30至60分钟内学习更新/解析/提交,但没人会在一小时内学会(d)vcs的工作方式。多年使用它的大多数人仍然没有真正得到它。
atamanroman

3
@ConradFrix胡萝卜蛋糕:)
乍得·哈里森

7
如果日历显示今天是1981
。– Kaz 2012年

7
这听起来像是一个经典案例,即没有10年经验,而是1年经验重复10次。
珍妮·平达

Answers:


90

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

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

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

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

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


17
+1,这是一个有趣的答案。但是,我不太同意“在那些日子里,源代码管理成本很高”。RCS已经存在了30年,CVS已经存在了21年。两者都是开源的。
vartec

8
+1:我仍然在这里工作。我们终于在今年获得了可管理的源代码控制(很大程度上是由于我)。我认为直到现在还没有它,我们都不是一个可怕的开发人员,但是我非常高兴它来了
Oliver-clare 2012年

3
如果考生了解源代码控制的原理,那么我认为没有问题。有经验的开发人员应该能够很快使用任何系统的“语法”。我会问一个问题-所有这些体验都集中在一个站点吗?如果是这样,那么也许他没有权限来引入一个系统。如果他在不同公司工作过,那么我会进一步探讨。如今,不使用源代码控制的拥有开发团队的公司数量必须最少。
BIDeveloper 2012年

4
+1询问正确的问题。我想知道是什么使他也成为最佳候选人。
Shambulator

3
@Ramhound:您认为手动进行源代码控制时需要更少的硬件和更少的备份时间吗?以我的经验,事实恰恰相反。
布朗

49

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

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

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


17
我同意这可能是十年前的事,但是今天呢?我会说不是“好/坏”,而是“坏/可怕”
vartec

24
即使您是一个人工作,使用VCS也非常有价值。在使项目从“几乎可以正常工作”变为无法再次正常运行,并且没有任何方法可以恢复到“几乎可以正常工作”的版本之后,我发誓无论项目多么小,一切都将放入VCS中。
alroc 2012年

11
“我很高兴学习。”-这不是像Coherence这样昂贵的商业产品。任何人都可以熟悉源代码控制。如果您阅读有关软件开发的任何博客,则应该了解它。
安迪

7
为此答案+1。一个优秀的程序员并不是拥有他所有技能的标志。这是他/她可以拿起所需的任何技能。
2012年

2
@Steven:没有。按照这种逻辑,可以雇用一个八岁的孩子,因为他们可以接受编程。IMO有或应该具备被视为程序员的基本技能。精通编程语言是一种,而掌握和使用任何 VCS则是另一种。还有更多。
史蒂文·埃弗斯

34

让我给您提供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。我在一些不使用它们或对它们使用非常随意的地方进行了采访,甚至完成了合同工作。

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


18
VSS不是“古怪”的-只是很糟糕。损坏的存储库和数据丢失是很常见的,但是问题发生后的几周或几个月内,您可能都没有发现它,除非您进行每日完整性检查(即使那时也能从中恢复过来)。文件锁定和共享非常糟糕。程序员之所以讨厌它,是因为它使他们的生活陷入死地-与VCS应该做的事情完全相反。
alroc 2012年

@alroc-信不信由你,那里有一些不那么可靠,更古怪的东西。我不幸使用了大约1995年。我从未遇到过VSS可靠性严重的问题,但我确实听到过其他人带来灾难的故事。我知道一些组织在经历了VSS的不良经历后就停止使用任何VCS。
jfrankcarr 2012年

UGGH,我们曾经尝试过Powerbuilder的源代码控制。它积极地导致我们丢失源代码。PB会崩溃,其他任何人都无法访问任何已签出的pbl。那真是个笑话。
GrandmasterB 2012年

我在一家使用Visual Source Safe的商店工作了1.5年。最好的程序员之一会在他每次尝试通过电话检入代码时都破坏存储库(是的,这是前一段时间)。我最不喜欢的VCS系统之一。
GlenPeterson,2012年

我们在DOS环境中的一项工作中使用了tlib(burtonsys.com/index.html)。当然,这是在2005年,但似乎他们已经使用了一段时间。
Doug T.

29

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

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

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


在我发现有关版本控制及其有用性之前(我是在经过2年的非专业,业余爱好者编程后才发现的),对于我来说,拥有五个带有项目里程碑“备份”的文件夹(一个原始的VCS)并不罕见。
orlp 2012年

“不能,没有,不会和被禁止”?我听说过有些地方不同意运行源代码控制,因为他们喜欢作为网络驱动器的丛林。
菲利普(Philip)

19

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

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

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

20
不确定SVN是“超越普通”设置的最佳示例。您必须在仓库中直接编辑其中一些文件,这些文件可能很奇怪。设置本地DVCS并非易事。和设置到位桶/ GitHub的帐户,并从中克隆回购协议是不是要复杂得多
PDR

9
@vartec:超越琐碎的是git init。链接的页面可能会让我逃脱,因为感觉很复杂。
maaartinus 2012年

7
@vartec:我认为,与多年来使用集中式VCS的人相比,VCS新手更容易理解git和hg,对于新手,它比CVCS更容易理解。只需查看该页面上的“存储库布局”部分,就好像您还不了解它一样。然后思考“我在这里有一个存储库,我想在这里克隆它”。
pdr 2012年

8
@vartec:嗯。不能同意。我喜欢即使我一个人工作也能分支和克隆。有时我有想法。有时他们是坏人:)。
pdr 2012年

4
我曾在管理层拒绝Versión控制的公司工作。这不是一个选择。我们做了有趣而复杂的项目。因此,我认为我不是最糟糕的开发人员。到目前为止,尽管我承认我已经考虑过,但在家里我也不使用它。
Picarus

14

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


34
我不同意。不使用源代码控制将需要比其他程序员更高水平的合作。我什至可以说,如果您来自没有源代码控制的环境,那么您真正了解合作的重要性
Oliver-clare 2012年

12
那是一个光荣的陈述,显然是不真实的。
Murph 2012年

3
我根本不想雇用一个不知道如何使用现代工具的程序员。他/她可能知道如何编写令人难以置信的出色代码,但是我认为至少必须具备版本控制的基本知识。
JesperE 2012年

6
周围的许多人似乎对没有接触VCS感到困惑,并积极拒绝在新工作中使用它。如果仅仅是他/他们在他们以前的工作场所从未发生过或者被管理者所困扰,该怎么办?就是说,如果我要招聘的话,这是一个关键问题,而他们的学习意愿对我来说是一个艰巨的要求。
捷尔吉Andrasek

5
吓到这里这么多人,实际上发现缺乏源代码控制是正常的或可以接受的。
JesperE 2012年

12

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


6
+1:如果因为我现任经理不了解源代码管理的重要性而失业,我会感到恐惧。至少我确实对所有个人项目都使用了源代码管理,所以我不会完全被这种情况所困扰……
Oliver-clare 2012年

2
@LordScree-在高容量的网站上工作可能很困难,但是您仍然可以学习在工作之外使用源代码控制。
JeffO 2012年

9

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

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

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


4
绝对需要找出他如何在没有版本控制的情况下管理更新,发行等
ChrisF

4

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

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

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

祝好运。


4

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

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


4

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

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

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

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


4
如果您只与白痴一起工作了15年,并且没有做过任何智能的开源程序,那可能会反映出您的技能和态度。人们受他们的环境影响。如果不是这样,我们为什么还要看某人的工作经历。
卡兹(Kaz)2012年

@Kaz我们查看他们的就业历史不是为了他们的同事,而是他们自己的。无法判断他们长大的区域中的某人,否则我们也可能会开始采访邻居。
James Khoury 2012年

是的,它是由我们的环境决定的,但是我们的环境并未定义我们。我只是建议OP全面了解程序员,而不要根据一个标准做出苛刻的判断。
cdkMoose 2012年

4

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

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

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

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

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

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

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


2

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

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

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

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


2

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

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

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

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

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

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

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


1
这个答案没有什么新鲜的。
pdr 2012年

1
如今,聪明的自学成才的程序员都知道并使用版本控制。其余的人的头卡在某个地方。
卡兹(Kaz)2012年

@Kaz不同意。我认为这就是我们想要的想法,但是正如我的亲身经历所言,我遇到了一些我认为很聪明但没有的程序员。不使用版本控制是一个很大的警告信号,表明他们可能将头塞在[迷人的短语:-)]处,但并非总是如此。
詹姆斯

2

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

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

  1. 通讯
  2. 创造力
  3. 同情心(说什么?)

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

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

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

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


2

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

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

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

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

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


不是每个人都阅读编程博客/等。尤其是,一个职业生涯完全使用单一遗留平台的人不会从他们那里找到很多直接的价值。您了解多少个Mainframe / COBOL / RPG(非游戏)软件博客?在过去的30年中,对这些平台进行编程并没有太大的改变,并且几乎可以肯定的是,为它们提供的许多最佳信息源仍处于死树格式。如果编程是您的工作,而不是您生活的重点,那么在那些领域工作时,阅读技术博客等不会在短期内获得很高的投资回报率。
丹·尼利

1
即使在一个人的项目中,您也可以从版本控制中受益。如果发现错误,则可以声明“在3.13版中引入的错误”,因此3.13及更高版本的用户受到影响。对于不想迁移到最新版本的人,您还可以轻松地为各种版本制作补丁。如果您可以在没有版本控制的情况下执行这些操作,那么您实际上是在进行临时的版本控制。您希望您的用户使用您的软件来消除繁琐且容易出错的手动工作,但是您(程序员)却不要自己这样做!大声笑。
卡兹(Kaz)2012年

2

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

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

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

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

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

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

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

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

2

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

特殊情况需要特殊说明。

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

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

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

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

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


您一直希望新毕业生获得的最好成绩是:“哦,我听说过”。我们围绕Subversion进行了为期一周的介绍,但从未对任何内容使用版本控制。
Izkata 2012年

是的,因为他们是新毕业生,所以我们“购买”并继续前进。
卡兹(Kaz)2012年

“通过熟悉度”(我认为您在答案中的意思)表示他们已在某些时候使用它;我要指出的是,您甚至都无法期望。
Izkata 2012年

我想说的是,如果CS毕业生没有使用版本控制,那么他们的母校部门将无法实施适当的强制性软件工程课程,该课程的本科生不仅要学习软件工程概念,而且还要从事团队项目(使用版本)。控制和所有)。我想和那个部门的负责人说一两个字。
卡兹(Kaz)2012年

我从事专业编程已经快20年了。我知道什么是链表,以及为什么要使用它们。我从未使用过它,并且可能会在编写函数时遇到麻烦。我认为仅仅因为您使用30年的技术,就说其他所有人都应该有点不公平。
DefenestrationDay

1

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

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

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

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


要求DBA从数据库生成SQL脚本,然后他可以将这些脚本置于源代码管理中。
linquize 2013年

@linquize哦,同意。这是一种更好的方法(尽管不是唯一的一种)。我只是简单地提到,我遇到了许多经验丰富的专业人士和熟练的业余人员,他们没有源代码控制方面的经验,尤其是在DBA方面。在招聘时,我不愿学习针对潜在新员工的源代码控制,但是对于以前没有使用过它,我不会感到太惊讶,尤其是如果他们习惯于一个小型团队并且主要在数据库方面。
TimothyAWiseman

1

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

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

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

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

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


1

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

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

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


0

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

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

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

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

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


这个答案没有什么新鲜的。
pdr 2012年

0

我在过去15年中一直在发展。仅使用了几次版本控制。我仍在使用自己的预定脚本和程序来增量备份所有开发文件夹。如果有人问我是否使用版本控制,我不知道该说些什么。我从不需要版本控制系统,我一直在从事小型项目。我的意思是我不是那里最好的程序员,但是我确定我不是最差的。大多数时候,我很尴尬地告诉人们我不经常使用版本控制系统,但这对我来说就是这样。


我经历了相反的经历:当我说我是唯一的开发人员的小型项目上使用版本控制时,有人给我一个有趣的表情。如今,情况可能有所减少,因为版本控制用于托管开源项目,因此可以将其理解为一种部署方法。
卡兹(Kaz)2012年

2
您应该改变态度,并研究版本控制,因为它可以让您轻松地完成许多事情。例如,git版本控制系统具有git bisect用于查找回归错误的自动化工作流程()。这将对项目的版本历史记录执行二进制搜索,以尝试查找引入该错误的变更集。您要做的就是重建,运行测试并告知git其好坏。然后选择并检索下一个要测试的基线。
卡兹(Kaz)2012年

git你可以做一些实验性的变化,然后把它们放在一个stash。您的工作将还原为原始内容,并保存更改。稍后,您可以探索自己的存储,然后重新应用这些更改以继续尝试它们,或者将其丢弃。当然,任何体面的版本控制系统都具有分支,通过该分支,您可以执行诸如独立开发稳定版本的功能之类的事情。或者返回并修复发行版中的错误(为客户提供补丁),然后轻松地将更改合并到当前开发版本中。
卡兹(Kaz)2012年

0

从我作为IBM MVS系统程序员的经验来看:在我的职业生涯的前十年中,与我一起使用的操作系统对程序员来说只有一个可版本化的文件类型:生成数据集。这本质上是一个具有固定数量版本的文件,并且您必须记住什么版本是什么-对于现代版本控制几乎没有用。再加上没有真实目录,或多或少(8个字符)限定符的文件系统,源代码管理系统的概念对于在该环境中工作的任何人都是完全陌生的。

在移至SunOS 3并使用RCS之前,我实际上并没有看到源代码控制系统。那时,我是一个非常灵活的IBM系统程序员,生产力很高,并且非常擅长我的工作。通过将备份复制到磁带并记录在何处来处理所有版本控制。

如果我现在仍在大型机上工作,那么很有可能我可能从未接触过正式的版本控制系统。明确支持的替代方案是ClearCase和Rational,它们都不是免费的(事实上,它们都是相当昂贵的)。

因此,从定义上说某人是不称职的,因为他或她从未使用过版本控制,这是一个似是而非的论点。有必要深入研究细节。如果他们声称自己是Linux / Unix / Mac OS开发人员,但从未使用过版本控制,那么这对他们来说不太好说,您可能不得不权衡他们的总体经验是否非常合适,以至于您愿意在现代软件工程中培训他们。如果他们是老派的大型机程序员,而这正是您所需要的,那么请专注于他们是否确实具有所需的编程技能,并拒绝接受这样的事实,即您需要向他们教这些。正如其他人所说,在这种情况下,他们对这一概念的反应将是决定性因素。


0

太好了!我们的整个社区都没有生活在高度发达的社交社区中,在这些社区中,令人讨厌的视频群聊和骇客事件过多,我们都不在软件开发公司工作,我们中有些人甚至找不到相关或最新的出版资源以我们的母语(印刷或在线),就可以与其他程序员见面。

据我所知,如果他像您所说的那样是一位经验丰富的软件开发人员,那么他很可能是独行侠,为小型企业担任自由职业者。


-1

没有使用版本控制的可能原因很少:

  1. 在没有将软件开发作为其主要业务的公司中工作。
  2. 或者,如果开发人员决定使用其他系统-仅对有经验的系统有效。
  3. 或者,如果开发人员尚未了解每个系统的工作方式
  4. 还是对他们不熟悉的工具的态度问题

但是,当您遇到以下假设的人时,请务必小心:

  1. 做某事只有一种方法
  2. 还是每个程序员都必须以相同的方式来做
  3. 或者人们正在改变的习惯很容易

-2

对于一个贫穷的程序员来说,尽可能地成为版本控制专家。我的意思是,我不知道版本控制对您的编程技能或问题解决能力有什么帮助。这是经验的问题。许多较小的商店要么不使用它,要么将其留给个人(他们经常自己工作)自行解决。


-2

我认为这不是“如何在不需要版本控制的情况下主动开发10-15年的软件?”的问题,而是“ 在最近的 10-15年中如何能够从未开发的有源软件?需要版本控制?”。

当然,无需版本控制就可以进行编程,但是专业人员应该熟悉当前的技术水平,并能够选择合适的工具来完成这项工作。未能使用适当的版本管理软件会使您的工作充满风险和不可靠,而您想聘请专业开发人员的原因之一就是他们应该能够管理风险。

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

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.