# 八、轻松写就功能规格说明书 - 第4节:技巧
好吧,我们已经讨论过为什麽要规格,规格裡有什麽,以及谁该写规格。在这系列的第四篇及最后一篇裡,我要和大家分享一份撰写良好规格的建议。
在真正有写规格的团队中最大的抱怨就是「没有人在读」。如果没有人在读,写规格的人通常会变得有点愤世嫉俗。就像以前呆伯特漫画裡,工程师用一大叠4吋厚的规格书堆起来充当隔间。在典型官僚作风的大公司裡,每个人都花好几个月写无聊的规格。等规格写好就放上书架永远不再拿下来,然后重头开始製作产品,完全不管规格裡怎麽写。这是因为没人读规格同时也是因为规格写得无聊透顶。写规格的过程应该是个很好的练习,因为它至少能强迫每个人仔细思考问题。不过规格完成后就被束之高阁(没人看也没人爱),会让大家觉得这只是件毫无价值的工作。
另外如果没有人读你的规格,等产品完成推出就会出现很多争议。某人(管理阶层,行销人员或是客户)会说:「等一下!你答应过会有蛤蜊蒸锅的!蛤蜊蒸锅在哪裡?」然后程式员会说:「不,事实上如果你看看规格第3章第4节的2.3.0.1,就会看到上面明确写著'没有蛤蜊蒸锅。」不过永远是对的客户可没这麽好打发,所以不爽的程式员只好在产品裡加一个蛤蜊蒸锅(结果让他们更不相信规格)。另外也可能会有个经理说:「嘿,这个对话框裡的文句都太累赘了,而且每个对话框上方应该都有广告才对。」然后程式员会垂头丧气地说:「可是你批准了规格而且裡面明确的列出每个对话框的配置和内容!」不过经理当然不会真正去读规格,因为当他想看的时候就开始心不在焉,而更重要的是这和他週二的高尔夫球比赛有衝突。
所以说虽然规格是很好的,不过如果没人读就不好了。身为撰写规格的人,你必须骗大家来读你的作品,另外也可能要努力不要让大家过份依赖规格而失去原本已经很差的思考力。
要骗大家来读你的作品,通常只需改善写作即可。不过光说句「要当个好作家」就撤手不管实在不太公道。下面列出想让别人读规格时绝对要遵守的四个简易规则。
## 规则1:要有趣
是的,要骗大家来读规格的第一个规则就是让读规格变得很有趣。别告诉我你生来就没有幽默感。我才不信呢。每个人随时都会有好玩的点子,只不过因为觉得会「不专业」所以自我约束。不过有时候你得要打破规则。
如果你读过我在这个网站写的一堆垃圾,你会注意裡面到处都有想让内容更有趣的拙劣企图。另外往前数第四段我才刚写了个低级玩笑取笑经理在打高尔夫球。虽然我实际上没那麽幽默,我还是很努力在尝试。另外虽说胡扯乱扯试图表现有趣本身就很滑稽,却是属于悲哀的那一型。在写规格时范例是个表达趣味的好地方。当你需要说个故事解释某个功能时,千万不要这样说:
使用者按Ctrl+N建立一个新的雇员表格,并且开始输入雇员姓名。
你应该要这样写:
猪小姐因为手指太肥按不到单一的键,所以拿著一根眼线笔戳键盘按出Ctrl+N建出一个新的男友表格。然后输入单一笔资料"Kermit"。
如果你读过很多Dave Barry的文章,会发现有个很容易的方法可以逗趣,就是在不需要的地方详述细节。「爱吵闹的哈巴狗」就比「狗」有趣。而「猪小姐」也比「使用者」有趣。用「左撇子酪梨农夫」要比「特殊嗜好」好。不要用「不替狗清大便的人应该受罚」,应该说「把他们关在单人囚房,让他们寂寞到想付钱跟蜘蛛上床。」
附带一提,如果你认为逗趣不够专业,那我也没办法,只能说你缺乏幽默感。(不要否认。没有幽默感的人总是不肯承认。你是骗不了我的。)另外如果同事会因为你写的规格轻鬆有趣很好读而轻视你的话,就去找别的工作吧,因为生命实在太短暂,不应该把你的白天浪费在这种苛刻悲惨的地方。
## 规则2:写规格就像在写用脑执行的程式
这就是我会认为程式员写不出好规格的原因。
当你在写程式时,主要对象是编译器。没错,我知道人也会读程式,不过通常会读得很辛苦。对大部份程式员来说,光是要让程式能正常编译就够辛苦了;要把程式写得容易阅读简直是遥不可及。你可以写:
```
void print_count( FILE* a,char * b,int c ){
fprintf(a,"there are %d %s\n",c,b);}
main(){ int n;n =
10;print_count(stdout,"employees",n) /* code
deliberately obfuscated */ }
```
或是
```
printf("there are 10 employees\n");
```
输出是完全一样的。如果你仔细想想,这就是原因所在,程式员通常都会写出如下的东西:
假设有个函数AddressOf(x),作用是由使用者x转出该使用者的RFC-822格式电子邮件地址,并以ANSI字串输出。让我们假设有使用者A和使用者B,A想送电子邮件给使用者B。所以使用者A用其他任意(不是全部)技术建立新讯息,然后在「传送至:」编辑框内键入AddressOf(B)。
这也可以写成以下的规格:
猪小姐想去吃午饭了,所以打了一封电子邮件并在「传送至:」框内键入Kermit的地址。
技术注解:地址必须是标准的Internet地址(RFC-822格式)
理论上这两种写法的「意思」完全一样,不过除非你很小心的解译,否则是不可能看懂第一种写法的。程式员常会尝试把规格写得像艰涩的学术论文。他们认为一份「正确」的规格必须在「技术」上完全正确,结果完全搅不清楚状况。
问题在于规格不光是正确就好,同时还必须是可理解的,以程式设计的术语来说,就是要把规格写得让人脑能够「编译」。电脑和人脑间最大的差别之一,就是当你定义稍后要用的辞语时电脑会耐心等候。可是对人来说一定要先有动机才会瞭解你在讲什麽。人们不会想被迫解译某些东西,他们只想循序阅读就能理解。对人来说,你必须先提供整体概念然后才填补细节。而电脑程式则是从头到尾顺序下来全部都是细节。电脑不在意变数名称是否有意义。而对人脑而言,如果能先讲个故事(即使只是片断也可以)描绘出鲜明的印象,就能够理解得更清楚。因为我们的脑袋已经演进到能理解故事了。
如果你拿出真实西洋棋赛进行中途的棋局,经验够的老手只要一两秒就能立刻记住每个棋子的位置。不过如果以正常下棋不会走的方法(比如把卒放在第一列或把两隻黑主教都放在黑格上)移动几颗棋子,棋手就很难记下棋局。这和电脑思考的方式不同。对能记忆棋局的电脑程式来说,可能及不可能的棋局记起来都一样。人脑的运作方式并不是随机存取的;我们脑中的某些路径会被持续加强,所以某些常见的事物就会比其他东西更易理解。
所以当你在写规格时得试著想像你的对象是谁,并且想像规格各个部份是要他们瞭解什麽东西。逐句逐句地问自己,就前面已经提供的内容而言,读到这句话的人能深入理解其涵义吗?如果对象中有些人不知道RFC-822是什麽,你必须把定义写出来,或者至少在技术注解中简述RFC-822,这样非技术人员才不会一开始就看到一堆专业术语,结果投降永不再看。
## 规则3:写得愈简单愈好
千万不要觉得简单句子不够专业,就使用夸大的正式语句。写得愈简单愈好。
人们会认为"use"不够专业所以改用"utilize"之类的单字。(「不够专业」这句话又出现了。不管任何时候,只要有人说你不应该如何如何,因为那样「不够专业」,你就知道这些人已经没有真正的理由了。)事实上我认为很多人会觉得写得清楚明瞭就表示裡面大有文章。
把要讲的东西拆成短句。如果你没办法把某个句子写得很清楚,就把它拆成二或三个较短的句子。避免整面的文字牆:也就是说整页都只有文字。大家遇到这种情况就会吓到根本不敢看。你什麽时候看过有热门杂志或报纸裡整页都是文字的?杂志会从文章裡摘录引言,然后用超大字体印在页面正中央,就是为了避免有整页都是文字的印象。有编号或标上符号的列表,图片,图表,表格以及大量空白,都可以让东西「看起来」更轻鬆。
「杂志会从文章裡摘录引言,然后用超大字体印在页面正中央,就是为了避免有整页都是文字的印象。」
没有东西比撷取大量的画面更能增进规格了。正所谓一图胜千言。撰写视窗软体规格的人都应该买一套Visual Basic,然后学到至少能建立模拟画面。(在麦金塔上就用REAL Basic;写网页就用Front Page或Dreamweaver)。然后撷取这些画面(按Ctrl+PrtSc)再贴进规格内。
## 规则4:审阅多次并重读几遍
嗯,好吧,本来我打算花大量篇幅来阐述这项规则,不过这一项实在是太简单明显了。把你的规格审阅多次并重读几遍,知道了吗?当你发现某个句子不是非常容易理解,就把整句重写一次。
不去解释规则4省了我很多时间,所以我要额外增加一项规则。
## 规则5:使用样板是不好的
要避免製作标准规格样板的诱惑。最先你可能只是认为,让「每份规格看起来都一样」是很重要的。我的建议是这并不重要。这会有什麽差别吗?你家裡书架上的每本书都长得一模一样吗?你希望他们一样吗?
更糟的是如果有了样板,很容易就会针对各个自认重要的功能在样板上加上一大堆章节。举例来说,大比尔下令从今以后,所有Microsquish产品都一定要有个Internet元件。所以现在起规格样板裡就有一节「Internet元件」。不管是谁在写也不管内容有多无聊,每个人都得在「Internet元件」那一节填入内容,即使他们只是在写Microsquish键盘的规格。(不然你以为为啥有那麽多无用的Internet购物键像雨后春笋般从键盘上冒出来。)
等这样的章节一多,整份样板就会变得大。(这裡有份非常非常糟糕的规格样板范例。我的天啊,谁会需要在规格裡放参考书目或一份小辞典呢?)这种巨型样板的问题就是让写规格写是很可怕的工作,把大家吓得不敢去写规格。
规格就是一份你希望大家去读的文件。就这种观点来看,规格和纽约客或学校论文没啥不同。你曾听说过有哪个教授会拿样板给学生去写论文吗?你曾读过哪两篇好文章能套进一份样板吗?把这个点子忘了吧
- 第一部分 位与字节:编程实践点滴
- 一、语言的选择
- 二、深入底层
- 三、joel测试:改进代码的12个步骤
- 四、每一位软件开发人员必须、绝对要至少具备UNICODE 与字符集知识(没有任何例外!)
- 五、轻松写就功能规格说明书 - 第1节:为什么烦心?
- 六、轻松写就功能规格说明书 - 第2节:什么是规格说明书?
- 七、轻松写就功能规格说明书 - 第3节:但是……如何?
- 八、轻松写就功能规格说明书 - 第4节:技巧
- 九、轻松制订软件进度表
- 十、每日连编是朋友
- 十一、难伺候的故障修复
- 十二、软件开发中的5个世界
- 十三、稿纸原型开发
- 十四、不要被太空架构师所吓倒
- 十五、开火与运动
- 十六、人员技能
- 十七、源于计算机学科的三个错误思想
- 十八、二元文化
- 十九、自动获取用户故障报表
- 第二部分 开发人员的管理
- 二十、面试游击指南
- 二十一、重金激励害多利少
- 二十、二不配备测试人员的五个首要(错误)原因
- 二十三、任务换人有害无益
- 二十四、绝不去做的事情,第一部
- 二十五、冰川下的秘密
- 二十六、漏洞抽象定律
- 二十七、程序设计界的LordPalmerston
- 二十八、评测
- 第三部分 Joel对常态问题的遐想
- 二十九、RickChapman解读愚昧
- 三十、在这个国家狗是干什么的? 我们有多么天真?
- 三十一、作为哼哈二将,只管去做事
- 三十二、两个故事
- 三十三、巨无霸麦当劳与天才厨师JamieOliver
- 三十四、没有什么像IT看起来那么简单
- 三十五、提防非自主开发综合症
- 三十六、策略I:BEN&JERRY公司与AMAZON
- 三十七、策略II:鸡与蛋问题
- 三十八、策略III:让我回去!
- 三十九、策略IV:大件与80/20神话
- 四十、策略V:公开源代码的经济因素
- 四十一、墨菲法则肆掠的礼拜
- 四十二、微软公司是如何败北API之战的
- 第四部分 对.NET稍多的评说
- 四十三、微软精神失常了
- 四十四、我们的.NET对策
- 四十五、请问,我可以使用连接程序吗