最近评论
正在载入评论列表...
2000年8月9日，星期三
你曾经听说过SEMA吗？[1]它是一个相当深奥的系统，用于测试软件团队优良程度。不，等一下！不要去读SEMA！要理解这个东西就得花大约6年的时间。因此，我自己提出了一套不很严格的宽松测试来评估一个软件团队的质量。该测试的闪光之处在于它只需花费大约三分钟的时间。将节省下来的所有时间利用起来，你就可以进入医学院了。
Joel测试
1．使用源控制机制吗？
2．能一步完成连编吗？
3．每天都做连编吗？
4．有故障信息数据库吗？
5．在编写新代码之前修复故障吗？
6．有最新的进度表吗？
7．有规格说明书吗？
8．程序员拥有安静的工作环境吗？
9．你用到了你资金能力内可买到的最好工具吗？
10．有测试人员吗？
11．新聘人员在试用期写代码吗？
12．进行走廊可用性测试吗？
Joel测试的巧妙之处在于，针对每个问题，都可以很容易得到“是”或者“不”的回答，没必要弄清每天的代码行，或者每个测试点的平均故障数。对每个做出“是”的回答，给团队加上一分。Joel测试的不足之处是，确实不应该用它来保证核动力工厂软件是安全的。
得12分是极好的，11分可以容忍，但10分或者更低就是严重的问题了。现实情况是，大多数软件机构正运转在2或3分上，它们需要正式的帮助，因为像Microsoft这样的公司全天候运转在12分上。
当然，这些内容不是决定成功或者失败的惟一因素。特别是，假设一个大型的软件团队正在努力开发一个没人想要的产品，对了，人们就是不会要它。这就好比是一支由“枪手”组成的队伍，他们做的事情与此毫不相干，却仍然设法生产能够改变世界的令人难以置信的软件。但是，万事万物都有可比性，如果将这12件事情办妥了，那么就有了一个可以随时投入使用的训练有素的团队。
1．使用源控制机制吗
我使用过商业版本的源控制包与免费的CVS[2]，并且，我要说CVS不错。但是，如果不使用源控制，那就得十分强调尽力让程序员在一起工作。程序员没有办法知道其他人员做了什么，所以不容易进行错误回滚。源控制系统的另外一个巧妙之处在于，可保证源代码在每个程序员的硬盘上都是经过自动确认了的——我从来没有听说使用源控制的项目丢失过许多代码。
2．能一步完成连编吗
对于这一点，我的意思是：从最新的源快照进行一次可分发的连编，需要多少个步骤？一个优秀的团队仅有一个能够做从头至尾的完全校验的有效脚本；可重建每个代码行；按所有不同的版本、语言与#ifdef组合来建立EXE文件；创建安装包；生成最终介质——CD-ROM规划；下载Web站点，等等。
如果这样的过程需要多步才能完成，那么就很可能出错，并且越接近产品分发时刻，就越希望修复“最后”故障、形成最终EXE文件等操作所经历的周期会更短一些。如果要用20步才能完成代码的编译与安装程序的生成等任务，那么你因为感到烦躁而很可能犯低级错误。
正是因为这个原因，我供职的最后一家公司就从当初使用Wise到现在改用InstallShield了：我们要求安装过程能够通过使用NT调度表通宵自动地从脚本运行，而Wise不能在晚上从调度表启动，因此我们将它扔掉了。（友善的Wise人向我保证，他们的最新版本一定支持夜晚连编功能。）
3．每天都做连编吗
使用源控制时，程序员时常不经意地加入一些东西，导致连编中断。比如说，他们添加了一个新的源文件，但是忘记了将该源文件添加到代码库中去。这在他们自己机器上编译是很好的，于是，他们锁上机器回家去了，心情舒畅而惬意。不过，别人却不能工作，但也只好回家去，心情郁闷而忧心忡忡。
中断连编过程是如此有害（同时也如此常见），以致它反而有助于保证每天的连编不至于出现中断没有被觉察的情况。在大型软件团队中，确保中断得以立即修复的一条很好的途径是，在每天的午餐时间实施每天都要进行的连编过程。每个人在午餐之前都尽可能多地进行加注新内容的工作。当他们回来时，兴许连编已经做完了。要是这个办法可行，就好极了！大家在核实最新的源文件版本以后继续工作。如果连编失败了，就得进行修复，不过，也可以从连编过的没有发生中断的源文件版本重新再来。
我给Excel开发团队制订了一条规则，无论谁中断了连编，都要负责担当连编操作的临时保姆以示“惩戒”，直到有别人中断连编过程为止。这是一条激励大家不要中断连编过程的好机制，也是让大家轮流进入连编进程的好途径，从而使每个人弄清连编是如何进行的。
关于每日连编方面的更多内容，可阅读我写的《每日连编是朋友》[3]一文。
