梦断代码阅读笔记02

是程序员的软件企业来说是必须环节。规格说明将需求一软件开发者
的客户提出的目标或愿望一翻译 为指挥程序员的详细行军指令。例如，
对于一种个人财务软件产品，需求可能类似于这样:必须支持多个信用
卡账户的分类账目。要能从银行下载账户信息。规格说明将明确写出程
序如何满足这些需求。界面规格巨细靡遗地描绘出每个屏幕的样子，按
钮和菜单的位置、字体和颜色，以及当文本超出-行时该如何处理。交
互规格说明记录程序如何响应用户每次点击、拖拽和字符输入。
规格说明是程序员的圣经，而且，通常程序员也会是忠诚信徒:规
格说明就是法律。因其天性和职业需求，程序员也缺乏想象力。所以编
写规格说明就要十分当心:像在童话故事里-般，你要小心阐述自己想
要的东西。(永生?别忘记还要指明“青春常驻”1)
计算机界有个老笑话，说某位受尽挫败的用户拨打技术支持热线，
抱怨说明书里写“按任意键开始"，可怎么也找不到“任意键”在哪儿。
这个笑话嘲笑的是那个倒霉的白痴用户，但这新手的错误理解却真实反
映出关注细节、无视上下文的阅读方式是编程大牛们的专长。规格，顾
名思义，应使用详尽的特性描述、在人类模糊世界与机器精确世界之间
搭起一座桥梁。不该让程序员如坠云里、连猜带蒙。但这类努力不免有
失完美。部分原因是规格说明的作者是人类，他们用人类语言写作。但
也因为写作“完美的规格"一设想并规定程序使用和行为的每种可能
场景一耗力无算; 永远不可能在完成规格撰写后才开始编码。
实际上，人类的耐心缺乏再加上市场需求迫切，常常导致规格说明
编写不充分。而在OSAF,问题却不在于知道规格说明何时完成，而是
构想出如何开始写。撇开团队内部对动力的新感觉不谈，在几个关键且
复杂的部分仍然盘踞有"蛇"一一用OSAF早期的术语来说。
共享信息是Chandler最重要的特性之一， 但每次设计组讨论到这个
主题，总会陷入未解决问题一或者用项目管理语言来说，“开放性问

题”一的循环中去。用户如何发起共享?到底可以共享什么一单个
条目?整个条目集合?还是一种特定的视图或一组屏幕布局?当用户要
共享这些而不是那些条目时，Chandler如何才能控制“权限”?如果允
许某些共享者修改共享的条目而另外一些共享者不行， 如何才能让数据
拥有者做出选择?如果有两个用户在离线时修改了同一条目，当他们回
到线上、试图同步修改时，Chandler 应该如何解决冲突?跟着是最痛苦
的共享问题:“ 链式共享"。如果你共享了我的一个条目，你能和第三人
共享这个条目吗?她能再与别人共享吗?当第三位、第四位、第五位共
享者修改了这个共享条目会发生什么一修改会 沿共享链条传递回来
吗?该问题又名"n 向同步”一同步 数据的未知(n)个版本。
- -开始时的简单需求一“ 用户应该能方便地共享信息"一很快
扩张成一-大团难题之云。虽说暂时可以推到“以后再说,"但每个人都知
道，最终还得设法解决这些问题。
共享并非唯一难 点。围绕Chandler群集(或条目组)的管理还有许
多开放性问题。从某种意义上说群集类似桌面应用界面中的文件夹一
包含一组东西一但从另外的角度来看， 它们更为奇特。条目可能同时
在多个群集中存在。有些群集基于规则:只要让Chandler 创建一个包
括所有商业伙伴名字的群集，程序就会自动更新群集。在这些部分，
Chandler管理信息的方式借鉴了Apple iTunes软件管理数字音乐集的方
式。但卡普尔也想确保Chandler 可以允许随意剔除或包含条目。他常
举例说，想要一个基于规则的、包括所有鲍勃.马雷( Bob Marley) 作
品的音乐集一但要 剔除一张他很不喜欢的现场版专辑。 用iTunes可做
不到。
“第一次,”卡普尔在一次会议上解释说，“在设计Agenda时，当我
说到我想要用规则定义群集、但也会有随意分组的情况的时候，遇到了
极大的阻力。就像是我犯了计算机科学中某种大忌似的。没错，有许多

个人感受：我们在做项目时一定要做好需求分析，站在客户的角度思考问题，

书中有个笑话很有意思某位受尽挫败的用户拨打技术支持热线，抱怨说明书

里写“按任意键开始"，可怎么也找不到“任意键”在哪儿。我之前在做东西时

并没有很好的站在客户的角度思考问题，总是觉得自己会用，自己开发的当

然会用，以后一定要重视这一点。

解决方案：多客观的看项目，站在客户的角度。