<<More Joel on Software>> 看起来简单， 实际上复杂

作者： 周思博 (Joel Spolsky) 译： Bo Yang 翻译 编辑： Billy Chen 编校 2002年3月4日

我们在CityDesk里有一个使用性上的小问题。

 

 

问题是这样的：你可以用菜单上“导入网页”的命令，从因特网上导入一个文件。你也可以用鼠标拖放的方法，从磁盘上导入一个文件。但是菜单上 没有“导入磁盘文件”这个命令，所以有些用户没有发现CityDesk 有这个功能，或者他们试图用“导入网页”这个命令去导入磁盘上的文件，结果造成无法成功导入。

 

 

我一开始想这个问题很好解决，大概的方法就是用一个两个页面的文件导入向导。第一页问你：“你要从哪里导入？”。如果你选择“磁盘”，第二页就会提示你选一个文件；你要是选择“因特网”，第二页就会提示你输入一个URL.

 

 

我差点就开始动手去实现我这个想法了，但是有些事情使得我并没有这样做。我决定先写一个小的规约再说。写出来的规约如下：

 

第一页

你要从哪里导入？

磁盘/因特网

 

第二页（磁盘）

标准的打开文件对话框

 

第二页（因特网）

用小浏览器让你输入一个URL

 

突然间我想到一个问题。Windows的打开文件的对话框，通常是由操作系统提供的。能不能把这个对话框放到我的文件导入向导里面呢？

 

嗯…

 

我查了一下。是可以这样做的，但这不是一件好玩的事，而且要花好几个小时的时间。我能不能不使用导入向导的方式呢？我重写了一下我的规约：

 

两个菜单项：

1）从网上导入网页 -> 显示URL输入对话框

2）从磁盘上导入网页–> 显示打开文件对话框

 

这就好多了。三分钟的设计时间，省了我几个小时的编程序时间。

 

如果你这辈子花了二十分钟以上的时间去编软件代码的话，你就可能发现了一条规则：事情没有看起来那么简单。

 

就像拷贝文件这样简单的事，都充满了危险。如果第一个参数是个目录会如何？如果第二个参数是个文件会如何？如果同名的文件已经存在于目的子目录会如何？如果你没有写的权限又会如何？

 

如果在拷贝文件的过程中失败了怎么办？如果目的地是在一个远程计算机上，但是需要身份验证怎么办？如果文件很大但网络连接又慢，所以你需要显示一个进度条怎么办？如果文件传输速度降到几乎是零了，你什么时候放弃拷贝而给用户一个错误信息呢？

 

 

一个面试测试员的好办法，就是给他们一个简单的操作过程，然后让他们列出可能出现的错误情况。一个在Microsoft面试时典型的问题就是：你怎样去测 试打开文件对话框呢？一个好的测试员，可以轻而易举地列出几十个令人难以想到的情况去测试（比如“一个文件显示在对话框里，然后你去打开它，但是在你按打 开的按钮之前，这个文件被另一个用户删除了”）。

 

好，我们得到这样一个公理：事情没有看起来那么简单。

 

软件工程里还有一个指导思想，那就是你要永远想方设法去减低风险性。一个要特别小心去避免的风险，就是项目进度延期的风险。项目延期很不 好，因为老板会训你，闹得你挺不高兴的。除此之外，这也存在经济方面的原因，那就是当初你决定给你的软件加某个功能的时候，你觉得这个功能只需要一个星期 就能完成。现在你认识到该功能需要二十个星期才能完成，那么你当初的决定当然就是错的。如果你当初就知道需要花掉二十个星期的话，你可能就作出不同的决定 了。你作出的错误决定越多，你公司的财产被一次性冲销处理的可能性就越大（甚至你们公司的标志会被收入债权人的仓库）。到时候你的前老板抱怨道：“我们公 司关门倒闭了不说，气人的是连上fuckedcompany的资格都没有。”

 

 

 

 

事情没有看起来那么简单，再加上减低风险性的指导思想，只能让你得出如下的结论：

 

先设计再编程序，先思而后行。

 

让你失望了，很抱歉。我知道你读过Kent Beck的书，所以你以为动手之前不做设计是可以的。对不起，那是不可以的。你修改程序不可能像修改设计文件那样“容易”。有些人总是发表这样的谬论： “我们现在用高级工具了，像Java和XML。 我们在几分钟之内，就可以改动程序里的很多东西。为什么不在程序里直接设计呢？”哥们儿，你可以在你自行车上加个发动机，但你不能把它变成汽车。如果你以 为把你拷贝文件的程序，由线程式改为抢占式，而且改得比我写这句话还快，那你就大错特错了。

 

 

不管怎么说，我不认为Extreme Programming是在鼓吹零设计的理念。他们只是说：“不要作任何无必要的设计”，这没有什么错嘛。但人们听到的并不是这样。大多数程序员是在找不 用设计的借口，所以他们像飞蛾扑火般投向“不用设计” 这个馊主意。这是一种奇怪的，让你事倍功半的懒惰方式。我懒得先在纸上把这个功能给设计好了，所以我就先写程序，然后发现不对，我就去改，结果反倒花更多 的时间。或者，更经常发生的是，我先写些程序，发现它不对，但是没时间改了，结果我的产品质量低劣，而且我还是要找出些借口，说明它为什么“一定要那样 “。那只不过是马虎潦草，缺乏职业精神。

 

Linus Torvalds攻击设计的时候，他是在讲那些规模庞大的系统。大规模的系统必须慢慢进化，要不然它们就变成Multics了。他不是在说你那个拷贝文件 的程序。你再想想，Linus Torvalds脑子里有一个很清楚的路线图，知道他要到哪去，所以他觉得设计没什么用，也不足为奇。但不要上当，基本上说那对你不适用。Linus Torvalds比我们聪明多了，所以他能干的事，不等于我们一般人也能干。渐增式设计及实现是好事。频繁地发布版本是可以的（但针对在大众市场上的软件 来说，频繁发布版本会使用户不高兴，绝不是个好主意——可以多搞些内部的里程碑取而代之）。设计上不要拘泥于形式，那只是浪费时间。我从来没有见过某个项 目得益于不动脑筋的流程图、UML、CRC，或者其他什么时髦的，花里呼哨的设计方法。至于那些Linus Torvalds说的系统，那些有一千万行代码程序的庞然大物，它们应该慢慢进化，因为人类还不知道怎样设计那种规模的软件。

 

但是当你坐下来写你的拷贝文件的程序，或者计划给你的软件下个版本增添功能的时候，你一定要先作设计。不要让报急的号角使你草草动手。