Joel on Software Painless Functional Specifications – Part 4: Tips 无痛功能需求 – 第四部分:技巧 by Joel Spolsky Sunday, October 15, 2000 OK, we’ve talkedaboutwhy you need aspec,what a spechas in it, andwho shouldwrite them. In this fourt
Joel on Software
Painless Functional Specifications – Part 4: Tips
无痛功能需求 –第四部分:技巧
by Joel Spolsky Sunday, October 15, 2000
OK, we’ve talkedabout why you need aspec, what a spechas in it, andwho shouldwrite them. In this fourth and final part of the series I’ll share some ofmy advice for writing good specs.
好,我们已经讨论了 为什么你需要规范, 规范包含什么内容, 以及谁应该编写规范。 在这些列的第四部分同时也是最后一部分我将和大家分享我编写好规范的建议。
The biggestcomplaint you’ll hear from teams that do write specs is that”nobody reads them.” When nobody reads specs, the people who writethem tend to get a little bit cynical. It’s like the old Dilbert cartoon inwhich engineers use stacks of 4-inch thick specs to build extensions to theircubicles. At your typical big, bureaucratic company, everybody spends monthsand months writing boring specs. Once the spec is done, it goes up on theshelf, never to be taken down again, and the product is implemented fromscratch without any regard to what the spec said, because nobody read the spec,because it was so dang mind-numbing. The very process of writingthe spec might have been a good exercise, because it forced everyone, at least,to think over the issues. But the fact that the spec was shelved (unread andunloved) when it was completed makes people feel like it was all a bunch ofwork for naught.
你从那些确实编写规范的团队听到的最大抱怨就是“没有人会读规范”。如果没有人阅读规范,那么写规范的人就会有点儿愤世嫉俗。就像迪尔伯特漫画里描绘的那样,工程师们使用一摞摞4英寸厚的规范来扩展他们的工作隔间。在你们那些大的,官僚作风的典型公司,每个人都会花数月来编写无聊的规范。规范一写完就会被放到架子上去,再也不会被拿下来,而产品则是从头做起绝不会参照任何规范的描述,因为没有人阅读规范,因为规范是如此的让人头皮发麻(无聊,愚蠢)。编写规范的过程也许是个很好的训练,因为它让每个人至少去仔细思考这些问题,但是规范完成后就被高高搁置(没人爱也没人读)让人觉得写规范就是件徒劳无功的工作。
Also, if yourspec never gets read, you get a lot of arguments when the finished product isdelivered. Somebody (management, marketing, or a customer) says: “wait aminute! You promised me that there would be a Clam Steamer! Where’s the clamsteamer?” And the programmers say, “no, ac本文来源gao@!dai!ma.com搞$$代^@码!网!tually, if you look on thespec on chapter 3, subchapter 4, paragraph 2.3.0.1, you’ll see it says quiteexplicitly ‘no clam steamer.'” But that doesn’t satisfy the customer, whois always right, so the grumpy programmers have to go retrofit a clam steamerinto the thing (making them even more cynical about specs). Or a manager says,”hey, all the wording on this dialog is too verbose, and there should bean advertisement at the top of every dialog box.” And the programmers say,in frustration, “but you approved the spec whichprecisely listedthe layout and contents of every dialog box!” But of course, the managerhadn’t actually read the spec, because when he tried, hisbrain started seeping out through his eye sockets, and anyway, it wasinterfering with his Tuesday golf game.
同时,如果你的规范从来没被阅读过,当你的产品完成并交付的时候你就会遇到很多争端。有人(管理层,销售,或者顾客)就会说:“等等!你答应过我会做蛤蜊蒸笼[w1] !蛤蜊蒸笼在哪儿?”然后程序员就会说,“不,实际上,如果你看看规范第三章第4小节,2.3.0.1段,你就会很清楚的看到写着‘没有蛤蜊蒸笼’”。不过这不会让客户满意,因客户永远是对的,所以暴躁的程序员只好去产品里改造出个蛤蜊蒸笼来(这就让规范存在的意义显得更讽刺了)。或者经理会说,“嘿,这个对话框上的文字太冗余了,而且每个对话框的顶部都应该要个广告。”然后程序员就会很沮丧的说,“但你已经批准了这个规范,规范上准确无误的描述了每个对话框的布局和内容。”但是,经理实际上当然没有去读那个规范,因为他刚要尝试,他的思绪就透过他的眼睛飘了出去,再说,这打扰了他礼拜二的高尔夫球比赛。