# 三十四、沒有什么像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和其他人一起。