軟件設計的哲學（第2版）A Philosophy of Software Design, 2nd Edition Paperback – July 26, 2021
[美]約翰·奧斯特豪特（John Ousterhout）
商品描述
本書深入探討了軟件設計中的核心問題：如何將復雜的軟件系統分解為可以相對獨立實現的模塊（例如類和方法），從而降低其復雜性並提高開發效率。本書首先介紹了軟件設計中的基本問題，即復雜性的本質。其次，討論了有關如何處理軟件設計過程的“哲學”問題，如通用設計的重要性、與《代碼整潔之道》中設計哲學的對比，以及如何將重要的東西和不重要的東西區分開等內容。最後，總結了在軟件設計過程中應遵循的一系列設計原則，以及一系列識別設計問題的警示信號。
本書適合軟件工程師、電腦科學專業的學生、教育者、對軟件設計和開發感興趣的自學者和技術管理者閱讀。通過應用本書中的思想，讀者可以最大限度地降低大型軟件系統的復雜性，從而更快地以更低的成本編寫軟件，並構建更易於維護和增強的系統。
作者簡介
[美]約翰·奧斯特豪特（John Ousterhout）
斯坦福大學電腦科學教授，美國國家工程院院士，曾任加州大學伯克利分校的電腦科學教授；獲得了包括ACM軟件系統獎、ACM Grace Murray Hopper獎、美國國家科學基金會總統青年研究者獎和加州大學伯克利分校傑出教學獎等多項榮譽；聚焦於與構建軟件系統的基礎設施相關的廣泛主題，包括分佈式系統、操作系統、存儲系統、開發框架和編程語言；在工業界有14年的經驗，創辦了Scriptics 和Electric Cloud兩家公司；Tcl腳本語言的創建者，並且以分佈式操作系統和存儲系統的相關工作而聞名。
譯者：
茹炳晟
騰訊Tech Lead（技術經理），騰訊研究院特約研究員，騰訊集團技術委員會委員，中國電腦學會(CCF)TF研發效能SIG主席，“軟件研發效能度量規範”團體標準核心編寫專家，中國商業聯合會因特網應用技術委員會智庫專家，中國通信標準化協會TC608雲計算標準和開源推進委員會雲上軟件工程工作組副組長，國內外各大技術峰會的聯席主席、出品人和Keynote演講嘉賓，公眾號“茹炳晟聊軟件研發”主理人。著有技術暢銷書《測試工程師全棧技術進階與實踐》和《現代軟件測試技術之美》等，譯有《現代軟件工程》和《DevOps 實踐指南（第2版）》等。
王海鵬
1994年畢業於華東師範大學，獲物理學理學學士學位和英國語言文學學士學位；是獨立咨詢顧問、培訓講師、譯者和軟件開發者；擁有30年的軟件開發經驗，專註於軟件架構和方法學研究，致力於提高軟件開發的品質與效率；翻譯了20餘本軟件開發相關圖書，內容涵蓋敏捷方法學、需求工程、UML 建模和測試等多個領域。
目錄大綱
第 1章 導言 001
1.1 如何使用本書 004
第 2章 復雜性的本質 007
2.1 復雜性的定義 007
2.2 復雜性的表現 009
2.3 復雜性的原因 012
2.4 復雜性是增量的 014
2.5 結論 015
第3章 能工作的代碼是不夠的 017
3.1 戰術性編程 017
3.2 戰略性編程 019
3.3 投資多少？ 020
3.4 初創企業與投資 022
3.5 結論 023
第4章 模塊應該深 025
4.1 模塊化設計 025
4.2 接口包含哪些內容？ 027
4.3 抽象 028
4.4 深模塊 029
4.5 淺模塊 031
4.6 類炎 033
4.7 示例：Java和UNIX I/O 033
4.8 結論 035
第5章 信息隱藏（和泄漏） 037
5.1 信息隱藏 037
5.2 信息泄漏 039
5.3 時序分解 040
5.4 示例：HTTP服務器 041
5.5 示例：類過多 042
5.6 示例：HTTP參數處理 043
5.7 示例：HTTP響應中的默認值 045
5.8 類內的信息隱藏 046
5.9 過猶不及 047
5.10 結論 047
第6章 通用模塊更深 049
6.1 讓類有點通用 049
6.2 示例：為編輯器存儲文本 051
6.3 更通用的API 052
6.4 通用性帶來更好的信息隱藏 054
6.5 要問自己的問題 055
6.6 將專用性向上推（和向下推） 056
6.7 示例：編輯器撤銷機制 057
6.8 消除代碼中的特例 060
6.9 結論 061
第7章 不同層，不同抽象 063
7.1 直通方法 064
7.2 接口重復何時可行？ 066
7.3 裝飾器 067
7.4 接口與實現 069
7.5 直通變量 070
7.6 結論 073
第8章 降低復雜性 075
8.1 示例：編輯器文本類 076
8.2 示例：配置參數 076
8.3 過猶不及 078
8.4 結論 078
第9章 合並好，還是分開好？ 079
9.1 如果共享信息，則合並 081
9.2 如果可以簡化接口，則合並 081
9.3 消除重復，則合並 082
9.4 區分通用代碼和專用代碼 085
9.5 示例：插入光標和選擇區域 086
9.6 示例：單獨的日誌類 087
9.7 拆分和連接方法 089
9.8 不同意見：《代碼整潔之道》 092
9.9 結論 093
第 10章 避免處理異常 095
10.1 為何異常會增加復雜性 095
10.2 異常太多 098
10.3 定義錯誤不存在 100
10.4 示例：Windows中的文件刪除 100
10.5 示例：Java的substring方法 101
10.6 異常屏蔽 103
10.7 異常聚合 104
10.8 就讓它崩潰 109
10.9 過猶不及 110
10.10 結論 111
第 11章 設計兩次 113
第 12章 為什麽要寫註釋？4個藉口 117
12.1 好的代碼自己就是文檔 118
12.2 我沒有時間寫註釋 119
12.3 註釋會過時，會產生誤導 120
12.4 我見過的註釋都沒有價值 121
12.5 寫好註釋的好處 121
12.6 不同觀點：註釋就是失敗 122
第 13章 註釋應描述代碼中不明顯的內容 125
13.1 選擇約定 126
13.2 不要重復代碼 127
13.3 低層註釋增加精確度 130
13.4 高層註釋增強直觀性 133
13.5 接口文檔 136
13.6 實現註釋：做什麽和為什麽，而不是怎麽做 144
13.7 跨模塊設計決策 146
13.8 結論 149
13.9 13.5節問題解答 150
第 14章 選擇名稱 151
14.1 示例：糟糕的名稱會導致缺陷 151
14.2 塑造形象 153
14.3 名稱應精確 153
14.4 一致地使用名稱 157
14.5 避免多餘的詞 158
14.6 不同意見：Go風格指南 159
14.7 結論 161
第 15章 先編寫註釋 163
15.1 拖延的註釋是糟糕的註釋 163
15.2 先編寫註釋 164
15.3 註釋是一種設計工具 165
15.4 早期註釋是有趣的註釋 166
15.5 早期註釋是否昂貴？ 167
15.6 結論 168
第 16章 修改現有代碼 169
16.1 持續使用戰略性編程 169
16.2 維護註釋：讓註釋靠近代碼 171
16.3 註釋屬於代碼，而非提交日誌 172
16.4 維護註釋：避免重復 173
16.5 維護註釋：檢查差異 175
16.6 更高層次的註釋更容易維護 175
第 17章 一致性 177
17.1 一致性的例子 177
17.2 確保一致性 178
17.3 過猶不及 181
17.4 結論 181
第 18章 代碼應顯而易見 183
18.1 讓代碼更顯而易見 184
18.2 讓代碼不顯而易見的因素 186
18.3 結論 190
第 19章 軟件發展趨勢 191
19.1 面向對象編程和繼承 191
19.2 敏捷開發 193
19.3 單元測試 194
19.4 測試驅動開發 196
19.5 設計模式 197
19.6 取值方法和設值方法 197
19.7 結論 198
第 20章 性能設計 199
20.1 如何考慮性能 199
20.2 修改前（後）的度量 202
20.3 圍繞關鍵路徑進行設計 203
20.4 示例：RAMCloud的Buffer類 204
20.5 結論 210
第 21章 確定什麽是重要的 211
21.1 如何確定什麽是重要的？ 211
21.2 盡量減少重要的東西 212
21.3 如何強調重要的東西 213
21.4 錯誤 213
21.5 更廣泛的思考 214
第 22章 結論 215
設計原則總結 217
警示信號總結 219
.jpg)
