第 1 章 引言 1 1.1 決策的后果與模式 2 1.1.1 單元測試 2 1.1.2 單元測試與集成測試的比例 3 1.2 設計模式及其失效分析 5 1.3 架構設計模式及其失效分析 10 1.3.1 可擴展性與彈性 11 1.3.2 開發(fā)速度 12 1.3.3 微服務的復雜性 12 小結 14 第 2 章 代碼重復不一定是壞事：代碼重復與靈活性的權衡 15 2.1 代碼庫間的通用代碼及重復代碼 16 2.1.1 添加新需求導致的代碼重復 17 2.1.2 實現(xiàn)新的業(yè)務需求 17 2.1.3 結果評估 19 2.2 通過庫在代碼庫之間共享代碼 19 2.2.1 共享庫的取舍與不足 20 2.2.2 創(chuàng)建共享庫 21 2.3 抽取代碼為一個獨立的微服務 22 2.3.1 采用獨立微服務方式的取舍與弊端 24 2.3.2 關于獨立微服務的總結 27 2.4 通過代碼重復改善松耦合 28 2.5 利用繼承減少 API 設計中的重復 31 2.5.1 抽取出一個請求處理器作為基類 33 2.5.2 繼承與緊耦合的取舍 35 2.5.3 繼承與組合的取舍 36 2.5.4 一貫性的重復與偶然性的重復 37 小結 38 第 3 章 異常及其他——代碼錯誤的處理模式 39 3.1 異常的層次結構 40 4 3.2 代碼異常處理的*佳模式 44 3.2.1 公共 API 的已檢測異常處理 45 3.2.2 公共 API 的未檢測異常處理 46 3.3 異常處理的反模式 47 3.3.1 異常時，關閉資源 49 3.3.2 反模式：利用異常控制應用流 51 3.4 源自第三方庫的異常 51 3.5 多線程環(huán)境中的異常 54 3.6 使用 Try 以函數(shù)式的途徑處理異常 59 3.6.1 在生產(chǎn)代碼中使用 Try 62 3.6.2 混合使用 Try 與拋出異常的代碼 64 3.7 異常處理策略的性能對比 65 小結 68 第 4 章 靈活性與復雜性的權衡 70 4.1 一個健壯但無法擴展的API 71 4.1.1 設計一個新組件 71 4.1.2 從*簡單的代碼開始 72 4.2 允許客戶使用自己的指標框架 75 4.3 通過鉤子為你的 API提供可擴展性 77 4.3.1 防范鉤子