我們在
CityDesk
里有一個使用性上的小問題。
?
?
問題是這樣的：你可以用菜單上“導入網(wǎng)頁”的命令，從因特網(wǎng)上導入一個文件。你也可以用鼠標拖放的方法，從磁盤上導入一個文件。但是菜單上沒有“導入磁盤文件”這個命令，所以有些用戶
沒有發(fā)現(xiàn)CityDesk 有這個功能，或者他們試圖用“導入網(wǎng)頁”這個命令去導入磁盤上的文件，結(jié)果造成無法成功導入。
?
我一開始想這個問題很好解決，大概的方法就是用一個兩個頁面的文件導入向?qū)А５谝豁搯柲悖骸澳阋獜哪睦飳耄俊薄Ｈ绻氵x擇“磁盤”，第二頁就會提示你選一個文件；你要是選擇“因特網(wǎng)”，第二頁就會提示你輸入一個
URL.
?
我差點就開始動手去實現(xiàn)我這個想法了，但是有些事情使得我并沒有這樣做。我決定先寫一個小的規(guī)約再說。寫出來的規(guī)約如下：
?
第一頁
你要從哪里導入？
磁盤
/因特網(wǎng)
?
第二頁（磁盤）
標準的打開文件對話框
?
第二頁（因特網(wǎng)）
用小瀏覽器讓你輸入一個
URL
?
突然間我想到一個問題。
Windows的打開文件的對話框，通常是由操作系統(tǒng)提供的。能不能把這個對話框放到我的文件導入向?qū)Ю锩婺兀?/span>
?
嗯
…
?
我查了一下。是可以這樣做的，但這不是一件
好玩
的事，而且要花好幾個小時的時間。我能不能不使用導入向?qū)У姆绞侥兀课抑貙懥艘幌挛业囊?guī)約：
?
兩個菜單項：
1）從網(wǎng)上導入網(wǎng)頁
-> 顯示
URL
輸入
對話框
2）從磁盤上導入網(wǎng)頁
–> 顯示打開文件對話框
??
這就好多了。三分鐘的設(shè)計時間，省了我?guī)讉€小時的編程序時間。
?
如果你這輩子花了二十分鐘以上的時間去編軟件代碼的話，你就可能發(fā)現(xiàn)了一條規(guī)則：事情沒有看起來那么簡單。
?
就像拷貝文件這樣簡單的事，都充滿了危險。如果第一個參數(shù)是個目錄會如何？如果第二個參數(shù)是個文件會如何？如果同名的文件已經(jīng)存在于目的子目錄會如何？如果你沒有寫的權(quán)限又會如何？
?
如果在拷貝文件的過程中失敗了怎么辦？如果目的地是在一個遠程計算機上，但是需要身份驗證怎么辦？如果文件很大但網(wǎng)絡(luò)連接又慢，所以你需要顯示一個進度條怎么辦？如果文件傳輸速度降到幾乎是零了，你什么時候放棄拷貝而給用戶一個錯誤信息呢？
?
一個面試測試員的好辦法，就是給他們一個簡單的操作過程，然后讓他們列出可能出現(xiàn)的錯誤情況。一個在
Microsoft面試時典型的問題就是：你怎樣去測試打開文件對話框呢？一個好的測試員，可以輕而易舉地列出幾十個令人難以想到的情況去測試（比如“一個文件顯示在對話框里，然后你去打開它，但是在你按打開的按鈕之前，這個文件被另一個用戶刪除了”）。
?
好，我們得到這樣一個公理：事情沒有看起來那么簡單。
?
軟件工程里還有一個指導思想，那就是你要永遠想方設(shè)法去減低風險性。一個要特別小心去避免的風險，就是項目進度延期的風險。項目延期很不好，因為老板會訓你，鬧得你挺不高興的。除此之外，這也存在經(jīng)濟方面的原因，那就是當初你決定給你的軟件加某個功能的時候，你覺得這個功能只需要一個星期就能完成。現(xiàn)在你認識到該功能需要二十個星期才能完成，那么你當初的決定當然就是錯的。如果你當初就知道需要花掉二十個星期的話，你可能就作出不同的決定了。你作出的錯誤決定越多，你公司的財產(chǎn)被一次性沖銷處理的可能性就越大（甚至你們公司的標志會被收入債權(quán)人的
倉庫
）。到時候你的前老板抱怨道：“我們公司關(guān)門倒閉了不說，氣人的是連上
fuckedcompany
的資格都沒有。”
?
事情沒有看起來那么簡單，再加上減低風險性的指導思想，只能讓你得出如下的結(jié)論：
?
先設(shè)計再編程序，先思而后行。
?
讓你失望了，很抱歉。我知道你讀過
Kent Beck
的書，
所以你以為動手之前不做設(shè)計是可以的。對不起，那是不可以的。你修改程序不可能像修改設(shè)計文件那樣“容易”。有些人總是發(fā)表這樣的謬論：“我們現(xiàn)在用高級工具了，像
Java和XML。 我們在幾分鐘之內(nèi)，就可以改動程序里的很多東西。為什么不在程序里直接設(shè)計呢？”哥們兒，你可以在你自行車上加個發(fā)動機，但你不能把它變成汽車。如果你以為把你拷貝文件的程序，由線程式改為搶占式，而且改得比我寫這句話還快，那你就大錯特錯了。
?
不管怎么說，我不認為
Extreme Programming
是在鼓吹零設(shè)計的理念。他們只是說：“不要作任何無必要的設(shè)計”，這沒有什么錯嘛。但人們聽到的并不是這樣。大多數(shù)程序員是在找不用設(shè)計的借口，所以他們像飛蛾撲火般投向“不用設(shè)計” 這個餿主意。這是一種奇怪的，讓你事倍功半的懶惰方式。我懶得先在紙上把這個功能給設(shè)計好了，所以我就先寫程序，然后發(fā)現(xiàn)不對，我就去改，結(jié)果反倒花更多的時間。或者，更經(jīng)常發(fā)生的是，我先寫些程序，發(fā)現(xiàn)它不對，但是沒時間改了，結(jié)果我的產(chǎn)品質(zhì)量低劣，而且我還是要找出些借口，說明它為什么“一定要那樣“。那只不過是馬虎潦草，缺乏職業(yè)精神。
?
Linus Torvalds
攻擊設(shè)計
的時候，他是在講那些規(guī)模龐大的系統(tǒng)。大規(guī)模的系統(tǒng)必須慢慢進化，要不然它們就變成
Multics
了。他不是在說你那個拷貝文件的程序。你再想想，
Linus Torvalds
腦子里有一個很清楚的路線圖，知道他要到哪去，所以他覺得設(shè)計沒什么用，也不足為奇。但不要上當，基本上說那對你不適用。
Linus Torvalds
比我們聰明多了，所以他能干的事，不等于我們一般人也能干。漸增式設(shè)計及實現(xiàn)是好事。頻繁地發(fā)布版本是可以的（但針對在大眾市場上的軟件來說，頻繁發(fā)布版本會使用戶不高興，絕不是個好主意——可以多搞些內(nèi)部的里程碑取而代之）。設(shè)計上不要拘泥于形式，那只是浪費時間。我從來沒有見過某個項目得益于不動腦筋的流程圖、
UML
、
CRC
，
或者其他什么時髦的，花里呼哨的設(shè)計方法。至于那些
Linus Torvalds
說的系統(tǒng)，
那些
有一千萬行代碼程序的龐然大物，它們應(yīng)該慢慢進化，因為人類還不知道怎樣設(shè)計那種規(guī)模的軟件。
?
但是當你坐下來寫你的拷貝文件的程序，或者計劃給你的軟件下個版本增添功能的時候，你一定要先作設(shè)計。不要讓報急的號角使你草草動手。