乔尔测试：改善代码的12个步骤(2000)

你听说过SEMA吗？这是一个相当深奥的系统，用来衡量一个软件团队有多好。不，等等！不要关注那个链接！光是理解这些东西，你就需要大约六年的时间。所以我想出了我自己的，非常不负责任的，草率的测试来评定软件团队的质量。最棒的是它需要大约3分钟。用你省下的所有时间，你可以上医学院了。

乔尔测试的巧妙之处在于，很容易对每个问题做出是或不是的快速回答。您不必计算每天的代码行数或每个拐点的平均错误数。每个“是”的答案都给你的团队1分。乔尔测试令人沮丧的是，你真的不应该用它来确保你的核电站软件是安全的。

12分是完美的，11分是可以容忍的，但10分或更低，你就有严重的问题了。事实是，大多数软件组织的运行得分是2或3，他们需要认真的帮助，因为像微软这样的公司全职运行12分。

当然，这些并不是决定成败的唯一因素：特别是，如果您有一个伟大的软件团队在开发一个没有人需要的产品，那么，人们就不会想要它。可以想象，一群“枪手”没有做任何这些事情，却仍然设法生产出令人难以置信的改变世界的软件。但是，在其他条件相同的情况下，如果你做对了这12件事，你就会有一个纪律严明的团队，能够始终如一地交付。

1.您是否使用源代码管理？我使用过商业源代码管理包，也使用过免费的CVS，让我告诉您，CVS很好。但是，如果您没有源代码控制，那么试图让程序员协同工作就会有压力。程序员无法知道其他人做了什么。错误是不能轻易改正的。源代码控制系统的另一个巧妙之处是，源代码本身会在每个程序员的硬盘上签出-我从来没有听说过使用源代码控制的项目丢失了很多代码。

2.你能一步到位吗？我的意思是：从最新的源快照构建发货版本需要几个步骤？在优秀的团队中，您可以运行一个脚本，它从头开始执行完整的签出，重新构建每一行代码，生成各种版本、语言和#ifdef组合的exe，创建安装包，并创建最终的媒体-CDROM布局、下载网站等等。

如果该过程采取任何一个以上的步骤，都容易出错。当您接近交付时，您希望有一个非常快的周期来修复“最后”的bug、生成最终的exe等。如果需要20个步骤来编译代码、运行安装构建器等，您会发疯的，并且会犯一些愚蠢的错误。

正是出于这个原因，我工作的上一家公司从WISE切换到了InstallShield：我们要求安装过程能够从脚本使用NT调度器在一夜之间自动运行，而WISE不能在一夜之间从调度器运行，所以我们放弃了它。(WISE的好心人向我保证，他们的最新版本确实支持夜间构建。)

3.你每天都做构建吗？当您使用源代码管理时，有时一个程序员不小心签入了一些破坏构建的东西。例如，他们添加了一个新的源文件，并且一切都在他们的机器上编译得很好，但是他们忘记了将源文件添加到代码存储库。所以他们锁上机器回家，忘乎所以，高兴地回家。但是其他人都不能工作，所以他们也不得不回家，不开心。

破坏构建是如此糟糕(并且如此常见)，以至于它有助于进行日常构建，以确保没有任何破坏不被注意到。在大型团队中，确保故障立即修复的一个好方法是每天下午(比方说)在午餐时间进行每日构建。每个人在午饭前都尽可能多地办理登机手续。当他们回来的时候，建造就完成了。如果成功了，那就太好了！每个人都会查看源代码的最新版本，然后继续工作。如果构建失败，您可以修复它，但每个人都可以继续使用源代码的预构建、完整版本。

在Excel团队中，我们有一条规则，无论谁破坏了构建，作为他们的“惩罚”，都要负责照看构建，直到其他人破坏它。这是一个很好的激励，不会破坏构建，也是在构建过程中轮换每个人的好方法，以便每个人都了解它是如何工作的。

4.您有bug数据库吗？我不在乎你说什么。如果您正在开发代码，即使是在一个一个人的团队中，如果没有一个列出代码中所有已知bug的有组织的数据库，那么您将交付低质量的代码。许多程序员认为他们可以将错误列表牢牢记在脑海中。胡说八道。我一次只能记住两三个bug，第二天早上，或者在运输的匆忙中，它们就被遗忘了。您绝对必须正式跟踪错误。

错误数据库可以很复杂，也可以很简单。最低限度有用的错误数据库必须包含每个错误的以下数据：

如果错误跟踪软件的复杂性是阻止您跟踪错误的唯一原因，那么只需制作一个包含这些关键字段的简单的5列表格，然后开始使用它。

5.您会在编写新代码之前修复错误吗？Microsoft Word for Windows的第一个版本被认为是一个“死亡行军”项目。这花了很长时间。它一直在滑落。整个团队都在荒唐地工作几个小时，项目再次被推迟，压力令人难以置信。几年后，当这件该死的东西终于上市时，微软把整个团队送到坎昆度假，然后坐下来进行了认真的自我反省。

他们意识到的是，项目经理是如此坚持遵守“时间表”，以至于程序员只是匆忙地完成了编码过程，编写了非常糟糕的代码，因为错误修复阶段不是正式时间表的一部分。没有人试图将错误数量控制在最低水平。恰恰相反。故事是这样的，一位程序员，他必须编写代码来计算一行文本的高度，他只需编写“Return 12；”，然后等待关于他的函数并不总是正确的bug报告。该时间表只是一份等待变成错误的功能清单。在尸检中，这被称为“无限缺陷方法论”。

为了纠正这个问题，微软普遍采用了一种叫做“零缺陷方法论”的方法。公司里的许多程序员都咯咯地笑了起来，因为这听起来像是管理层认为他们可以通过执行指令来减少错误数量。实际上，“零缺陷”意味着在任何给定的时间，在编写任何新代码之前，最优先考虑的是消除bug。原因如下。

通常，在修复bug之前等待的时间越长，修复它的成本(在时间和金钱上)就越高。

例如，当您犯了编译器捕获到的拼写错误或语法错误时，修复它基本上是微不足道的。

当您在第一次尝试运行代码时发现代码中的错误时，您将能够在任何时间内修复它，因为所有代码在您的脑海中仍然记忆犹新。

如果您在几天前编写的一些代码中发现了bug，您将需要一段时间才能找到它，但是当您重新阅读您编写的代码时，您会记住所有事情，并且能够在合理的时间内修复该bug。

但是，如果您在几个月前编写的代码中发现了错误，您可能已经忘记了关于该代码的很多事情，而且修复起来要困难得多。到那时，您可能正在修复其他人的代码，他们可能正在阿鲁巴度假，在这种情况下，修复错误就像科学一样：您必须缓慢、有条不紊、细致，而且您不能确定需要多长时间才能发现解决方法。

如果您在已经发布的代码中发现了错误，那么修复它将会产生难以想象的费用。

这是立即修复错误的一个原因：因为它花费的时间更少。还有另一个原因，这与这样一个事实有关，即预测编写新代码需要多长时间比修复现有的bug更容易。例如，如果我让您预测编写代码对列表进行排序需要多长时间，您可以给我一个相当好的估计。但是，如果我问您如何预测如果安装了Internet Explorer5.5，您的代码不能工作的地方需要多长时间才能修复错误，您甚至无法猜测，因为您不知道(根据定义)是什么导致了错误。可能需要3天才能找到它，也可能需要2分钟。

这意味着，如果您的计划中有许多错误需要修复，那么该计划就是不可靠的。但是，如果您已经修复了所有已知的错误，并且只剩下新的代码，那么您的日程安排将会令人吃惊地更加准确。

保持错误数量为零的另一件好事是，您可以更快地对竞争做出反应。一些程序员认为这就是让产品随时准备发货。然后，如果您的竞争对手引入了一个夺走您客户的杀手级新功能，您可以只实现该功能并当场发布，而不必修复大量累积的错误。

6.你们有最新的日程安排吗？这就把我们带到了日程安排上。如果您的代码对业务非常重要，那么知道代码何时执行对业务很重要的原因有很多。程序员在制定时间表方面是出了名的暴躁。“做完了就做好了！”他们对商人大喊大叫。

不幸的是，这并不能解决问题。在发布代码之前，业务需要做出太多的计划决策：演示、贸易展览、广告等等。要做到这一点，唯一的方法就是制定一个时间表，并使其保持最新。

制定时间表的另一个关键是，它会迫使你决定要做哪些功能，然后它会迫使你挑选最不重要的功能并将它们删减，而不是陷入功能障碍(也就是。范围爬行)。

遵守时间表并不难。请阅读我的文章“无痛软件时间表”，它描述了一种制定出色时间表的简单方法。

7.你们有规格书吗？写说明书就像用牙线清洁牙齿：每个人都同意这是件好事，但没有人这么做。

我不确定为什么会这样，但可能是因为大多数程序员讨厌编写文档。因此，当团队完全由程序员组成时，他们更喜欢用代码而不是文档来表达他们的解决方案。他们更愿意潜心编写代码，而不是先生成规范。

在设计阶段，当您发现问题时，只需编辑几行文本即可轻松解决这些问题。一旦编写了代码，修复问题的成本就会大大增加，无论是在情感上(人们讨厌扔掉代码)，还是在时间上，因此实际修复问题是有阻力的。不是根据规范构建的软件通常最终设计得很糟糕，进度也会失控。这似乎是Netscape的问题所在，前四个版本发展得如此混乱，以至于管理层愚蠢地决定扔掉代码，重新开始。然后他们用Mozilla重新犯了这个错误，创造了一个失去控制的怪物，花了几年时间才达到阿尔法阶段。

我最喜欢的理论是，这个问题可以通过教育程序员成为不那么不情愿的作家来解决，方法是让他们去参加一个密集的写作课程。另一种解决方案是聘请聪明的项目经理来制作书面规范。在任何一种情况下，您都应该执行简单的规则“没有规范就没有代码”。

8.程序员是否有安静的工作环境？通过为知识型员工提供空间、安静和隐私，可以提供广泛记录的工作效率提升。经典的软件管理书籍Peopleware详细记录了这些生产力优势。

这就是问题所在。我们都知道，知识工作者最好的工作方式是进入“流动”，也就是所谓的“在区域”，在那里他们完全专注于自己的工作，完全脱离自己的环境。他们忘记了时间，通过绝对的集中精力生产出很棒的东西。这是他们完成所有富有成效的工作的时候。作家、程序员、科学家，甚至篮球运动员都会告诉你自己身处这个区域。

问题是，进入“区域”并不容易。当你试着测量它时，它看起来平均需要15分钟才能以最高的生产力开始工作。有时，如果你很累，或者那天已经做了很多创造性的工作，你就是无法进入状态，剩下的工作日时间你就是在闲逛、看网页、玩俄罗斯方块。

另一个问题是很容易被踢出禁区。噪音、电话、外出吃午饭、不得不开车5分钟去星巴克喝咖啡、同事的打扰--尤其是同事的打扰--所有这些都把你赶出了这个区域。如果一位同事问了你一个问题，只打断了你1分钟，但这严重地把你踢出了禁区，以至于你花了半个小时才能恢复工作效率，你的整体工作效率就陷入了严重的麻烦之中。如果你处在一个嘈杂的牛棚环境中，就像喝咖啡的互联网公司喜欢创造的那样，营销人员在程序员旁边打电话尖叫，你的生产力将会大幅下降，因为知识型员工会一次又一次地被打断，永远不会进入这个区域。

对于程序员来说，这尤其困难。工作效率取决于能够同时处理短期记忆中的许多小细节。任何形式的干扰都可能导致这些细节崩溃。当您恢复工作时，您不记得任何细节(如您使用的局部变量名，或者您在实现该搜索算法时处于什么位置)，并且您必须不断查找这些内容，这会大大降低您的速度，直到您恢复速度。

这是简单的代数。让我们这样说(证据似乎表明)，如果我们打断一个程序员，哪怕只有一分钟，我们真的会浪费掉15分钟的生产力。在这个例子中，让我们把两个程序员Jeff和Mutt放在一个标准的Dilbert小牛肉育肥农场中紧挨着的开放小隔间里。Mut不记得strcpy函数的Unicode版本的名称。他可以查一查，这需要30秒，或者他可以问杰夫，这需要15秒。因为他就坐在杰夫旁边，他问杰夫。Jeff分心了，失去了15分钟的工作效率(为了节省Mutt 15秒)。

现在让我们把他们搬到有墙有门的单独的办公室里。现在，当Mutt记不起函数的名称时，他可以查找它，这仍然需要30秒，或者他可以询问Jeff，现在需要45秒，并且需要站立(考虑到程序员的平均体能，这不是一项容易的任务！)。所以他查了查。所以现在Mutt失去了30秒的生产力，但是我们为Jeff节省了15分钟。啊！

9.你会使用金钱能买到的最好的工具吗？用编译语言编写代码是仍不能在普通家用计算机上立即完成的最后几件事之一。如果您的编译过程花费的时间超过几秒钟，那么购买最新最好的计算机将会节省您的时间。如果编译哪怕只需要15秒，程序员在编译器运行时就会感到厌烦，转而阅读洋葱，这会让他们全神贯注，并扼杀几个小时的生产力。

使用单个监视器系统调试GUI代码即使不是不可能，也是很痛苦的。如果您正在编写GUI代码，两个监视器将使事情变得容易得多。

大多数程序员最终不得不操作图标或工具栏的位图，而大多数程序员没有一个好的位图编辑器可用。试图使用Microsoft Paint操作位图是个笑话，但这是大多数程序员必须做的。

在我上一份工作中，系统管理员不断向我发送自动垃圾邮件，抱怨我使用的不只是…。获取此…。服务器上有220 MB的硬盘空间。我指出，考虑到目前硬盘的价格，这个空间的成本明显低于我使用的卫生纸的成本。即使花10分钟清理我的目录也是对生产力的极大浪费。

顶尖的开发团队不会折磨他们的程序员。即使是使用功能不足的工具造成的小挫折也会累积起来，让程序员变得暴躁和不高兴。而脾气暴躁的程序员是效率低下的程序员。

要添加到所有这些…中，请执行以下操作。程序员很容易被贿赂，给他们提供最酷、最新的东西。这是让他们为你工作的一种比实际支付有竞争力的工资便宜得多的方式！

10.你们有测试员吗？如果您的团队没有专门的测试人员，每两到三个程序员至少有一个，那么您要么是在销售有缺陷的产品，要么是在浪费钱，让100美元/小时的程序员来做30美元/小时测试人员可以完成的工作，这是浪费钱。在测试人员上的节俭是如此离谱的虚假经济，以至于我简直被打动了，以至于更多的人没有认识到这一点。

阅读我写的一篇关于这个主题的文章“你没有测试员的五大(错误)原因”。

11.新应聘者在面试期间会编写代码吗？你会雇一个魔术师而不让他们给你表演一些魔术吗？当然不是。

你会不会在不品尝他们的食物的情况下为你的婚礼雇一个宴席承办人？我怀疑。(除非是玛吉阿姨，如果你不让她做她“有名的”切碎肝蛋糕，她会永远恨你的。)。

然而，每天聘用程序员都是基于一份令人印象深刻的简历，或者是因为面试官喜欢与他们聊天。或者他们会被问到一些琐碎的问题(“CreateDialog()和DialogBox()有什么不同？”)。这可以通过查看文档来回答。你不关心他们是否记住了成千上万关于编程的琐事，你关心的是他们是否能够产生代码。或者，更糟糕的是，他们被问到“啊哈！”问题：当你知道答案时，这些问题看起来很容易，但如果你不知道答案，它们就是不可能的。

拜托，别再这么做了。在面试期间做任何你想做的事，但是让应聘者写一些代码。(有关更多建议，请阅读我的游击队面试指南。)。

12.你会做走廊可用性测试吗？走廊可用性测试是指你抓住走廊里经过的下一个人，强迫他们尝试使用你刚刚写的代码。如果你对5个人这样做，你将学到95%关于代码中可用性问题的知识。

好的用户界面设计并不像你想象的那么难，如果你想让客户喜欢并购买你的产品，这是至关重要的。您可以阅读我的关于UI设计的免费在线书籍，这是一本程序员的简短入门读物。

但是，用户界面最重要的一点是，如果您向少数人展示您的程序(实际上，五六个就足够了)，您将很快发现人们遇到的最大问题。请阅读雅各布·尼尔森(Jakob Nielsen)解释原因的文章。即使你的UI设计技能不足，只要你强迫自己做走廊可用性测试，这是免费的，你的UI就会好得多。