软件12法则

作者简介： 作者：Joel Spolsky 是纽约市一家小软件公司Fog Creek Software 的创始人。他毕业于耶鲁大学，曾在美国微软公司、Viacom、Juno 任软件设计师及经理。 1. 你们用不用源文件管理系统？ 我用过商业化的源文件管理系统，我也用过免费的系统，比如CVS，告诉你吧，CVS挺好用。但如果你根本就没有用源文件管理系统，那你就是累死了也没法让你的程序员出活：他们没法知道别人在改动什么源文件，写错了的源文件也没法恢复。 使用源文件管理系统还有一大好处是，由于每一位程序员都把源文件从源文件管理系统里提出来放到自己的硬盘里，几乎不会发生丢失源文件的事，最起码我还没听说过。 2. 你们可以把整个系统从源码到CD映像文件一步建成吗？ 这句话问的问题是：从你们最新的源码开始到建立起能够交出去的最后文件，你们有多少步骤要做？ 一个好的团队应该有一个批处理程序一步便可将所有的工作做完，像把源文件提取出来，跟据不同的语言版本要求（英文版，中文版），和各种编译开关（#ifdef）进行编译，联接成可执行文件，标上版本号，打包成CD映像文件或直接送到网站上去，等等等等。 如果这些步骤不是一步做完，就有可能出人为差错。而且当你很接近产品开发尾声的时侯，你可能很急于把最后几个虫解决，然后尽快地交活。如果这时候你需要做20步才能把最终文件制出来，你肯定会急得要命，然后犯一些很不该犯的错误。 正因为这个原因，我工作的前一个公司从用WISE改用InstallShield：我们必需要让我们的批处理程序完全自动化地，在夜里，被NT scheduler起动把最终文件制成，WISE不能被NT scheduler启动而InstallShield可以，我们只能把WISE扔掉。（WISE的那帮家伙向我保证他们的下一代产品一定支持在夜里自动运行) 3. 你们每天白天都把从系统源码到CD映像做一遍吗？ 你们有没有遇到过这样的事情：一个程序员不小心把有毛病的源码放进源文件管理系统，结果造成最终文件没法制成。比如，他建立了一个新源文件但忘了把它放进源文件管理系统，然后他高高兴兴锁机回家了，因为在他的机器上整个编译得很好。可是别人却因为这没法工作下去了，也只好闷闷地回家了。 这种造成最终文件没法制成的情况很糟糕，但却很常见。如果每天在白天就把最终文件制一遍的话，就可以让这种事不造成太大危害。在一个大的团队里，要想保证有毛病的源码及时得到纠正，最好每天下午（比如午餐时）制一下最终文件。午餐前，每个人都尽可能地把改动的源文件放到源文件管理系统里，午餐后，大家回来，如果最终文件已经制成了，好！这时大家再从源文件管理系统里取出最新的源文件接着干活。如果最终文件制作出错，出错者马上修正，而别人还可接着用原有的没问题的源程序干活。 在我以前曾干过的微软Excel开发组里，我们有一条规定：谁造成最终文件制作出错，谁就得被罚去负责监视以后的最终文件制作过程，直到下一位造成最终文件制作出错的人来接任他。这样做不仅可以督促大家少造成最终文件制作出错，而且可以让每个人都有机会去了解最终文件制作过程。 如果想更多了解这个话题，可以读我的另一篇文章 Daily Builds are Your Friend. 4. 你们有软件虫管理系统吗？ 不论你有任何借口，只要你写程序，哪怕只是一个人的小组，如果你没有一个系统化的管理软件虫的工具，你写的程序的质量一定高不了。许多程序员觉得自己可以记得自己的软件虫。没门！我从来记不住超过２到３个软件虫。而且第二天早上起床后忙着去买这买那，好不容易记住的软件虫早忘掉了。你绝对需要一个系统来管住你的那些虫。 软件虫管理系统功能有多有少。但最少要管理以下几种信息： 如何重复软件虫的详细步骤 正常情况（无虫）应是怎样 现在情况（有虫）又是怎样 谁来负责杀虫 问题有没有解决 如果你觉得用软件虫管理系统太麻烦，可以简化一下，建立一个有以上5列的表来用就行了。 如果想更多了解这个话题，可以读我的另一篇文章Painless Bug Tracking. 5. 你们在写新程序之前总是把现有程序里已知的虫解决吗？ 微软Windows Word的第一版的开发项目曾被认为是“死亡之旅”项目。好象永远也做不完，永远超时。所有人疯狂地工作，可怎么也完成不了任务。整个项目一拖再拖，大家都觉得压力大得受不了。最后终于做完了这个鬼项目，微软把全组送到墨西哥的Cancun去度假，让大家坐下来好好想想。 大家意识到由于项目经理过于强求程序员们按时交活，结果大家只能匆匆地赶活，写出的程序毛病百出。由于项目经理的开发计划并没有考虑杀虫的时间，大家只能把杀虫的任务往后推，结果虫越积越多。有一个程序员负责写计算字体高度的程序，为了图快，居然写一行”return 12;”了事。他指望以后的质检人员发现这段程序有毛病后报告他再改正。项目经理的开发计划事实上已变成一个列写程序功能的清单，而上面列的所谓程序功能迟早都会成为软件虫。在项目总结会上，我们称这种工作方法为“绝对劣质之路”。 为了避免再犯这个错误，微软制定了“零缺陷策略”。许多程序员嘲笑这个策略，觉得经理们似乎在指望靠行政命令来提高产品质量。而事实上“零缺陷策略”的真正含义是：在任何时候，都要把解决现有程序里的问题作为首要问题来抓，然后再去写新程序。 为什么要这样做呢？ 一般说来，你越不及时地杀虫，杀虫的代价（时间和金钱）就会越高。比如，你写程序时打错了一个字，编译器马上告诉你，你很容易就把它改正。你刚写好的程序在第一次运行时发现了一个问题，你也很快就能解决它，因为你对你刚写的程序还记忆犹新。如果你运行你的程序时发现了一个问题，可这个程序是几天以前写的，你可能就需要折腾一会儿，还好，你还大致记得，所以不会花太长时间。但如果你在你几个月以前写的程序里发现了问题，就比较难解决了，因为你已经忘了许多细节。这时候，你还没准儿正忙着杀别人程序里的虫呐，因为这家伙到加勒比海阿鲁巴岛度假去了。这时候，解决这一堆问题的难度不亚于从事尖端科学研究。你一定得小心翼翼地，非常系统化地从事，而且你很难知道多长时间你才能把问题解决。还有更糟糕的，你的程序已交到用户手里了，才发现问题，那你就等着掏腰包吧。 总结起来，就一条：越早解决问题，越容易解决。 另外还有一个原因，刚写的程序里发现问题，你能够比较容易地估算解决它的时间。举个例子，如果我问你写一段程序去把一个列表排序需要花多长时间，你可以给我一个比较确切的估计。如果你的程序，在Internet Explorer 5.5安装以后，工作不正常。我问你要多长时间把这个问题解决，你恐怕都估计不出来，因为你根本就不知道是什么原因造成了这个问题。你可能要花三天时间才能解决，也有可能只花两分钟。 这个例子告诉我们，如果你的开发过程中有许多虫没有及时解决，那你的开发计划肯定不可靠。反过来，如果你们已经把已知的虫全部解决了，要做的事只是写新的程序，那你的开发计划就会比较准确。 把已知的虫全部解决，这样做还有一个好处：你可以对竞争对手快速反击。有些人把这叫着“让开发中的产品随时处在可以交给用户的状态”。如果你的竞争对手推出一个新的功能想把你的客户抢走，你可以马上在你的产品里加上这个功能，立刻将新产品交付用户，因为你没有一大堆积累下来的问题要解决。