我們在
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
說的系統，
那些
有一千萬行代碼程序的龐然大物，它們應該慢慢進化，因為人類還不知道怎樣設計那種規模的軟件。
?
但是當你坐下來寫你的拷貝文件的程序，或者計劃給你的軟件下個版本增添功能的時候，你一定要先作設計。不要讓報急的號角使你草草動手。