Joel On Software---JOEL 测试:改进代码的12个步骤

此节为第一部分的第三节：
JOEL测试：改进代码的12个步骤

JOEL测试
1 、使用源控制代码吗？
2 、能一步完成连编吗？
3 、每天都做连编吗？
4 、有故障信息数据库吗？
5 、在编写新代码之前修复故障吗？
6 、有最新的进度表吗？
7 、有规格说明书吗？
8 、程序员拥有安静的工作环境吗？
9 、你用到了你资金能力内可买到的最好工具吗？
10 、有测试人员吗？
11 、新聘人员在试用期写代码吗？
12 、进行走廊可用性测试吗？

在这一节中例出了JOEL测试的12个步骤，个人觉得确实把一些标准软件测试的精华吸取进去了，却又抛弃了各类标准测试中的过于严格、限制灵活性的部分。当然这也如书中所说的，“Joel测试的不足之处，处是，确实不应该用它来保证核动力工厂软件是安全的”。作为个人来讲，应该把这些测试作为一种软件开发的习惯（当然，只是有些部分哦！~）。

在这里把比较精要的地方记录一下：
1、不使用源控制，程序员没有办法知道其他人员做了什么，所以不容易进行错误回滚。源控制系统的另外一个巧妙之处在于，可保证源代码在每个程序员的硬盘上都是经过自动确认了的。

2、从最新的源快照进行一次可分发的连编，需要多少个步骤？在一个优秀的团队通常会维护一个脚本，通过运行它，可以从头至尾地进行一次检查；重新编译每一个代码行；并按其不同的版本、语言以及条件编译语句#ifdef来生成EXE文件；创建安装包；并且生成最终的表现介质——CD-ROM、下载页面等。如果这样的过程需要多步才能完成，那么就很可能出错，并且越接近产品分发时刻，就越希望修复“最后故障”、形成最终EXE文件等操作所经历的周期会更短一些。JOEL指出不应该有20步。

3、无论谁中断了连编，都要负责修复连编操作，直到有别人中断连编过程为止。这是JOEL在Excel开发团队采用一种激励不要中断连编过程的机制，同时也让大家弄清楚连编是如何进行的。

4、故障信息数据库。一个可用的故障信息数据库必须至少为每个故障包含如下数据：重现故障的完整步骤、预期功能、观察到的（故障）行为、要分配谁、是否已修复。

5、发现故障到准备修复故障之间等待的时间越长，付出的代价（时间与金钱上）就越大。微软普遍采取了一种称之为零缺陷法（zero defects methodology）的措施。零缺陷意味着在任意给定时间点，最需要优先去做的事情是在写任何新的代码之前消除故障。这也可以是一个衡量进度表的标准：如果你已经修复了所有已经知道的故障，并且剩下的就是编写新代码，那么进度表就是极其准确的。

6、拥有一个好的进度表的优点：保证它始终反映最新的项目情况；迫使你做出将要实现什么功能的决定，然后强迫你拣出最不重要的功能，并加以剪除而不是陷入功能沼泽地带（也就是功能范围蔓延开来）。

7、“没有规格说明书就没有代码”。不是根据规格说明书开发出来的软件通常会因设计欠佳而停滞不前，从而使进度失去控制。

8、JOEL举了一个比较好的例子：Mutt记不住Unicode版本的strcpy函数的名字。他可以查询该函数，这要花费30秒钟的时间；他也可以询问Jeff，这得用去15秒钟的时间。既然紧靠Jeff坐着，他选择询问Jeff。不过，Jeff因此显得心烦意乱而丢掉了15分钟的产出（仅仅为了节省Mutt 15秒钟）。然而如果当Mutt去询问Jeff需要45秒钟的时间时，Mutt就会去选择自己去查询了。

9、可以显著地提高开发效率，同时程序员是容易通过给他们提供最棒最新的东西而得到满足的，这是一种远比通过支付极富竞争力的薪力来促使他们为你工作好得多的途径。

10、没有专门的测试人员，意味着要么分发充满故障的产品，要么通过让价值$100/小时的程序员去做那些能够让价值$30/小时的测试人员完成的工作。

11、一定要让应聘者编写一些代码。

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