如果你可以一一教導使用者如何運用你寫的框架那麼準則就是多餘的。
這本書中的準則就是要幫助框架作者與框架使用者之間建立共通語言。
在早期的開發應用程式的工具有:編譯器、standard libraries、系統 API，但是開發者發現非常多的重複程式碼，這些程式碼可以通過高階的API進行抽象化， 系統開發商也發現只要讓開發者能以更低的代價使用它們的系統來進行開發，這樣系統的相關應用程式的數量就會增加，最後吸引大量的末端使用者。
之後業界開始接受 OOP 的設計，因為它有利於可擴展性與可復用性，就有大量的軟體供應商改用 OOP 提供可復用的函式庫，就有框架的概念產生了， 開發者就不必從頭開始開發，反而是透過框架提供大部分的程式碼，最後開發者只需對其自定義和連接形成應用程式。
隨著大量的軟體供應商開始提供可復用的函式庫，開發者發現這些函式庫並不能在同一個應用程式中很好的組合在一起，這對生產力有負面影響， 所以需要制定通用的規則確保可復用的函式庫能夠有一致性與無縫集成的能力。
1.1 設計精良的框架特質
有許多因素可以定義一個優良的程式，例如:可靠性(reliability)、安全性(security)、性能(performance)、依賴管理(dependency management) 等等。
優量的框架也有相同的特質，但框架是由一系列可復用的 API 組成的，下面列出了幾點需要特殊考量的因素。
1.1.1 (Well-Designed Frameworks Are Simple)
在開發流程中因為各種需求常常會犧牲簡單性，如果覺得當前的功能設計過於複雜，最好的辦法就是把該功能從當前發佈版本中移除，並在下一次發佈前 花更多時間去做正確的設計。
對於框架設計者而言，「你永遠可以新增功能，但是永遠不能移除」，所以感覺設計不合適最好把它拿掉。
測試一個API是否具備簡單性可以試試 client-first programming。首先說明 library 的用途然後要求開發者根據自己的想法來編寫程序， 看看開發者實做出來的跟你自己實做出來的是否相同，或者可以與多人一起，如果大多數的人都寫出相似的程式碼，又與你寫的不一致那麼就代表 它們是對的，而你是錯的。
1.1.2 (Well-Designed Frameworks Are Expensive to Design)
優秀的框架需要花費大量的時間與資源並且努力工作所產生出來的結果。
框架設計應該是明確的，因為他需要適當的設計、調配人手、並被執行。 也必須是獨立的，因為它不能只是實現流程的一部分，有些常見的框架最後只是由一些公開的類型或成員組合而成的。
最好的框架需要由明確的由負責框架設計的人來完成，不可以混淆職責，這會導致設計中暴露實現細節。
1.1.3 (Well-Designed Frameworks Are Full of Trade-Offs)
世界上並沒有完美的設計，設計就是要做出取捨，關鍵是要了解所有的選項，並且知道它們的優勢與不足。 如果你發現設計過程中不需要做出取捨，那只代表你忽略了某些重大的問題。
1.1.4 (Well-Designed Frameworks Borrow from the Past)
大多數成功的框架都會借鑑成熟的設計並以此作為基礎來建構，因入新的解決方法需要非常小心謹慎。
最好讓你的函式庫保持乏味而不是充滿創新的內容，因為你需要做的是功能而不是需引人，如果只在某一的方面進行創新而導致用戶需要改變使用習慣並不值得。
1.1.5 (Well-Designed Frameworks Are Designed to Evolve)
需要思實做任何的設計時會不會影響框架的後續發展，仔細考量可以避免引入的東西隨著時間而退化，甚至到後面不能保持向後兼容性， 最好是將新功能推遲到下一次發佈，而不是在當前發佈中引入。
1.1.6 (Well-Designed Frameworks Are Integrated)
現代框架需要能夠很好的與大量不同的開發工具、編成語言、應用模型等集成在一起。
1.1.7 (Well-Designed Frameworks Are Consistent)
一致性是設計精良的框架的核心特質，是影響生產力的最重要因素。
一致性的框架可以讓開發者能夠將他們的知識轉移到目前正在學習的內容，一致性也能使開發者快速辨識那些功能部份是獨特的，哪些則是平常的設計模式與慣例。