Framework Design Guidelines 筆記 (1) : 優良框架的特徵
Michael Tsai
8/31/2009
小引
網路上有不少人推薦這本書，我也覺得是本內容紮實的好書。原以為應該很快就能看到中文版了，但一直到第二版都沒看到影子（中國大陸有出第一版的簡體版）。我想，這多少是因為從書名來看，它似乎是專門寫給 framework designers 看的，目標讀者的市場太小了。
其實，在目前的程式設計環境，開發人員多少都得碰觸到共用類別／元件的撰寫，即便是元件的使用者（或 app programmers），瞭解好的程式寫法與設計原則，對提升軟體品質也大有幫助。
另一個原因，也許和書中所提的類別設計原則與程式寫法（如命名規則、exception 的處理建議等）比較細緻有關。撰寫一般的 app code 時，多以結果導向，即程式能跑、功能正確就行，至於 end users 看不到的程式碼，自己想怎麼寫就怎麼寫。尤其在專案時程很趕，與時間賽跑的情況下（哪個案子不是這樣？），哪還有閒功夫去琢磨：這個變數怎麼命名比較好、那些 code 是否要抽離成共用類別或函式、有哪些 patterns 可以 reuse 呢？
但我一直覺得，就像人品一樣，程式碼的品質會反映在軟體系統的外在行為上，使用者必定能感受到。也許他們看不到程式碼寫得怎麼樣，但是操作介面難用、執行效能差、不易擴充（要求稍微改一點東西就說程式很難改）、大小 bug 不斷...等等，都顯示出軟體系統的內在（架構與設計）出了問題。
我打算節譯部分內容，放在部落格上。一方面作筆記，一方面也向大家推薦這本書。至於會寫多少篇，倒也沒認真去想，若有時間的話，看到哪兒就寫到哪兒吧。
以下開始內容摘要，我自己的話是用暗橘色標示。
優良框架的特徵
- 優良的框架一定很精簡
大部分的框架都不缺功能，因為只要需求明確，增加功能就很容易。
另一方面，當開發過程中出現時程壓力、功能蔓延（feature creep）等問題，或想要滿足每一項枝微末節的需求時，簡單性（simplicity）通常就會被犧牲掉。
如果多考慮一下設計的複雜性，你會發現，把目前版本的一些功能砍掉，並將時間花在思考下一個版本該如何設計才適當，這麼做通常會有比較好的結果。
如框架設計師常說的：「功能隨時可以加，但要將它移除可就難了。」 - 優良的框架須付出較高的設計成本
框架設計應該是開發流程中的一項明確且專屬的工作，因為這項工作需要謹慎規劃、組織人力、並有效執行，它不應流於實作過程中的附屬產品。
（問題是有多少軟體公司願意聘用專職的 framework designer？看他好像閒閒沒事在看書的時候，可能還是忍不住叫他去打雜吧。正所謂物盡其用..... >_<|||） - 優良的框架充滿權衡取捨
沒有所謂「完美設計」這種東西。設計其實就是一連串的權衡取捨，然後做出正確決定。你得瞭解各種選項的優點和缺點。如果在設計時都沒有碰到需要取捨的情況，那不是你發現銀彈了，而是可能很多重要的地方都沒考慮到。 - 優良的框架會善用既有成果
- 優良的框架能持續演進
- 優良的框架易於整合
- 優良的框架具備一致性
說到設計的簡單性，還真的不簡單。
碰到需要處理大量資料的情況就直接開個超大陣列，這種寫法簡單嗎？簡單，而且通常過於天真。
我曾看過一個 .NET 類別庫裡面有個工具類別提供一個叫做 CreateDirectory 的 method。好奇它跟 System.IO.Directory 的 CreateDirectory 有甚麼不同，挖出原始碼一看：
public void CreateDirectory(string path)
{
If (!System.IO.Directory.Exists(path))
{
System.IO.Directory.CreateDirectory(path);
}
}
這函式設計得簡單嗎？簡單，但是多餘。這種連雞肋的價值都談不上的 method，除了增加類別庫的體積和重量之外，別無益處。
也許設計者希望使用此類別的程式設計師少寫一些 code，但問題是，當欲建立的目錄已經存在時，System.IO.Directory.CreateDirectory 本來就不會發生錯誤，何必多此一舉呢？
元件或框架設計師必須非常瞭解基礎類別庫的行為，才不會為了提供方便的工具而重新發明一堆輪子。增加 methods 時若未審慎考量，一旦使用類別庫的程式設計師用慣了，專案中到處充斥這些 method calls，將來要拿掉可就麻煩了。
請神容易送神難。框架設計師豈可不慎？
相關文章
