科技人筆記: Framework

Framework Design Guidelines 筆記 (3) : 情節驅動設計

關鍵詞彙

scenario-driven design（情節驅動設計）
use cases（使用案例）
test-driven development, TDD（測試驅動開發）
框架設計師經常犯的錯誤，是先以各種設計方法論來設計物件模型，然後為這些設計好的 API 撰寫範例程式。問題是，大多數的設計方法（包括物件導向設計）都是以可維護性為主要考量，而未著重在 API 的易用性；它們非常適合用來設計僅供內部使用的程式架構，但不適合用來設計大型框架的共用 API 層。
- DO　先為主要情節撰寫範例程式碼，然後再從這些範例程式發展出對應的物件模型。

Framework Design Guidelines 筆記 (2) : 漸進式框架

表示法

DO: 表示強烈建議、務必遵守的設計原則。
CONSIDER: 建議考慮這麼做。
DO NOT: 禁止事項。
AVOID: 儘量避免的做法。
DO　設計框架時要兼顧功能強大與容易使用。

如 Alan Kay 所說：「簡單的東西就要有簡單的設計，而碰到複雜的情況時也應該要能應付。」（Simple things should be simple and complex things should be possible.）
DO　設計時應考量廣大開發人員的各種程式設計風格、需求、以及不同的技術水平。
DO　設計時應考量支援各種程式語言。

漸進式框架

一套框架要能同時兼顧各類開發人員、需求、和程式語言，是相當困難且昂貴的事業。以往，開發軟體元件的廠商是針對特定開發族群和特定需求來提供多種解決方案，例如微軟的 Visual Basic、MFC、ATL 等等。

這些特定用途的 APIs 雖然強大好用，卻有個主要缺點：當開發人員要從目前的技術領域移向另一塊領域時，學習曲線會非常陡峭，因為那等於是要學習另一套新的東西。

比較好的解決方式，是提供所謂的漸進式框架（progressive framework）。這種框架的特色是兼顧各類型的開發人員，且適用範圍較廣，從比較簡單的需求到進階的應用都能應付。

.NET Framework 即屬於漸進式框架，它有單一的程式撰寫模型，支援廣泛類型的應用需求與技術層次，學習曲線也較為緩和，能夠由簡入繁、循序漸進。

Framework Design Guidelines 筆記 (1) : 優良框架的特徵

撰寫一般的 app code 時，多以結果導向，即程式能跑、功能正確就行，至於 end users 看不到的程式碼，自己想怎麼寫就怎麼寫。尤其在專案時程很趕，與時間賽跑的情況下（哪個案子不是這樣？），哪還有閒功夫去琢磨：這個變數怎麼命名比較好、那些 code 是否要抽離成共用類別或函式、有哪些 patterns 可以 reuse 呢？

優良框架的特徵

1. 優良的框架一定很精簡

大部分的框架都不缺功能，因為只要需求明確，增加功能就很容易。另一方面，當開發過程中出現時程壓力、功能蔓延（feature creep）等問題，或想要滿足每一項枝微末節的需求時，簡單性（simplicity）通常就會被犧牲掉。如果多考慮一下設計的複雜性，你會發現，把目前版本的一些功能砍掉，並將時間花在思考下一個版本該如何設計才適當，這麼做通常會有比較好的結果。如框架設計師常說的：「功能隨時可以加，但要將它移除可就難了。」

2. 優良的框架須付出較高的設計成本

框架設計應該是開發流程中的一項明確且專屬的工作，因為這項工作需要謹慎規劃、組織人力、並有效執行，它不應流於實作過程中的附屬產品。

3. 優良的框架充滿權衡取捨

沒有所謂「完美設計」這種東西。設計其實就是一連串的權衡取捨，然後做出正確決定。你得瞭解各種選項的優點和缺點。如果在設計時都沒有碰到需要取捨的情況，那不是你發現銀彈了，而是可能很多重要的地方都沒考慮到。

4. 優良的框架會善用既有成果

5. 優良的框架能持續演進

6. 優良的框架易於整合

7. 優良的框架具備一致性