软件随想录(local.joelonsoftware.com/wiki)-2000年08月09日 约耳测试：迈向高品质的12个步骤 - The Joel Test: 12 Steps to Bette

2000年08月09日
约耳测试：迈向高品质的12个步骤 -
The Joel Test: 12 Steps to Better Code

 

 

The Joel on Software Translation Project:约耳测试

From The Joel on Software Translation Project

Jump to:
navigation,
search

约耳测试：迈向高品质的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团队有个规定，导致编译失败的人必须从此负责重新编译的动作(作为处罚)，一直到有其他人出错为止。这是个让人不要导致编译失败的好诱因，同时是个让大家轮流处理重新编译的好方法，这样大家都会知道怎么做。

我这篇文章里有更多每日重新编译的资料：每日编译是你的好朋友。

4.你有没有问题追踪数据库(bug database)？

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

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

重现问题的完整步骤
应该看到的行为
实际看到的(有问题的)行为
被指派的负责人
是否已修正
如果你是觉得问题追踪软件太复杂才不追踪问题，建个5栏的表，填上这些重要栏位然后开始用吧。

想深入了解问题追踪，请参阅无痛错误追踪。

5.你会先把问题都修好之后才写新的程序吗？

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

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

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

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

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

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

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

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

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

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

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

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

6.你有一份最新的日程表吗？

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

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

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

要维护日程表并不困难。请参阅我的文章无痛软件日程，文中敘述建立好用日程表的简单方法。

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

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

在设计阶段发现问题时，只要改几行就能轻易修正。等程序写出来之后，修正的代价就高得多了，代价包含了情感(人们讨厌拋弃程序代码)和时间，所以会抗拒修正问题。通常未依据规格制作的软件最后的设计都很糟，而且进度完全无法控制。这似乎就是发生在Netscape上的问题。它的前四版变得一团乱，结果管理阶层愚蠢地决定把程序丟掉重新开始。然后他们在Mozilla上又重蹈覆辙，造出了一个无法控制的怪物，而且耗了几年才进入alpha测试阶段

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

你可以由我写的四篇系列文章学到所有关于规格的內容。

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美元)做的事。省测试员绝对不是真省，这实在是再明显不过了。我实在很惊讶很多人却还认不清这一点。

看看不用测试人员的五大(错误)借口吧，这是我针对这个题目所写的文章。

11.有没有在面试时要求面试对象写程序？

你可能不叫魔术师先表演几招就直接雇用吗？当然不会。

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

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

拜託别再这样做了。随便你想怎么面试都行，不过记得一定要让面试者写些程序。(需要更多建议时可以看我写的软件人员面试教战守则。)

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

良好的使用者介面设计并没有想像中那么困难，在吸引客户中意并购买产品时又是极为重要的。你可以参阅我写的免费在线UI设计书，是针对程序人员的短篇入门书。

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

约耳测试的四种用法

对你自己的软件组织评分，再把分数给我作为讲八卦的题材。
如果你是一个程序设计团队的经理，可以用它来确保团队能在最佳状态工作。等拿到12分之后，就可以把程序人员放著不管，专心去避免业务的干扰就好了。

如果你正在决定是否接受一份程序设计的工作，可以问问未来可能的雇主他们能拿几分。如果分数太低时要先确定你有权修正这种问题。否则你将会灰心丧气而且一事无成。
如果你是个正在评估某个程序设计团队价值的投资者，或是你的公司正考虑与其他公司合并，这个测试可以提供快速的判断方法。
这些网页的內容为表达个人意见。

All contents Copyright 1999-2002 by Joel Spolsky。All Rights Reserved.