# 三十四、没有什么像IT看起来那么简单 问题是这样的：你可以用选单由网络上汇入档案（Import Web Page)，也可以用 鼠标拖拉磁盘里的档案汇入CityDesk。不过没有选单可以汇入磁盘中的档案，所 以大家不是没有发现可以这样做，就是尝试用Import Web Page功能汇入磁盘中 的档案，而后者当然也是不能用的。 我认为用两页的精灵可以轻易的解决这个问题。大概的方法是用精灵的第一页问 「你要由哪里汇入数据？」，如果你选「磁盘」，第二页就提示你输入档名；如 果选择「web」，第二页就提不输入URL路径。 我几乎要开始实作，不过还是停下来着手写一份迷你规格。下面是这份规格的全文： 第一页 你要由哪里汇入数据？（磁盘/Web) 第二页(磁盘） 标准的开启档案对话盒第二页(Web) 有迷你网页浏览器的URL输入画面 突然间我想到一件事。有办法把通常由0S提供的开档对话盒激在精灵里吗？ 呃… 我去查过了。结果是可以的，不过不太好玩而且要花几个小时工夫。那么可以不 用精灵来做吗？我把规格重写成： 两个选单： 1)由Internet汇入网页-> 显不URL对话盒 2)由磁盘汇入网页-> 显示开文件对话盒 好多了。三分钟的设计省了我几小时的程序工夫。 如果你这辈子写过20分钟以上的程序，可能已经发现这个很好的基本原则：没有事情像表面看起来那么简单. 就连复制一个档案这么简单的动作都充满陷阱。如果第一个参数是目录会如何？ 如果第二个参数是档案又如何？如果目的地已经有相同档名的档案又会怎样？ 万一没有写入权限又怎么办？ 如果档案拷到一半出错要如何？如果目的地是需要认证才能继续的远程机器又 如何？如果档案很大而联机很慢，必须显示进度栏时又会如何？万一传输速度慢 到刀手完全不动…你要等多久才放弃并传回错误讯息呢？ 有个好方法可以用来面试应征测试工作的人，就是要他针对一件简单的操作，把 所有可能出错的地方全都列举出来。微软对面试测试人员有个经典题目：如何测 试开档对话盒？优秀的测试人员可以滔滔不绝地列出几十种测试项目（在你选好 档案，要按「开启」之前，另一个使用者把原本存在的档案杀掉了）。 好了，所以我们得到一个定理：没有事情像表面看起来那么简单。 软件工程里有另外一个定理，就是随时随地都要尝试降低风险。其中一项必须避 免的重大风险是进度风险，就是某件事花的时间比预期多。进度风险的坏处在 于你会被老板吼而很痛苦。如果你觉得这没什么，可以改由经济观点考虑进度风 险的坏处。如果因为当初评估需要一周而决定要做某个功能，事后才发现其实 需要20周，那么前面的决策就错了。如果你早知道需要20周很可能就会做不一样 的决定。而错误的决策愈多，印有你公司标志的购物袋愈有可能流落到资产清算 的仓库，而同时间你的前执行长还在怨叹「真惨啊，我们还没有被烂公司报导前 就倒了！」 「没有事情像表面看起来那么简单」再加上「降低风险」只会导出一个结论： 你必须先做设计再去实作。 我很抱歉让你失望了。没错，我知道你看过Kent Beck的书，而且现在认为不先 设计而直接实作是正常的。很抱歉，这并不正常。改程序就是没法子和改设计 文件「一样简单」。大家一直都这样说，不过这并不对。「现在我们都用Java 和XML这种高阶工具，几分钟就可以改好程序，为什么不直接在写程序时做设计 呢？」我的朋友，你可以替你老妈装上轮子，不过她并不会因而变成巴士。另 外如果你自认能把错用线程的档案复制函数，重整改正成先占多任务的作法，而 且速度和我写这个句子一样快，你根本就在自己骗自己(deep denial)。 无论如何，我不认为极限程序设计真的在提倡零设计。他们只是说「不要做无谓 的设计」，而这一点是没有问题的。不过大家所至如勺不是这么回事。大部份程 序员都尽可能地找寻能不在实作前先做基本设计的借口，所以他们就像捕蚊灯里 的蚊子一样黏住「无设计」这个想法。这其实只是偷鸡不着蚀把米的另类懒惰。 我懒得先在纸上设计功能所以直接写程序，程序做得不对只好再花时间修正，结 果只会花更多的时间。还有更常见的状况，就是程序写错了可是来不及改正， 于是产品的质量低落，只好一直找借口解释东西为什么「必须写成这样」。根本就是懒散又不专业。 当Linus Torvalds痛斥设计时谈的是巨大的系统，这种系统必须逐渐演进，否 则就会像Multics那样死路一条。他说的并不是你的档案复制程序。人们认为 Linus有很清楚的计划，确实知道往后要怎么进行，无怪Linus会不怎么看重设 计。所以别上当了，这种作法很可能并不适合你。何况Linus比我们要聪明多， 他能做的事我们一般人是做不来的。 渐进式的设计和实作是好的。常常发行也是好的。不过就软件包或大众市场而言， 频繁的发行新版会让客户疯掉，并不是个好主意，应该改成在内部密集的发行。 太拘泥于设计细节会浪费时间，我从来没看过哪个项目，会因不需动脑的流程图 或UML或CRC或是其他流行玩意而获益。Linus说的那些有一千万行程序的超大型 怪物系统应该要逐渐演进，因为人类确实不知道要如何设计那种规模的软件。 不过当你坐下来要写档案复制的程序，或是计划下一版软件的功能时，一定要做 设计。不要让那些说法迷惑了你。 你可以在四月29到五月一日间，到麻州剑桥的Cutter Summit和我当面讨论，我会和Tom DeMarco, Kent Beck和其他人一起。