總結
設計原則小結
這些是本書中討論的最重要的軟體設計原則：
- 複雜性是增量產生的：您必須努力處理小事情（請參閱 第 2.4 節）。
- 能工作的程式碼是不夠的（請參閱 第 3.2 節）。
- 持續進行小額投資以改善系統設計（請參閱 第 3.3 節）。
- 模組應該是深的（請參閱 第 4.4 節）
- 介面的設計應儘可能簡化其最常見的用法（請參閱 第 4.7 節）。
- 讓模組的介面簡單比讓其實現簡單更為重要（請參閱 第 8 章 和 第 9.7 節）。
- 通用模組是更深的（請參閱 第 6 章）。
- 分開通用程式碼和專用程式碼（請參閱 第 6.6 節 和 第 9.4 節）。
- 不同的層級應具有不同的抽象（請參閱 第 7 章）。
- 下沉複雜性（請參閱 第 8 章）。
- 透過定義來規避錯誤（請參閱 第 10.3 節）。
- 設計兩次（請參閱 第 11 章）。
- 註釋應該描述程式碼中難以理解的內容（請參閱 第 13 章）。
- 軟體應被設計成易於閱讀而不是易於編寫（請參閱 第 18.2 節）。
- 軟體開發的增量應該是抽象而不是功能（請參閱 第 19.2 節）。
- 區分重要的和不重要的事情，並強調重要的事情（請參閱 第 21 章）。
危險訊號小結
這些是本書中討論的一些最重要的危險訊號。系統中任何這些症狀的存在都表明系統的設計存在問題：
- 淺模組：類或方法的介面並不比其實現簡單得多（請參閱 第 4.5 節 和 第 13.5 節）。
- 資訊洩露：設計決策反映在多個模組中（請參閱 第 5.2 節）。
- 時間分解：程式碼結構基於執行操作的順序，而不是基於資訊隱藏的原則（請參閱 第 5.3 節）。
- 過度暴露：API 強迫呼叫者在使用常用功能的時候還需要去了解那些很少使用的功能（請參閱 第 5.7 節）。
- 透傳方法：一種幾乎不執行任何操作的方法，只是將其引數傳遞給具有相似簽名的另一個方法（請參閱 第 7.1 節）。
- 重複：一遍又一遍的重複程式碼（請參閱 第 9.4 節）。
- 通用專用混合體：專用程式碼與通用程式碼沒有整潔地分開（請參閱 第 9.5 節）。
- 連體方法：兩個方法之間的依賴很多，以至於很難在不理解一個方法的實現的情況下理解另一個方法的實現（請參閱 第 9.8 節）。
- 註釋重複了程式碼：註釋中的所有資訊在旁邊的程式碼裡顯而易見（請參閱 第 13.2 節）。
- 實現文件汙染了介面：介面註釋描述了其使用者不需要了解的實現細節（請參閱 第 13.5 節）。
- 模糊的名稱：變數或方法的名稱過於不精確，以至於它不能傳遞太多有用的資訊（請參閱 第 14.3 節）。
- 難以選取名稱：很難為實體提供一個精確而直觀的名稱（請參閱 第 14.3 節）。
- 難以描述：為了得到完整的描述，變數或方法的文件必須很長（請參閱 第 15.3 節）。
- 難以理解的程式碼：一段程式碼的行為或含義不容易被理解（請參閱 第 18.2 節）。
關於作者
John Ousterhout 是斯坦福大學的 Bosack Lerner 計算機科學教授。他當前的研究重點是新的軟體堆疊層，以允許資料中心應用程式利用具有微秒級延遲的通訊和儲存技術。Ousterhout 之前的 14 年經歷在工業界，並創辦了 Scriptics 和 Electric Cloud 這兩家公司，再之前的 14 年則是加州大學伯克利分校的計算機科學教授。他是 Tcl 指令碼語言的建立者，並且以在分散式作業系統和儲存系統中的工作而聞名。Ousterhout 在耶魯大學獲得了物理學學士學位，並在卡內基梅隆大學獲得了計算機科學博士學位。他是美國國家工程院院士，並獲得了無數獎項，包括 ACM 軟體系統獎、ACM Grace Murray Hopper 獎、美國國家科學基金會總統年輕研究者獎和 UC Berkeley 傑出教學獎。