约耳测试：迈向高品质的12个步骤

作者：周思博(Joel Spolsky)
译：Paul May 梅普华
编辑： Nick Wong
2000， 8， 9

听说过SEMA吗？这是一套相当深奥的系统，可以测量软体团队的好坏。等一下！不要急着连过去看。光是要搞懂那东西大概就要花上六年了。所以我自己有一套无责任的简易方法来衡量软体团队的品质。这套方法的好处是只要花3分钟左右。省下的时间足够让你念趟医学院。

约耳测试(Joel Test)

你有使用原始码控制系统吗？
你能用一个步骤建出所有结果吗？
你有没有每天都重新编译建立(daily builds)吗？
你有没有问题追踪资料库(bug database)？
你会先把问题都修好之后才写新的程式吗？
你有一份最新的时程表吗？
你有规格吗？
程式人员有没有安静的工作环境？
你有没有用市面上最好的工具？
你有没有测试人员？
有没有在面试时要求面试对象写程式？
有没有做走廊使用性(hallway usability)测试？

约耳测试的好处是每个问题都很容易回答是或否。你不必计算每天写的程式行数或是每个转折点的平均问题数量。只要答「是」就加1分。约耳测试的缺点是_绝对不能_ 用来确保核电厂的安全性。

得12分是完美，11分勉强可接受，不过10分以下(含10分)就表示问题大了。事实上大部份软体组织都只拿到2或3分，这些组织都_岌岌可危_ ，因为微软随时都是以12分的水准运作。

当然啦，这些并不是决定成败的唯一因素：特别是当你的优秀团队做些没人要的产品时(对，没人要)。另外也可能有那种「高手」团队，即使完全不鸟这些东西却还是能做出改变世界的梦幻软体。不过除此之外其他人都一样，如果你能把这12件事做好，就能建立一个能稳定出货的纪律团队。

1.你有使用原始码控制系统吗？
我用过一些商用原始码制系统也用过免费的CVS，我可以告诉你CVS相当_不错_ 。不过如果你没有原始码控制系统，当需要程式人员合作时你就会被压垮了。程式人员没法子知道其他人做了些什么。也不能轻易回复成出错前的状态。原始码控制系统还有另一个优点，就是原始码会被登出(check out)到各个程式人员的硬碟里– 我还没看过哪个用了原始码控制的专案会遗失大量程式。

2.你能用一个步骤建出所有结果吗？
我的意思是：从最新的原始码快照开始，要花多少步骤才能建立出货用的软体？好的团队会有单个脚本档案，只要执行这个档案，就会从头登出所有档案，编译每一行程式，建立执行档(包含所有不同版本，语言以及#ifdef组合)，制作安装程式，并且产生出最后要用的媒体形式 – 光碟片编排，网站下载或是其他各种形式。

如果这个程序不只一个步骤就会容易出错。另外当出货时程紧逼时，修正「最后的」问题，制作最终执行档等等的过程要能飞快地完成。如果程式编译和安装档制作等动作要20个步骤才能完成，你一定会急疯掉并且做出一些蠢事。

就是为了这一点，我前一家公司把原本用的WISE换成InstallShield：我们需要能透过NT工作排程器，在晚上用描述档自动执行的安装制作程序，由于WISE不能透过工作排程器半夜执行，所以我们就把它丢掉了。(亲切的WISE员工跟我保证他们的最新版一定会支援夜间执行。)

3.你有没有每天都重新编译建立(daily builds)吗？
在使用原始码控制工具时，有时候程式人员会不慎登入(check in)某些内容而导致编译失败。举例来说，某人新增加了一个原始程式档，整个程式在他的机器上都能正常编译，可是却忘记把新增的程式档加到原始码控制程式库中。结果这位仁兄健忘并快乐地锁上机器回家了。其他人都不能做事，所以也只好很不爽地回家。

导致编译失败非常糟糕(又经常发生)，这时每天重新编译建立就很有帮助了。它能保证不会有漏网之鱼。在大型的团队中，要确保能立即修正编译失败的最佳方法就是每天下午(像是午餐时间)重新编译。大家在午餐前尽可能的登入档案。等大家回来的时候已经编译完毕。如果结果正常，很好！大家可以登出最新版的原始码继续工作。如果有问题就去把它搞定，而其他人还可以用前一版没问题的程式继续干活。

我们Excel团队有个规定，导致编译失败的人必须从此负责重新编译的动作(作为处罚)，一直到有其他人出错为止。这是个让人不要导致编译失败的好诱因，同时是个让大家轮流处理重新编译的好方法，这样大家都会知道怎么做。

我这篇文章里有更多每日重新编译的资料：[每日编译是你的好朋友](/wiki/The_Joel_on_Software_Translation_Project:%E6%AF%8F%E6%97%A5%E7%B7%A8% E8%AD%AF “The Joel on Software Translation Project:每日编译”)。

4.你有没有问题追踪资料库(bug database)？
不管你说什么。只要你在写程式(只有一个人写也一样)，如果没有一套良好的资料库列出程式中所有的问题，一定会产生品质低劣的程式码。很多程式人员自认能把问题清单记在脑里。才怪。我从来没法子一次记住超过二或三个问题，而且会在第二天早上或是赶着出货时把它们全部忘掉。你一定要正式的记录问题。

问题资料库可大可小。一个最简化的有效问题资料库必须包含每个问题的下列资料：

1. 重现问题的完整步骤
2. 应该看到的行为
3. 实际看到的(有问题的)行为
4. 被指派的负责人
5. 是否已修正

如果你是觉得问题追踪软体太复杂才不追踪问题，建个5栏的表，填上这些重要栏位然后_开始用吧_ 。

想深入了解问题追踪，请参阅[无痛错误追踪](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E9%8C%AF%E8%AA%A4%E8%BF%BD% E8%B9%A4 “The Joel on Software Translation Project:无痛错误追踪”)。

5.你会先把问题都修好之后才写新的程式吗？
古早第一版的Microsoft Word for Windows被视作为「死亡行军」型专案。进度一直落后。整个团队的工作时间长得离谱，专案却一延再延三延，大家都承受到无比的压力。拖了几年后那个鬼东西终于上市了，微软就把整个团队送到Cancun(墨西哥著名海滩)渡假，然后再坐下来做些深度反省。

他们发现专案经理过度坚持要保持「进度」，结果程式人员只能赶工写出烂程式，而且正式的时程并没有包含错误修正的阶段。没有人试图要减少问题数量。而且实际上刚好相反。有个程式人员要写程式计算一行文字的高度，结果他只写了"return 12;“并等问题报告出炉说这个函数功能不对。时程表变成一份等着被转换成问题的功能列表。事后检讨时称之为「无穷错误法」。

为了修正这个问题，微软全面采用所谓的「零错误作法」。很多公司里的程式人员都不禁窃笑，因为听起来像是管理阶层认为能用行政命令降低错误数量。实际上「零错误」是指无论何时都要先修正错误才能写新程式。原因如下。

一般来说，愈晚修正错误，修正所付出的成本(时间及金钱)愈高。

举例来说，当你打错字或出现编译器会发现的语法错误，要修正只是小事一件。

当你的程式第一次执行出错时，应该也能立即改正，因为整个程式还在你脑海里。

如果要为几天前写的程式除错，应该需要回想好一阵子，不过当里重读所写的程式之后，就会记起所有细节并在适当时间内把问题修好。

不过如果你要为_几个月_ 前写的程式除错，很可能已经忘掉了一大半，要修正就是难上加难。你也可能正在替_别人的_ 程式除错，而当事人可能正在阿卢巴渡假，这时候除错就像科学一样：你得条理分明小心翼翼地慢慢来，而且也无法确定要多久时间才能解决。

另外如果要为_已出货_ 的程式除错，要修正问题的代价可是难以估算的。

要立即修正问题的理由之一，就是因为这样做能少花点时间。另一个理由是写新程式的时间还比修正现有错误的时间较易估计。举例来说，如果要你估计写个串列排序的程式需要多久，你应该能估算得相当准确。不过如果说你的程式在装了Internet Explorer 5.5之后有问题，要估计需要多久才能修好这个问题，恐怕你连_猜_ 都不会，因为你不知道(当然不知道)问题_哪儿_ 来的。要找出问题可能要花3天，也可能只花2分钟。

我的意思是如果你的计划时程里有很多错误待修正，这种时程是不太可靠的。不过如果把_已知_ 的错误都修好了，所剩的就只要新程式了，那么你的时程就会变得非常准确。

把错误数量维持在零还有另外一个优点，就是面对竞争时反应更快。有些程式人员认为这样做能让产品_随时能推出_ 。所以如果竞争者推出某个杀手级新功能来抢客户，你只要把那个功能加上去就可以立即出货，不必去修正累积下来的大量问题。

6.你有一份最新的时程表吗？
我们在这里要谈谈时程表。如果你的程式对公司非常重要，有太多理由可以说明预知程式完成时点有多么重要。程式人员不爱订定时程可是恶名昭彰。他们会对业务大叫：「该完成的时候就会完成！」

但是问题不可能就这样算了。业务人员有太多的计划决策必须远在程式出货之前做决定：展示，商展，广告等等。而做决定的唯一方法就是定出时程并随时更新。

拥有时程的另一个重点是逼你决定要制作哪些功能，并且能逼你_剔除_ 最不重要的功能而避免功能过度膨胀(featuritis，又名scope creep)。

要维护时程表并不困难。请参阅我的文章[无痛软体时程](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E8%BB%9F%E9%AB%94%E6%99%82%E7% A8%8B “The Joel on Software Translation Project:无痛软体时程”)，文中叙述建立好用时程表的简单方法。

7.你有规格吗？
写规格像用牙线：大家都同意这是好事，却没有人真的在做。

我不知道为什么，或许是因为大多数程式人员都讨厌写文件吧。所以当全是程式人员的团体面对问题时，自然倾向用程式码而非文件来表示答案。他们宁愿跳进去写程式也不愿先写规格。

在设计阶段发现问题时，只要改几行就能轻易修正。等程式写出来之后，修正的代价就高得多了，代价包含了情感(人们讨厌抛弃程式码)和时间，所以会抗拒修正问题。通常未依据规格制作的软体最后的设计都很糟，而且进度完全无法控制。这似乎就是发生在Netscape上的问题。它的前四版变得一团乱，结果管理阶层[愚蠢地决定](/wiki/The_Joel_on_Software_Translation_Project:%E4%BD%A0%E7%B5%95%E5%B0%8D%E4%B8%8D% E6%87%89%E8%A9%B2%E5%81%9A%E7%9A%84%E4%BA%8B “The Joel on Software Translation Project:你绝对不应该做的事”)把程式丢掉重新开始。然后他们在Mozilla上又重蹈覆辙，造出了一个无法控制的怪物，而且耗了_几年_ 才进入alpha测试阶段

我的拿手方法是把程式人员送去上密集的写作课程，让他们变得不那么排斥写作，就可以解决这个问题。另一个方法是雇用聪明的专案经理来写规格。不管用哪一种方法，你都应该强制执行「没有规格不写程式」这个简单的规则。

你可以由我写的[四篇系列文章](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E5%8A%9F%E8%83%BD%E8%A6%8F%E6 %A0%BC(%E4%B8%80) “The Joel on Software Translation Project:无痛功能规格(一)")学到所有关于规格的内容。

8.程式人员有没有安静的工作环境？
有大量的文件记载，为知识工作者提供空间安静及隐私可以提升产能。软体管理经典Peopleware大量记录了这种产能上的增益。

这就是问题所在。我们都知道知识工作者进入「状况」(flow，也被称作in the zone)时工作效果最佳，这时候他们会完全与环境脱离，全心专注在工作上。他们忘记时间并透过绝对专注产出极佳成果。他们所有丰富的产出也都是在这个时候完成的。作家，程式人员，科学家，甚至篮球球员都会告诉你进入「状况」的情形。

问题是要进入「状况」不是那么容易。如果你有试着计时，平均大概要15分钟才能开始全速工作。有时如果你累了或是那一天已经有很多创造性的成果，会根本无法进入「状况」，然后看看网页玩玩俄罗斯方块打混过完一天。

还有一个问题就是很容易_脱离_ 「状况」。噪音、电话、同事的中断( 特别是这一点 )都会让你脱离「状况」。假设有个同事问了一个问题让你中断了1分钟，实际上却会让你完全脱离「状况」，得再等半个小时才能回复生产力，结果你的整体产能都出问题了。如果你身在一个喧闹的BULLPEN环境中(像那些一窝蜂(caffeinated)网路公司最爱营造的典型)，行销部门在程式人员旁对着电话大喊，你的产能就像一直被中断的知识工作者一样颠簸，永远无法进入「状况」。

这对程式人员来说更加严重。生产力多寡在于是否能在短期记忆体中处理大量的细节。任何一种中断都会让这些细节完全消失。等你转回来工作时就完全不记得任何细节(比如正在使用的区域变数名称或是搜寻演算法写到哪了)，必须把刚刚的东西找出来，于是速度就放慢下来一直到你回复为止。

这里有个简单的算术。我们可以说(依照陈述所暗示的)虽然仅仅打断程式人员一分钟，事实上是去掉了15分钟的产能。以此为例，假设有两个程式人员Jeff和Mutt，把他们安排在一个标准呆伯特(Dilbert，美国漫画)养牛场里相邻的开放隔间中。Mutt忘记了strcpy函数的Unicode版本拼法。他可以花30秒自己查出来，也可以花15秒问Jeff。由于人就坐在旁边，所以他问Jeff。Jeff分心所以就损失了15分钟的产能(替Mutt省了15秒)。

现在把他们搬到两间有墙有门的独立房间里。如果Mutt忘记那个函数的拼法，他可以花30秒查出来，也可以花45秒过去问Jeff(就典型程式人员的身材来说离开位置并不轻松)。结果他就自己查了。于是Mutt损失30秒的产能，不过却替Jeff省下15分钟。哎呀呀呀！

9.你有没有用市面上最好的工具？
用编译语言撰写程式是一般家用电脑还无法瞬间完成的最后几件事之一。如果你的编译过程超过数秒，去找台最新最棒的电脑可以替你省点时间。如果编译需要超过15秒，程式人员觉得无聊就会跑去看线上新闻The Onion，然后陷在里面耗掉几个钟头的产能。

在单萤幕系统上替GUI程式除错并非绝不可能，不过用起来有够痛苦。如果你在撰写GUI程式，弄两台萤幕会让你轻松许多。

大部份程式人员到最后都得修整图示或工具列所用的图，可是大部份人都没有一个好用的图形编辑器。用微软的小画家修图简直是笑话，不过却是大多数程式不得不做的事。

在我前一家公司，系统管理员会一直送些垃圾信给我，抱怨我在伺服器上使用了超过「220 MB」的硬碟空间。我说依据现在硬碟的价格，这点空间的费用还远比不上我所用的_卫生纸_ 。即使只花10分钟清理目录也是生产力的极大浪费。

一流的开发团队不会虐待他们的程式人员。 即使工具不好所引起的挫败很小，累积起来都会让程式人员心情不爽脾气暴躁。而不爽的程式人员就等于无生产力的程式人员。

除此之外…程式人员也是很容易用最酷最新的东西贿赂的。这可远比再增加薪水叫他们工作要便宜多了！

10.你有没有测试人员？
如果你的团队没有专门的测试人员(至少每两到三个程式人员要配一名)，你要不是推出问题很多的产品，就是浪费钱叫时薪100美元的程式人员去做测试员(时薪30美元)做的事。省测试员绝对不是真省，这实在是再明显不过了。我实在很惊讶很多人却还认不清这一点。

看看[不用测试人员的五大(错误)借口](/wiki/The_Joel_on_Software_Translation_Project:%E4%B8%8D%E7%94%A8%E6%B8%AC%E8%A9%A6%E4%BA%BA% E5%93%A1%E7%9A%84%E4%BA%94%E5%A4%A7(%E9%8C%AF%E8%AA%A4)%E8%97%89%E5%8F% A3 “The Joel on Software Translation Project:不用测试人员的五大(错误)借口”)吧，这是我针对这个题目所写的文章。

11.有没有在面试时要求面试对象写程式？
你可能不叫魔术师先表演几招就直接雇用吗？当然不会。

你可能不先尝尝菜就决定自己婚宴的餐厅吗？我很怀疑。(除非是Marge姑姑，如果不让她弄一道「顶级」碎牛肝饼，她会恨你一辈子)。

尽管如此，现在程式人员是否录用都还是要看履历是否突出，或是因为主试人员面谈聊得很高兴，或是回答些查文件就知道的琐碎问题(比如CreateDialog()和DialogBox()间的差异是什么？)。你根本不会管他们能否背出几百条有关程式设计的琐事，你真正在意的是他们能否写出程式。更糟的情况是问那种「啊！我懂了！」的问题：就是那种知道答案时理所当然，可是不知道答案时却莫名其妙的问题(译注：像是脑筋急转弯)。

拜托_别再这样做了_ 。随便你想怎么面试都行，不过记得一定要让面试者写些程式。(需要更多建议时可以看我写的[软体人员面试教战守则](/wiki/The_Joel_on_Software_Translation_Project:%E8%BB%9F%E9%AB%94%E4%BA%BA%E5%93%A1% E9%9D%A2%E8%A9%A6%E6%95%99%E6%88%B0%E5%AE%88%E5%89%87 “The Joel on Software Translation Project:软体人员面试教战守则”)。)

12.有没有做走廊使用性(hallway usability)测试？
走廊使用性测试 是说到走廊拦住下一位经过的人，然后逼他试用你刚写好的程式。如果你做够五个人，就可以发现程式中95%应注意的使用性问题。

良好的使用者介面设计并没有想像中那么困难，在吸引客户中意并购买产品时又是极为重要的。你可以参阅我写的[免费线上UI设计书](/wiki/The_Joel_on_Software_Translation_Project:%E4%BD%BF%E7%94%A8%E4%BB%8B%E9%9D%A2%E8%A8%AD% E8%A8%88%E6%89%8B%E5%86%8A%E7%AC%AC%E4%B8%80%E7%AB%A0 “The Joel on Software Translation Project:使用介面设计手册第一章”)，是针对程式人员的短篇入门书。

不过处理使用者介面时有一点最重要：如果你把程式展示给少数几个人看(事实上五或六个就够了)，就能快速地发现一般人会遇到的主要问题。Jakob Nielsen的文章中有解释原因。即使你的UI设计技巧不足，只要强逼自己实行不花什么工夫的走廊使用性测试，就会让你的UI水准大幅提升。

约耳测试的四种用法

1. 对你自己的软体组织评分，再把分数给我作为讲八卦的题材。
2. 如果你是一个程式设计团队的经理，可以用它来确保团队能在最佳状态工作。等拿到12分之后，就可以[把程式人员放着不管](http://www.joelonsoftware.com/articles/fog0000000072.html)，专心去避免业务的干扰就好了。
3. 如果你正在决定是否接受一份程式设计的工作，可以问问未来可能的雇主他们能拿几分。如果分数太低时要先确定你有权修正这种问题。否则你将会灰心丧气而且一事无成。
4. 如果你是个正在评估某个程式设计团队价值的投资者，或是你的公司正考虑与其他公司合并，这个测试可以提供快速的判断方法。