【IT168 技术文章】
有没有听说过SEMA？这可是衡量一个软件开发组好坏的很深奥的系统。别介，等一下！别按那个联接！ 给你六年你也搞不清这玩意。所以我自己随便攒了一套衡量系统，信不信由你，这系统，三分钟就可掌握。你可以把省下的时间去读医学院了（译注：美国的医学院可是要读死人的！）。
Joel 衡量法则
你们用不用源文件管理系统？
你们可以把整个系统从源码到ＣＤ映像文件一步建成吗？
你们每天白天都把从系统源码到ＣＤ映像做一遍吗？
你们有软件虫管理系统吗？
你们在写新程序之前总是把现有程序里已知的虫解决吗？
你们的产品开发日程安排是否反映最新的开发进展情况？
你们有没有软件开发的详细说明书？
你们的程序员是否工作在安静的环境里？
你们是否使用现有市场上能买到的最好的工具？
你们有没有专职的软件测试人员？
你们招人面试时是否让写一段程序？
你们是否随便抓一些人来试用你们的软件？
“Joel 衡量法则”好就好在你只需照着逐条回答以上问题，然后把所答为“是”的问题算成一分，再加起来就可以了，而不需要去算什么每天写的程序行数或程序虫的平均数等等。但咱丑话说在前面，可别用“Joel 衡量法则”去推算你的核电站管理程序是否可靠。
如果你们得了１２分，那是最好，得了１１分还过得去，但如果只得了１０分或低于１０分，你们可能就有很严重的问题了。严酷的现实是：大多数的软件开发公司只能得到２到３分。这些公司如果得不到急救可就玄了，因为像微软这样的公司从来就没有低过１２分。
当然，一个公司成功与否不仅仅只取决于以上标准。比如，让一个管理较好的软件公司去开发一个没有人要的软件，那开发出来的软件也只能是没有人要。或反过来，一帮软件痞子以上标准一条也达不到，没准照样也能搞出一个改变世界的伟大软件。但我告诉你，如果不考虑别的因素，你只要能达到以上１２条准则，你的团队就是一个可以准时交活的纪律严明的好团队。
1. 你们用不用源文件管理系统？
我用过商业化的源文件管理系统，我也用过免费的系统，比如CVS，告诉你吧，CVS挺好用。但如果你根本就没有用源文件管理系统，那你就是累死了也没法让你的程序员出活：他们没法知道别人在改动什么源文件，写错了的源文件也没法恢复。
使用源文件管理系统还有一大好处是，由于每一位程序员都把源文件从源文件管理系统里提出来放到自己的硬盘里，几乎不会发生丢失源文件的事，最起码我还没听说过。
2. 你们可以把整个系统从源码到ＣＤ映像文件一步建成吗？
这句话问的问题是：从你们最新的源码开始到建立起能够交出去的最后文件，你们有多少步骤要做？ 一个好的团队应该有一个批处理程序一步便可将所有的工作做完，像把源文件提取出来，跟据不同的语言版本要求（英文版，中文版），和各种编译开关（#ifdef）进行编译，联接成可执行文件，标上版本号，打包成ＣＤ映像文件或直接送到网站上去，等等等等。
如果这些步骤不是一步做完，就有可能出人为差错。而且当你很接近产品开发尾声的时侯，你可能很急于把最后几个虫解决，然后尽快地交活。如果这时候你需要做２０步才能把最终文件制出来，你肯定会急得要命，然后犯一些很不该犯的错误。
正因为这个原因，我工作的前一个公司从用WISE改用InstallShield：我们必需要让我们的批处理程序完全自动化地，在夜里，被NT scheduler起动把最终文件制成，WISE不能被NT scheduler启动而InstallShield可以，我们只能把WISE扔掉。（WISE的那帮家伙向我保证他们的下一代产品一定支持在夜里自动运行.)
3. 你们每天白天都把从系统源码到ＣＤ映像做一遍吗？
你们有没有遇到过这样的事情：一个程序员不小心把有毛病的源码放进源文件管理系统，结果造成最终文件没法制成。比如，他建立了一个新源文件但忘了把它放进源文件管理系统，然后他高高兴兴锁机回家了，因为在他的机器上整个编译得很好。可是别人却因为这没法工作下去了，也只好闷闷地回家了。
这种造成最终文件没法制成的情况很糟糕，但却很常见。如果每天在白天就把最终文件制一遍的话，就可以让这种事不造成太大危害。在一个大的团队里，要想保证有毛病的源码及时得到纠正，最好每天下午（比如午餐时）制一下最终文件。午餐前，每个人都尽可能地把改动的源文件放到源文件管理系统里，午餐后，大家回来，如果最终文件已经制成了，好！这时大家再从源文件管理系统里取出最新的源文件接着干活。如果最终文件制作出错，出错者马上修正，而别人还可接着用原有的没问题的源程序干活。
在我以前曾干过的微软Excel开发组里，我们有一条规定：谁造成最终文件制作出错，谁就得被罚去负责监视以后的最终文件制作过程，直到下一位造成最终文件制作出错的人来接任他。这样做不仅可以督促大家少造成最终文件制作出错，而且可以让每个人都有机会去了解最终文件制作过程。
如果想更多了解这个话题，可以读我的另一篇文章 Daily Builds are Your Friend.
4. 你们有软件虫管理系统吗？
不论你有任何借口，只要你写程序，哪怕只是一个人的小组，如果你没有一个系统化的管理软件虫的工具，你写的程序的质量一定高不了。许多程序员觉得自己可以记得自己的软件虫。没门！我从来记不住超过２到３个软件虫。而且第二天早上起床后忙着去买这买那，好不容易记住的软件虫早忘掉了。你绝对需要一个系统来管住你的那些虫。
软件虫管理系统功能有多有少。但最少要管理以下几种信息：
如何重复软件虫的详细步骤
正常情况（无虫）应是怎样
现在情况（有虫）又是怎样
谁来负责杀虫
问题有没有解决
如果你觉得用软件虫管理系统太麻烦，可以简化一下，建立一个有以上５列的表来用就行了。
如果想更多了解这个话题，可以读我的另一篇文章Painless Bug Tracking.
5. 你们在写新程序之前总是把现有程序里已知的虫解决吗？
微软Windows Word的第一版的开发项目曾被认为是“死亡之旅”项目。好象永远也做不完，永远超时。所有人疯狂地工作，可怎么也完成不了任务。整个项目一拖再拖，大家都觉得压力大得受不了。最后终于做完了这个鬼项目，微软把全组送到墨西哥的Cancun去度假，让大家坐下来好好想想。
大家意识到由于项目经理过于强求程序员们按时交活，结果大家只能匆匆地赶活，写出的程序毛病百出。由于项目经理的开发计划并没有考虑杀虫的时间，大家只能把杀虫的任务往后推，结果虫越积越多。有一个程序员负责写计算字体高度的程序，为了图快，居然写一行“return 12;”了事。他指望以后的质检人员发现这段程序有毛病后报告他再改正。项目经理的开发计划事实上已变成一个列写程序功能的清单，而上面列的所谓程序功能迟早都会成为软件虫。在项目总结会上，我们称这种工作方法为“绝对劣质之路”。
为了避免再犯这个错误，微软制定了“零缺陷策略”。许多程序员嘲笑这个策略，觉得经理们似乎在指望靠行政命令来提高产品质量。而事实上“零缺陷策略”的真正含义是：在任何时候，都要把解决现有程序里的问题作为首要问题来抓，然后再去写新程序。
