如果团队没有专门的测试人员（至少为每两个或者三个程序员配备一个测试人员），那么意味着要么分发充满故障的产品，要么通过让价值$100/小时的程序员去从事那些能够让价值$30/小时的测试人员完成的工作而浪费钱财。在测试人员方面吝惜钱财谈不上节俭，这种做法显得不可理喻，我只能是嗤之以鼻地说，较多的人不会认可它。第22章对该内容会有更多的介绍。

 

你会聘用一个魔术师而不叫他露几手戏法吗？当然不会。你会让酒店老板承办婚礼宴席而不品尝他们的菜肴吗？这很难说。（Marge阿姨除外，你要是不让她做她“著名的”碎肝饼，她会嫉恨你一辈子。）

尽管如此，每天仍然有一些程序员是因为持有令人印象深刻的履历或者面试人员喜欢跟他们聊天而被聘用的。或者他们只是被问了一些非常琐碎的问题（比如说“CreateDialog()与DialogBox()之间有什么不同？”），这些问题是可以通过查看文档资料得以作答的。用不着在意他们是否记住了编程方面成千上万的细枝末节，应该在乎的是他们能否构造代码。甚或还有更为糟糕的情况，那就是程序员被问了一些“打哈哈”的问题——这些问题如果你知道答案似乎显得很容易，可要是你不知道答案，要回答出来就显得极为不可能。

务请停止这样的做法。诚然，你可以在面试期间做想做的任何事情，但是一定要让应聘者编写一些代码（关于这方面的更多建议，可阅读我的《面试游击战指南》一文，本书的第20章收录了该文。）

 

走廊可用性测试指的是，在走廊里随便抓一个从身边走过的人，要他试着使用你所编写的代码。如果对5个人进行了这类测试，那么就可以了解隐藏在代码中的95%的可用性问题。

好的用户界面设计并不像你想像的那样难，并且，它对于顾客喜爱与购买你的产品至关重要。我写的关于用户界面设计的书[1]集中叙述了这方面的内容，它是为程序员所写的一个初级读本。

不过对于用户界面最为重要的事情是，如果将程序交给一部分人（事实上，5~6个人就够了）看，那么你会迅速发现人们掌握着最大的问题。关于这方面的原因，可阅读Jakob Nielsen的有关文章[2]。即使你的UI设计技能很缺乏，但是只要强迫自己进行走廊可用性测试（这用不着付出什么代价），那么设计出来的UI将是非常非常好的。

 

1．评价自己的软件机构，并说出是如何评价的，这样我可以与你交流一下了。

2．如果你是程序设计团队的经理，那么使用该测试作为校验表，以保证团队确实在尽可能地发挥作用。如果一开始就评定一个团队为12分，那么可以集中精力不使业务人员去打扰程序员而使他们置身其外[3]。

3．如果你在决定是否接受一项编程活件的话，那么询问你未来的雇主在该测试上的得分情况如何。如果测试的分值太低，那么就要确保自己有权威去修正这种局面。否则，你会面临失败而徒劳无益。

4．如果你是一位正在努力评判某个程序设计团队的价值的投资人，或者你的软件公司正在考虑与另外一家公司合并，那么这个测试可以提供一个快速而简易的尺度。

 

自从Joel测试在2000年8月推出以来，我从世界各地的开发人员那里收到了成堆的汇报各自团队如何评分事宜的电子邮件。尽管结果的分布显得相当均匀，我还是要说，绝大多数分值处在2与3之间的一个位置。嗯！我也收到一些在无组织的“枪手”软件开发实践当中成长起来的开发人员的来信，他们拒绝从那些看起来在Joel测试方面天生只能得低分的公司招揽新活。并且，我还收到一些团队经理给出的杰作，他们以Joel测试作为提高团队素质的进阶过程而推进自己的管理工作。

与此同时，似乎许多软件开发组织已经远远地走出了Joel测试的范畴，而进入复杂的官僚政治动脉硬化苦斗之中。什么时候会出现这种情况是很容易说出的，因为人们在准备开会方面所花的时间比开发软件更多。在Joel测试上得到12分的不错成绩，然后就被多如牛毛的政治活动纠缠得脱不开身而做不了什么事情，这是很有可能发生的一种情况。

没有必要告诉别人是我说了些什么，不过，自上世纪90年代初我在微软公司工作的那个时期以来，所有证据都表明，该公司或多或少地搁浅乃至停滞均是因其过于庞大的规模、内部政治纷争与官僚系统的不检点所致。还需要证据吗？

Tablet PC——这是一种只有微软公司的中层经理们才可能喜爱的东西——似乎设计成了让华盛顿Redmond的程序经理们可以开一整天的会，却不至于使其日常电子邮件处理事宜显得过于滞后。这不单纯只是微软才存在的现象。

如果突然间地发现自己在安装与配置巨无霸软件开发系统或“什么什么可视化企业体系设计大师”之类的软件方面，花费的时间太多，或者说要开始开发产品时还在团队重新学习“极限编程（Extreme Programming）”与UML方面反反复复而让他们脑袋变大，那么即使在Joel测试方面真的做得不错，你还是可能陷入困境。

---

图书导读

当前章节:第3章(4)