中圖網小程序
一鍵登錄
更方便
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
好代碼壞代碼(軟件工程師卓越之道) 版權信息
- ISBN：9787115596413
- 條形碼：9787115596413 ; 978-7-115-59641-3
- 裝幀：一般膠版紙
- 冊數：暫無
- 重量：暫無
- 所屬分類：>
好代碼壞代碼(軟件工程師卓越之道) 本書特色
1.易學易用：從零開始講解編程實踐，每一個經驗教訓以“壞代碼”開始，以“好代碼”結束。 2.貼合實際：通過50+條錦囊妙計、100+個案例手把手教你編寫高質量代碼。 3.內容豐富：通過11大主題解讀卓越軟件工程師編寫可靠的、易于維護的代碼的關鍵概念與技術。 4.源于實踐：內容整合作者及團隊成員多年的軟件開發實踐經驗，通過理論介紹與實戰相結合的方式詳細分析軟件開發實踐。 5.注重效率：通過清晰的注釋及代碼分析，幫你輕松理解和掌握編程技巧。
好代碼壞代碼(軟件工程師卓越之道) 內容簡介
本書分享的實用技巧可以幫助你編寫魯棒、可靠且易于團隊成員理解和適應不斷變化需求的代碼。內容涉及如何像高效的軟件工程師一樣思考代碼，如何編寫讀起來像一個結構良好的句子的函數，如何確保代碼可靠且無錯誤，如何進行有效的單元測試，如何識別可能導致問題的代碼并對其進行改進，如何編寫可重用并適應新需求的代碼，如何提高讀者的中長期生產力，同時還介紹了如何節省開發人員及團隊的寶貴時間，等等。 本書文字簡潔、論述精辟、層次清晰，適合零基礎及擁有一定編程基礎的開發人員閱讀，對于高等院校計算機及相關專業的學生，也具有很高的參考價值。
好代碼壞代碼(軟件工程師卓越之道) 目錄
第 一部分 理論
第 1章 代碼質量 3
1.1 代碼如何變成軟件 4
1.2 代碼質量目標 6
1.2.1 代碼應該正常工作 7
1.2.2 代碼應該持續正常工作 7
1.2.3 代碼應該適應不斷變化的需求 8
1.2.4 代碼不應該重復別人做過的工作 9
1.3 代碼質量的支柱 10
1.3.1 編寫易于理解的代碼 10
1.3.2 避免意外 11
1.3.3 編寫難以誤用的代碼 13
1.3.4 編寫模塊化的代碼 14
1.3.5 編寫可重用、可推廣的代碼 15
1.3.6 編寫可測試的代碼并適當測試 16
1.4 編寫高質量代碼是否會拖慢進度 17
1.5 小結 19
第 2章 抽象層次 20
2.1 空值和本書中的偽代碼慣例 20
2.2 為什么要創建抽象層次 22
2.3 代碼層次 24
2.3.1 API和實現細節 25
2.3.2 函數 26
2.3.3 類 28
2.3.4 接口 36
2.3.5 當層次太薄的時候 39
2.4 微服務簡介 40
2.5 小結 41
第3章 其他工程師與代碼契約 42
3.1 你的代碼和其他工程師的代碼 42
3.1.1 對你來說顯而易見，但對其他人并不清晰的事情 44
3.1.2 其他工程師無意間試圖破壞你的代碼 44
3.1.3 過段時間，你會忘記自己的代碼的相關情況 44
3.2 其他人如何領會你的代碼的使用方法 45
3.2.1 查看代碼元素的名稱 45
3.2.2 查看代碼元素的數據類型 45
3.2.3 閱讀文檔 46
3.2.4 親自詢問 46
3.2.5 查看你的代碼 46
3.3 代碼契約 47
3.3.1 契約的附屬細則 47
3.3.2 不要過分依賴附屬細則 49
3.4 檢查和斷言 53
3.4.1 檢查 54
3.4.2 斷言 55
3.5 小結 56
第4章 錯誤 57
4.1 可恢復性 57
4.1.1 可以從中恢復的錯誤 57
4.1.2 無法從中恢復的錯誤 58
4.1.3 只有調用者知道能否從某種錯誤中恢復 58
4.1.4 讓調用者意識到他們可能想從中恢復的錯誤 60
4.2 魯棒性與故障 60
4.2.1 快速失敗 61
4.2.2 大聲失敗 62
4.2.3 可恢復性的范圍 62
4.2.4 不要隱藏錯誤 64
4.3 錯誤報告方式 67
4.3.1 回顧：異常 68
4.3.2 顯式：受檢異常 68
4.3.3 隱式：非受檢異常 70
4.3.4 顯式：允許為空的返回類型 71
4.3.5 顯式：結果返回類型 72
4.3.6 顯式：操作結果返回類型 74
4.3.7 隱式：承諾/未來 76
4.3.8 隱式：返回“魔法值” 78
4.4 報告不可恢復的錯誤 79
4.5 報告調用者可能想要從中恢復的錯誤 79
4.5.1 使用非受檢異常的論據 79
4.5.2 使用顯式報錯技術的論據 82
4.5.3 我的觀點：使用顯式報錯技術 84
4.6 不要忽視編譯器警告 85
4.7 小結 86
第二部分 實踐
第5章 編寫易于理解的代碼 91
5.1 使用描述性名稱 91
5.1.1 非描述性名稱使代碼難以理解 91
5.1.2 用注釋代替描述性名稱是很不好的做法 92
5.1.3 解決方案：使名稱具有描述性 93
5.2 適當使用注釋 94
5.2.1 多余的注釋可能有害 94
5.2.2 注釋不是可讀代碼的合格替代品 95
5.2.3 注釋可能很適合于解釋代碼存在的理由 96
5.2.4 注釋可以提供有用的高層概述 96
5.3 不要執著于代碼行數 97
5.3.1 避免簡短但難以理解的代碼 98
5.3.2 解決方案：編寫易于理解的代碼，即便需要更多行代碼 99
5.4 堅持一致的編程風格 99
5.4.1 不一致的編程風格可能引發混亂 100
5.4.2 解決方案：采納和遵循風格指南 100
5.5 避免深嵌套代碼 101
5.5.1 嵌套很深的代碼可能難以理解 102
5.5.2 解決方案：改變結構，*大限度地減少嵌套 103
5.5.3 嵌套往往是功能過多的結果 103
5.5.4 解決方案：將代碼分解為更小的函數 104
5.6 使函數調用易于理解 105
5.6.1 參數可能難以理解 105
5.6.2 解決方案：使用命名參數 105
5.6.3 解決方案：使用描述性類型 106
5.6.4 有時沒有很好的解決方案 107
5.6.5 IDE又怎么樣呢 108
5.7 避免使用未做解釋的值 108
5.7.1 未做解釋的值可能令人困惑 109
5.7.2 解決方案：使用恰當命名的常量 110
5.7.3 解決方案：使用恰當命名的函數 110
5.8 正確使用匿名函數 111
5.8.1 匿名函數適合于小的事物 112
5.8.2 匿名函數可能導致代碼難以理解 113
5.8.3 解決方案：用命名函數代替 113
5.8.4 大的匿名函數可能造成問題 114
5.8.5 解決方案：將大的匿名函數分解為命名函數 115
5.9 正確使用新奇的編程語言特性 116
5.9.1 新特性可能改善代碼 117
5.9.2 不為人知的特性可能引起混亂 117
5.9.3 使用適合于工作的工具 118
5.10 小結 118
第6章 避免意外 119
6.1 避免返回魔法值 119
6.1.1 魔法值可能造成缺陷 120
6.1.2 解決方案：返回空值、可選值或者錯誤 121
6.1.3 魔法值可能偶然出現 122
6.2 正確使用空對象模式 124
6.2.1 返回空集可能改進代碼 125
6.2.2 返回空字符串有時可能造成問題 126
6.2.3 較復雜的空對象可能造成意外 128
6.2.4 空對象實現可能造成意外 129
6.3 避免造成意料之外的副作用 130
6.3.1 明顯、有意的副作用沒有問題 131
6.3.2 意料之外的副作用可能造成問題 131
6.3.3 解決方案：避免副作用或者使其顯而易見 134
6.4 謹防輸入參數突變 135
6.4.1 輸入參數突變可能導致程序缺陷 136
6.4.2 解決方案：在突變之前復制 137
6.5 避免編寫誤導性的函數 137
6.5.1 在關鍵輸入缺失時什么都不做可能造成意外 138
6.5.2 解決方案：將關鍵輸入變成必要的輸入 140
6.6 永不過時的枚舉處理 141
6.6.1 隱式處理未來的枚舉值可能造成問題 141
6.6.2 解決方案：使用全面的switch語句 143
6.6.3 注意默認情況 144
6.6.4 注意事項：依賴另一個項目的枚舉類型 146
6.7 我們不能只用測試解決所有此類問題嗎 146
6.8 小結 147
第7章 編寫難以被誤用的代碼 148
7.1 考慮不可變對象 149
7.1.1 可變類可能很容易被誤用 149
7.1.2 解決方案：只在構建時設值 151
7.1.3 解決方案：使用不可變性設計模式 152
7.2 考慮實現深度不可變性 157
7.2.1 深度可變性可能導致誤用 157
7.2.2 解決方案：防御性復制 159
7.2.3 解決方案：使用不可變數據結構 160
7.3 避免過于通用的類型 161
7.3.1 過于通用的類型可能被誤用 162
7.3.2 配對類型很容易被誤用 164
7.3.3 解決方案：使用專用類型 166
7.4 處理時間 167
7.4.1 用整數表示時間可能帶來問題 168
7.4.2 解決方案：使用合適的數據結構表示時間 170
7.5 擁有單一可信數據源 172
7.5.1 第二個可信數據源可能導致無效狀態 172
7.5.2 解決方案：使用原始數據作為單一可信數據源 173
7.6 擁有單一可信邏輯來源 175
7.6.1 多個可信邏輯來源可能導致程序缺陷 175
7.6.2 解決方案：使用單一可信來源 177
7.7 小結 179
第8章 實現代碼模塊化 180
8.1 考慮使用依賴注入 180
8.1.1 硬編程的依賴項可能造成問題 181
8.1.2 解決方案：使用依賴注入 182
8.1.3 在設計代碼時考慮依賴注入 184
8.2 傾向于依賴接口 185
8.2.1 依賴于具體實現將限制適應性 186
8.2.2 解決方案：盡可能依賴于接口 186
8.3 注意類的繼承 187
8.3.1 類繼承可能造成問題 188
8.3.2 解決方案：使用組合 192
8.3.3 真正的“is-a”關系該怎么辦 194
8.4 類應該只關心自身 196
8.4.1 過于關心其他類可能造成問題 196
8.4.2 解決方案：使類僅關心自身 197
8.5 將相關聯的數據封裝在一起 198
8.5.1 未封裝的數據可能難以處理 199
8.5.2 解決方案：將相關數據組合為對象或類 200
8.6 防止在返回類型中泄露實現細節 201
8.6.1 在返回類型中泄露實現細節可能造成問題 202
8.6.2 解決方案：返回對應于抽象層次的類型 203
8.7 防止在異常中泄露實現細節 204
8.7.1 在異常中泄露實現細節可能造成問題 204
8.7.2 解決方案：使異常適合抽象層次 206
8.8 小結 208
第9章 編寫可重用、可推廣的代碼 209
9.1 注意各種假設 209
9.1.1 代碼重用時假設將導致缺陷 210
9.1.2 解決方案：避免不必要的假設 210
9.1.3 解決方案：如果假設是必要的，則強制實施 211
9.2 注意全局狀態 213
9.2.1 全局狀態可能使重用變得不安全 215
9.2.2 解決方案：依賴注入共享狀態 217
9.3 恰當地使用默認返回值 219
9.3.1 低層次代碼中的默認返回值可能損害可重用性 220
9.3.2 解決方案：在較高層次代碼中使用默認值 221
9.4 保持函數參數的集中度 223
9.4.1 如果函數參數超出需要，可能難以重用 224
9.4.2 解決方案：讓函數只取得需要的參數 225
9.5 考慮使用泛型 226
9.5.1 依賴于特定類型將限制可推廣性 226
9.5.2 解決方案：使用泛型 227
9.6 小結 228
第三部分 單元測試
第 10章 單元測試原則 231
10.1 單元測試入門 232
10.2 是什么造就好的單元測試 233
10.2.1 準確檢測破壞 234
10.2.2 與實現細節無關 235
10.2.3 充分解釋失敗 236
10.2.4 易于理解的測試代碼 237
10.2.5 便捷運行 237
10.3 專注于公共API，但不要忽略重要的行為 238
10.4 測試替身 242
10.4.1 使用測試替身的理由 242
10.4.2 模擬對象 246
10.4.3 樁 248
10.4.4 模擬對象和樁可能有問題 250
10.4.5 偽造對象 253
10.4.6 關于模擬對象的不同學派 256
10.5 挑選測試思想 257
10.6 小結 258
第 11章 單元測試實踐 259
11.1 測試行為，而不僅僅是函數 259
11.1.1 每個函數一個測試用例往往是不夠的 260
11.1.2 解決方案：專注于測試每個行為 261
11.2 避免僅為了測試而使所有細節可見 263
11.2.1 測試私有函數往往是個壞主意 264
11.2.2 解決方案：首選通過公共API測試 265
11.2.3 解決方案：將代碼分解為較小的單元 266
11.3 一次測試一個行為 270
11.3.1 一次測試多個行為可能導致降低測試質量 270
11.3.2 解決方案：以單獨的測試用例測試每個行為 272
11.3.3 參數化測試 273
11.4 恰當地使用共享測試配置 274
11.4.1 共享狀態可能帶來問題 275
11.4.2 解決方案：避免共享狀態或者重置狀態 277
11.4.3 共享配置可能帶來問題 278
11.4.4 解決方案：在測試用例中定義重要配置 281
11.4.5 何時適用共享配置 283
11.5 使用合適的斷言匹配器 284
11.5.1 不合適的匹配器可能導致無法充分解釋失敗 284
11.5.2 解決方案：使用合適的匹配器 286
11.6 使用依賴注入來提高可測試性 287
11.6.1 硬編程的依賴項可能導致代碼無法測試 287
11.6.2 解決方案：使用依賴注入 288
11.7 關于測試的一些結論 289
11.8 小結 290
附錄A 巧克力糕餅食譜 291
附錄B 空值安全與可選類型 292
附錄C 額外的代碼示例 295
展開全部
好代碼壞代碼(軟件工程師卓越之道) 作者簡介
Tom Long，擁有劍橋大學信息工程專業碩士學位，目前擔任Google公司高級開發工程師，領導一支針對移動設備廣告的自動化及優化的技術團隊。目前重點關注軟件工程、Java開發、團隊管理、數據分析、移動廣告、技術創新等方向。
書友推薦
- >
企鵝口袋書系列·偉大的思想20:論自然選擇(英漢雙語)
- >
李白與唐代文化
- >
推拿
- >
史學評論
- >
苦雨齋序跋文-周作人自編集
- >
上帝之肋:男人的真實旅程
- >
詩經-先民的歌唱
- >
龍榆生：詞曲概論/大家小書
本類暢銷
