无痛功能规格第一篇：何必麻烦呢？

作者：周思博(Joel Spolsky)
译：Paul May 梅普华
编辑：Jeff Wang 王家麒
October 2, 2000
A part of Joel on Software, http://www.joelonsoftware.com

当约耳试验刚发表时，读者反映说执行上最困难的一点就是写规格。看起来规格就像用牙线：大家都知道应该要，却没有人真的在做。

为什么大家不写规格呢？有人声称跳过写规格这个步骤可以节省时间。讲得好像写规格像是什么奢侈品，只有NASA太空梭工程师或为大保险公司工作的人才能做。胡说八道。不写规格是软体专案中 一个最大且不必要的风险 。这就像只在背上挂件衣服就妄想飞越摩哈维沙漠一样的愚蠢。那些不订规格直接写程式的程式员和软体工程师都会自认是神枪手，可以朝背后开枪。才怪。他们根本没有生产力。他们写出烂程式并做出低劣的产品，而且还让专案承受完全可以避免的极大风险。

我认为所有重要的专案(写程式时间超过一周或一个以上的程式员)都一样，如果没有规格， 绝对会 耗时更久并且写出品质低劣的程式。理由如下。

规格最重要的功能是要_设计程式_ 。即使你是自己一个人写好所有的程式，而且写了规格也只是自己在看，写规格这个动作(详细描述程式运作)还是能迫使你实际设计程式。

让我们看看分属两家公司的两名虚构程式员。速食香蕉软体的史快手从来不写规格。「规格？我们才不要讨厌的规格！」而好脾气软体公司的罗杰先生则在规格确定前绝对不写程式。他们只是我众多虚构朋友中的两位。

史快手和罗杰先生有个相同点：他们都负责自家产品2.0版的向后相容事宜。

史快手决定，提供向后相容的最佳方法就是写一个转换器，把1.0版的档案转成2.0版档案。她开始打程式，喀嗒喀嗒，硬碟转呀转，鸡飞狗跳。大约两周后弄出一个还不错的转换器。不过史快手的客户不太高兴。史快手的程式等于强迫全公司一次升级成新版本。史快手最大的客户Nanner Splits无限公司拒绝购买新软体。他们要确定2.0版软体能_不经_ 转换使用1.0版档案。史快手决定写一个_回溯_ 转换器并挂在「存档」功能内。这就有点复杂了，在使用2.0版的功能时_似乎_ 一切正常，不过等要把档案存成1.0格式时就有问题了。你会发现前半小时用的新功能都无法以旧的档案格式储存。所以回溯转换器又写了两周，而且也不是很好用。这样子4周就过去了

而好脾气软体公司的罗杰先生是那种一切_照规矩_ 的人，没拿到规格前是_绝对不_ 写程式的。他花了20分钟设计出和史快手一样的向后相容功能，并且写出大意如下的规格：

1. 如果开启的档案是由旧版产品所建立的，就把档案转成新格式。

把规格先拿给客户看看，客户说话了「等一下！我们不想让全公司都升级！」所以罗杰先生再想想后把规格改成：

1. 如果开启的档案是由旧版产品所建立的，就把档案在记忆体内转成新格式。等要储存这个档案时，使用者可以选择存回旧格式。

这样又用了20分钟。

罗杰先生的老板是个物件导向狂。他看看这份规格，觉得有点问题并且建议用另一种架构。

1. 把程式重组成使用两组介面：V1和V2。V1包含所有版本一的功能，而V2则是继承V1并加上所有新功能。这样V1::Save可以处理向后相容事宜而V2::Save可以储存所有新东西。如果你开启V1档案后使用到V2的功能，程式可以马上警告你，你必须转换成新档案格式或放弃使用新功能。

又20分钟去了。

罗杰先生不太高兴。因为重组程式要花3周而不是他原先估的2周！不过的确优雅地解决了客户_所有_ 的问题，所以他还是回去照做了。

罗杰先生所花的时间总共是3周加1小时。史快手则花了4周，不过史快手的程式没那么好。

这个故事告诉我们，只要举的例子够怪，什么事都可以证明。对不起，刚才是开玩笑的，我不是这个意思。这个故事真正要说的是，当你以人用的语言设计产品时，只需要花几分钟就能考虑多种可能并且修订及改进自己的设计。没有人会觉得在文书处理器里删掉一段有啥大不了的。不过当你用程式语言设计产品时，反覆设计就得花上 好几周 了。更糟糕的是，某段程式可能只花程式员2周就写出来，可是他会一直死抱着那段程式，不管程式错得多么离谱。虽然史快手的程式并非最佳的架构，可是不管她老板或客户说什么，都无法说服她把那段漂亮的转换程式丢掉。结果最终的产品很容易变成最初设计和错误设计以及理想设计间的妥协。它是「我们所能做到的最佳设计，因为这些程式都写好了，而我们又舍不得把写好的程式丢掉重写」。如果光是「我们所能做到的最佳设计」，没有后面那些废话会更好。

所以这就是写规格的天字第一号理由。天字第二号是_节省沟通时间_ 。当你有写规格时，对于程式应有的作用只需要讲解_一次_ 。团队里其他人只要读规格就好了。品保人员读了规格就知道程式的动作同时也知道如何测试。行销人员读了规格就能写出暧昧的资料，放在网站上宣传尚未出现的产品。事业开发人员没好好读规格却在幻想，以为产品能治疗秃头肿瘤还有毒瘾，不过这样能吸引投资者，所以没啥关系。开发人员读了规格就知道要怎样写程式。客户读规格则是要确定开发人员正在制作他们想买的产品。技术作者读了规格才能写出好的手册(然后被遗失或丢掉，不过[这是另一个故事](/wiki/The_Joel_on_Software_Translation_Project:%E4%BD%BF%E7%94%A8%E4%BB%8B %E9%9D%A2%E8%A8%AD%E8%A8%88%E6%89%8B%E5%86%8A%E7%AC%AC%E5%85%AD%E7%AB%A0 “The Joel on Software Translation Project:使用介面设计手册第六章”))。经理也读规格，才能让自己好像知道经营会议的内容。如此类推。

这所有的沟通在没有规格时还是会发生， 因为这都是必要的 ，不过这时的沟通都是_特别安排的_ 。品保人员无论如何都得玩这个程式，看到有任何不对劲就会再度中断程式人员，并且问_另一个_ 程式应该怎么动的蠢问题。这不只会毁掉程式人员的生产力，而且程式人员也习惯照自己程式的写法回答问题，而不会回答「正确的答案」。结果品保人员实际上是用程式来检验程式，而非以设计来检验程式，而后者应该会好一点吧。

当你没有规格时，可怜的技术作者会遇到很好笑的事(以极悲惨的方式)。技术作者通常没有中断程式人员的特权。在很多公司中，如果技术作者习惯中断程式人员问些程式运作上的问题，程式人员会找经理告状，说这些该死的作者让他们什么事都做不了，请他们_闪远一点_ 。经理为了想提升生产力，就禁止技术作者不要_再_ 浪费程式人员_宝贵_ 的时间。这种公司很容易分辨，因为它们的说明档和手册里讲的没比画面上多多少。当你在画面上看到以下的讯息

1. 你要启动LRF-1914支援吗？

…当你点选「说明」就会看到一段叫人哭笑不得的内容

1. 允许你选择LRF-1914支援(预设值)或无LRF-1914支援。如果你需要LRF-1914支援，点选「是」或按「Y」。如果不需要LRF-1914支援，点选「否」或按「N」。

嗯，谢了。很显然技术作者试图掩饰他们_不知道LRF-1914支援是啥_ 的事实。他们不能问程式人员，因为(a)他们太害羞了，或是(b)程式人员在海得拉巴(印度)而他们在伦敦，或者(c)管理阶层禁止他们中断程式人员或是其他各种数不清的企业弊病，不过根本的问题在于 没有规格 。

写规格的天字_第三号_ 理由就是没有详细规格就无法订出时程。有些场合没有时程是可以的，例如你打算花14年研究的博士论文，或打算写下一版_等好了就会推出_ 的毁灭公爵游戏。不过几乎所有真实的事业都必须知道事情需要多久完成，因为开发产品是要花_钱_ 的。你不可能不知道价钱就买_牛仔裤_ ，那么一个负责的企业怎么能不知道要多少还有要多少钱，就决定是否制作某个产品呢？想多了解时程安排，请参考无痛软体时程。

有个很糟糕的常见错误，就是对某个项目的设计争论不休，结果_永远无法排除争议_ 。Windows 2000的首度开发人员Brian Valentine就有句名言「10分钟内给你决定，否则下一个免费」(译注：美国著名的披萨连锁店达美乐有一句广告标语「30分钟内送达，否则下一个免费」。同样的，Brian会在10分钟内决定，否则会免费给你下一个决定，不过要老板下决定本来就不用付钱给你的，不是吗？)

在很多的程式开发组织中，每次出现设计争议总是没有人愿意作出_决策_ (通常都是因为政治理由)。所以程式人员只去做那些没有争议的项目。等时间消逝而所有困难的决定都会压到最后才决定。这些专案很可能会失败。 如果你针对某项新技术开了家新公司，却注意到公司有结构性问题无法作出决策，你最好关门大吉把钱退还给投资者。因为你永远都无法推出产品。

写规格是处理这些烦人设计决策的好方法，这些问题有大有小，不过没写规格就看不到。即使很小的决策问题也可以写规格搞定。举例来说，如果你正在建一个会员网站，你们可能都会同意，当使用者忘记密码时应该发信告知密码。很好，不过对写程式来说还不够。要把程式写出来得知道邮件中实际使用的文句。大部份公司都不认为程式人员能撰写使用者实际接触的文句(而且通常都有很好的理由)。所以会要求行销人员或公关或是其他文学素养好的人决定讯息的文句内容。「王大明先生，这是阁下忘记的密码。希望阁下往后能小心一点。」当你强迫自己写出一份 良好而完整 的规格时(我很快就会详述这一点)，就会注意到这所有的项目并且把它解决，或者至少标示出来以便修正。

好了。我们现在应该都能同意。规格是一切的根本。我怀疑大部份的人是否懂这一点，另外我讲的虽然有趣，却不知是否真能让你学到新东西。那么为什么人们_不_ 写规格呢？绝不是省时间，因为根本_不会省_ ，而且我认为大多数程式员都知道(在大部份组织中，唯一存在的「规格」都是断简残篇，是程式员写好程式_后_ 解说某该死功能第三百遍_后_ ，用记事本打出来的一页文字文件。

我认为真正原因是多数人都不喜欢写东西。瞪着空白的萤幕会让人感觉极度地沮丧。我个人克服写作恐惧的方法是去学校参加写作课，一星期写3到5页的短文。写作就像肌肉一样，写得愈多就愈能写。如果你必须写规格又写不出来，开个期刊定讯，建一个weblog，上个创作写作课程，或是写封信给亲戚或四年未联络的大学室友。任何把文字填到纸上的活动都能增进你写规格的技巧。如果你是个软体开发经理而该写规格的人写不出来，把他送到山里面上两周创作写作课吧。

如果你未曾在一家有写功能规格的公司做过，可能会没看过功能规格。我会在本系列的下一篇中展示一篇简短的规格范例供你参考，另外我们也会讨论一份好的规格必须具备的元素。[继续看！](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E5%8A%9F%E8%83%BD%E8%A6%8F%E6%A0%BC(%E4%BA% 8C) “The Joel on Software Translation Project:无痛功能规格(二)”)

无痛功能规格 第一篇：何必麻烦呢？

无痛功能规格第一篇：何必麻烦呢？