經典好文推薦︰What is Software Design? By Jack W. Reeves

作者Jack W. Reeves發表What is Software Design?這篇文章於1992年，13年後作者又寫了另一篇文章回顧當時的觀點。全文可以在這個網址下載。這篇文章引起的迴響很大，有堅決反對的意見，也有很多人受它啟蒙而用全新的角度看整個軟體開發的行為。我個人是屬於後者。這些觀點在1992年就提出，非常具有前瞻性，和後來的Extreme Programming的主張互相呼應，間接預言了將程式碼視為文件、自動測試、重構、Simple Design等觀念。

這篇文章探討的，是什麼叫做軟體設計。台灣大多數的軟體公司，將程式設計師視為一種機械性的勞力密集工作，只需要資淺，受過簡單訓練的新手就可以擔任。程式設計師的工作，是將系統設計師（SD）開出來的規格實做出來。還在這個模型下，引進工業工程的大量生產的管理辦法，稱為"軟體工程"。具我所知台灣最大的幾家軟體整合的公司都是走這樣的類比思維。

作者很仔細地觀察比較工業開發生產行為和軟體開發行為，發現一些相似處被忽略了，但是不相似的部份又硬被做類比。我非常推薦所有軟體人都讀這篇充滿智慧的文章。底下簡單條列一些本文的重點。如果您不介意先知道結果會破壞閱讀的樂趣，請往下讀︰

1. 一般認為程式師是勞力密集的組合工人。他們的工作是遵照設計文件的指示進行製造（設計文件是由較有才能的設計師所做出來的），製造的成品是原始碼。對於這點，作者提出了不同的觀點

• 和其他工程類型相類比，軟體的設計文件指的是程式師寫的原始碼。寫程式的過程是設計師的複雜心智活動。而生產製造是編譯器（compiler）的工作。編譯器根據設計文件（原始碼）建造出成品（執行檔）。
• 當你設計完一個橋樑，要用設計成本的十倍來建造那座橋樑；而和一般工程不同的是，軟體的製造是編譯，編譯成本幾乎是零。
  
• 在其他的工程領域，設計常常會被建造的成本限制住，而不被鼓勵做得太複雜。軟體設計活動的其中一項特色是高複雜度。主要原因是因為製造成本超低：幾乎是免費。假想軟體每項設計都牽涉到開模具，訂購材料與零件，調整生產線，今天的軟體就不會做成那麼複雜。
• 由於製造時間很短（compile一次的時間），所以設計（包含coding）活動幾乎佔滿軟體開發過程的全部。不像其他工程，設計跟製造各佔相當比重的時間。

2. 一般認為SD完成設計文件後就完成了他的工作，可以交給程式師實作，SD可以再去忙其他專案。對於這點，作者的觀點是

• 設計的過程有很多種形式，畫各種圖表、在白板前腦力激盪，或著對著天花板發呆地思考，製作雛型等。但是要進行到寫成程式碼經過驗證，設計的工作才算完成。
• 即使資深的高階設計的人員也要親自參與programming。

3. 仿造一般工程的作法，設計文件需要繁重的手續和review預防不良設計，不斷改善。一旦確定以後，必須將設計凍結，才能開始進入寫程式階段。實務上在寫程式過程仍然會發生設計文件的問題需要修改，和流程的規定牴觸。如果不修改，要選擇用不自然的方式去實現那個設計，最後會造成程式碼複雜到難以維護。關於這點，作者的回應是︰

• 橋樑、飛機由於建造成本高，設計結果需要做出模型做各種實驗來驗證，如電腦模擬、風洞測試等等，不斷改進與修正。
• 但是軟體開發有建造成本超便宜的特性，可以不用對設計本身作太多驗證，而直接做出產品(編譯出執行檔)，對成品驗證就夠了。如果有好的靈感或想法，最好即早用程式碼來驗證。

4. 一般將軟體瑕疵（臭蟲）視為生產線中的瑕疵品。希望提昇良率，降低testing/debug的成本。作者的觀念是

• 由於寫程式是設計的行為，除錯應該和一般的工程的風洞實驗及電腦數值模擬後改良設計一樣，應視為設計的過程。不適用生產線的品管方法。

5. 很多人期待有一個與語言無關的記號方法，能用來做設計文件（類似uml、dfd吧），程式師只要依照該文件來製造出程式碼。作者雖然傾向用程式碼作為設計文件，但是他也認同︰

• 用程式語言作為表達設計概念的工具，的確有其不足之處。例如表達高階架構的概念。
• 所幸隨著程式語言的演進，C++、Java等現代的語言也適合於表達高階的概念。
• 用程式語言表達設計概念，另一個不足之處是domain knowledge難以在程式碼中表達。為了補足程式碼作為設計文件的不足，其他輔助文件是有幫助的。但是不能取代最主要的設計文件：程式碼。

6. 一般假設各層次的設計是互相隔絕的活動。分析文件凍結後進入設計，設計文件凍結後進入程式撰寫。因而將這整個流程視為生產線的上中下游。作者的觀點是：

• 現實世界中，高階與低階的設計不可能全然切開。
• 低階設計發現的問題有可能需要高階設計徹底的改變作為配合。
• 所以所有的設計一定要到程式碼的等級才算完成。

以製造業起家的台灣，軟體公司的管理方法普遍都用生產線的邏輯，即使導入ISO或CMMI，往往也只是更強化這個錯誤的類比。為甚麼不管怎麼修改流程，死亡行軍式的專案地獄還是層出不窮？甚至讓老闆們都不再相信流程改善的投資了，因為不會反應在專案的效率上。這篇文章可以幫助我們檢討軟體流程出了什麼問題。