代碼整潔之道

代碼整潔之道

《代碼整潔之道》是2010年1月由人民郵電出版社出版的圖書,作者是馬丁。本書主要講述了代碼質量與其整潔度成正比的道理,並由此揭示代碼整潔之道。

基本介紹

  • 書名:代碼整潔之道
  • 作者:[美]Robert C.Martin
  • ISBN:9787115216878
  • 定價:59.00 元
  • 出版社人民郵電出版社
  • 出版時間:2010年01月
  • 開本:16開
內容簡介,編輯推薦,作者簡介,作品目錄,

內容簡介

《代碼整潔之道》講述了一系列行之有效的整潔代碼操作實踐。軟體質量,不但依賴於架構及項目管理,而且與代碼質量緊密相關。這一點,無論是敏捷開發流派還是傳統開發流派,都不得不承認。《代碼整潔之道》提出一種觀念:代碼質量與其整潔度成正比。乾淨的代碼,既在質量上較為可靠,也為後期維護、升級奠定了良好基礎。作為編程領域的佼佼者,這些實踐在《代碼整潔之道》中體現為一條條規則(或稱“啟示”),並輔以來自現實項目的正、反兩面的範例。只要遵循這些規則,就能編寫出乾淨的代碼,從而有效提升代碼質量。

編輯推薦

《代碼整潔之道》閱讀對象為一切有志於改善代碼質量的程式設計師及技術經理。書中介紹的規則均來自作者多年的實踐經驗,涵蓋從命名到重構的多個編程方面,雖為一“家”之言,然誠有可資借鑑的價值。圖書推薦
《代碼整潔之道》:細節之中自有天地,整潔成就卓越代碼
儘管糟糕的代碼也能運行,但如果代碼不整潔,會使整個開發團隊泥足深陷,寫得不好的代碼每年都要耗費難以計數的時間和資源。然而這種情況並非無法避免。
著名軟體專家RoberfC.Marlin在《代碼整潔之道》中為你呈現出了革命性的視野。Martin攜同ObjectMetltor公司的同事,從他們有關整潔代碼的最佳敏捷實踐中提煉出軟體技藝的價值觀,以饗讀者,讓你成為更優秀的程式設計師——只要你著手研讀《代碼整潔之道》。
閱讀《代碼整潔之道》需要你做些什麼呢?你將閱讀代碼——大量代碼。《代碼整潔之道》促使你思考代碼中何謂正確,何謂錯誤。更重要的是,《代碼整潔之道》將促使你重新評估自己的專業價值觀,以及對自己技藝的承諾。
從《代碼整潔之道》中可以學到:好代碼和糟糕的代碼之間的區別:如何編寫好代碼,如何將糟糕的代碼轉化為好代碼:如何創建好名稱、好函式、好對象和好類;如何格式化代碼以實現其可讀性的最大化:如何在不妨礙代碼邏輯的前提下充分實現錯誤處理;如何進行單元測試和測試驅動開發。

作者簡介

作者:(美國)馬丁(Robert C. Martin) 譯者:韓磊
Robert C. Martin,(Bob大叔)自1970年進入軟體行業,從1990年起成為國際軟體諮詢師。是軟體工程領域的大師級人物,是《敏捷軟體開發:原則、模式與實踐》、《敏捷軟體開發:原則、模式與實踐(C#版)》(郵電)、《極限編程實踐》(郵電)等國內引進的暢銷書的作者,其中第一本原著榮獲美國《軟體開發》第13屆震撼(Jolt)大獎,Martin的敏捷系列書是軟體工程界的權威書籍。本書是他的又一最新力作。
Martin在書中對代碼具有革命性的解讀
闡述了整潔代碼的最佳敏捷實踐的方法
書中介紹規則均來自Martin多年的經驗,擁有很高的借鑑價值
韓磊,網際網路產品與運營專家,技術書籍著譯者。曾在全球著名的IT中文社區CSDN及《程式設計師》雜誌任副總經理、總編輯等職。現居廣州。譯著有《夢斷代碼》和《C#編程風格》。與劉韌合著《網路媒體教程》,與戴飛合譯《BeginningC#Objects中文版:概念到代碼》。

作品目錄

第1章 整潔代碼 1
1.1 要有代碼 2 1.2 糟糕的代碼 2
1.3 混亂的代價 3
1.3.1 華麗新設計 4
1.3.2 態度 4
1.3.3 迷題 5
1.3.4 整潔代碼的藝術 5
1.3.5 什麼是整潔代碼 6
1.4 思想流派 10
1.5 我們是作者 11
1.6 童子軍軍規 12
1.7 前傳與原則 12 1.8 小結 12
1.9 文獻 13
第2章 有意義的命名 15
2.1 介紹 15
2.2 名副其實 16
2.3 避免誤導 17
2.4 做有意義的區分 18
2.5 使用讀得出來的名稱 19
2.6 使用可搜尋的名稱 20 2.7 避免使用編碼 21
2.7.1 匈牙利語標記法 21
2.7.2 成員前綴 21
2.7.3 接口和實現 22
2.8 避免思維映射 22
2.9  類名 23
2.10 方法名 23
2.11 別扮可愛 23
2.12 每個概念對應一個詞 24
2.13 別用雙關語 24
2.14 使用解決方案領域名稱 25
2.15 使用源自所涉問題領域的名稱 25
2.16 添加有意義的語境 25
2.17 不要添加沒用的語境 27
2.18 最後的話 27
第3章 函式 29
3.1 短小 32
3.2 只做一件事 33
3.3 每個函式一個抽象層級 34
3.4 switch語句 35
3.5 使用描述性的名稱 36
3.6 函式參數 37
3.6.1 一元函式的普遍形式 38
3.6.2 標識參數 38
3.6.3 二元函式 38
3.6.4 三元函式 39
3.6.5 參數對象 39
3.6.6 參數列表 40
3.6.7 動詞與關鍵字 40
3.7 無副作用 40
3.8 分隔指令與詢問 42
3.9 使用異常替代返回錯誤碼 42 3.9.1 抽離Try/Catch代碼塊 43
3.9.2 錯誤處理就是一件事 44
3.9.3 Error.java依賴磁鐵 44
3.10 別重複自己 44
3.11 結構化編程 45
3.12 如何寫出這樣的函式 45
3.13 小結 45
3.14 SetupTeardownIncluder程式 46 3.15 文獻 48
第4章 注釋 49
4.1 注釋不能美化糟糕的代碼 50
4.2 用代碼來闡述 51
4.3 好注釋 51
4.3.1 法律信息 51
4.3.2 提供信息的注釋 51
4.3.3 對意圖的解釋 52
4.3.4 闡釋 53 4.3.5 警示 53
4.3.6 TODO注釋 54
4.3.7 放大 54
4.3.8 公共API中的Javadoc 55
4.4 壞注釋 55
4.4.1 喃喃自語 55
4.4.2 多餘的注釋 56
4.4.3 誤導性注釋 58
4.4.4 循規式注釋 58
4.4.5 日誌式注釋 59 4.4.6 廢話注釋 59
4.4.7 可怕的廢話 61
4.4.8 能用函式或變數時就別用注釋 62
4.4.9 位置標記 62
4.4.10 括弧後面的注釋 62
4.4.11 歸屬與署名 63
4.4.12 注釋掉的代碼 63
4.4.13 HTML注釋 64
4.4.14 非本地信息 64
4.4.15 信息過多 65
4.4.16 不明顯的聯繫 65 4.4.17 函式頭 66
4.4.18 非公共代碼中的Javadoc 66
4.4.19 範例 66
4.5 文獻 69
第5章 格式 71
5.1 格式的目的 72
5.2 垂直格式 72
5.2.1 向報紙學習 73
5.2.2 概念間垂直方向上的區隔 73 5.2.3 垂直方向上的靠近 74
5.2.4 垂直距離 75
5.2.5 垂直順序 79
5.3 橫向格式 79
5.3.1 水平方向上的區隔與靠近 80
5.3.2 水平對齊 81
5.3.3 縮進 82
5.3.4 空範圍 84
5.4 團隊規則 84
5.5 鮑勃大叔的格式規則 85
第6章 對象和數據結構 87 6.1 數據抽象 87
6.2 數據、對象的反對稱性 89
6.3 得墨忒耳律 91
6.3.1 火車失事 91
6.3.2 混雜 92
6.3.3 隱藏結構 92
6.4 數據傳送對象 93
6.5 小結 94 6.6 文獻 94
第7章 錯誤處理 95
7.1 使用異常而非返回碼 96
7.2 先寫Try-Catch-Finally語句 97
7.3 使用不可控異常 98
7.4 給出異常發生的環境說明 99
7.5 依調用者需要定義異常類 99
7.6 定義常規流程 100
7.7 別返回null值 101
7.8 別傳遞null值 102
7.9 小結 103 7.10 文獻 104
第8章 邊界 105
8.1 使用第三方代碼 106
8.2 瀏覽和學習邊界 107
8.3 學習log4j 108
8.4 學習性測試的好處不只是免費 110
8.5 使用尚不存在的代碼 110
8.6 整潔的邊界 111
8.7 文獻 112
第9章 單元測試 113
9.1 TDD三定律 114 9.2 保持測試整潔 115
9.3 整潔的測試 116
9.3.1 面向特定領域的測試語言 118
9.3.2 雙重標準 119
9.4 每個測試一個斷言 121
9.5 F.I.R.S.T. 122
9.6 小結 123
9.7 文獻 124
第10章 類 125
10.1 類的組織 126
10.2 類應該短小 126
10.2.1 單一權責原則 128
10.2.2 內聚 129
10.2.3 保持內聚性就會得到許多短小的類 130
10.3 為了修改而組織 136
10.4 文獻 139
第11章 系統 141
11.1 如何建造一個城市 142
11.2 將系統的構造與使用分開 142
11.2.1 分解main 143
11.2.2 工廠 143
11.2.3 依賴注入 144
11.3 擴容 145
11.4 Java代理 148
11.5 純Java AOP框架 150
11.6 AspectJ的方面 152
11.7 測試驅動系統架構 153 11.8 最佳化決策 154
11.9 明智使用添加了可論證價值的標準 154
11.10 系統需要領域特定語言 154
11.11 小結 155
11.12 文獻 155
第12章 迭進 157
12.1 通過迭進設計達到整潔目的 157
12.2 簡單設計規則1:運行所有測試 158 12.3 簡單設計規則2~4:重構 158
12.4 不可重複 159
12.5 表達力 161
12.6 儘可能少的類和方法 162
12.7 小結 162
12.8 文獻 162
第13章 並發編程 163
13.1 為什麼要並發 164 13.2 挑戰 165
13.3 並發防禦原則 166
13.3.1 單一權責原則 166
13.3.2 推論:限制數據作用域 166
13.3.3 推論:使用數據複本 167
13.3.4 推論:執行緒應儘可能地獨立 167
13.4 了解Java庫 167
13.5 了解執行模型 168
13.5.1 生產者-消費者模型 169 13.5.2 讀者-作者模型 169
13.5.3 宴席哲學家 169
13.6 警惕同步方法之間的依賴 169
13.7 保持同步區域微小 170
13.8 很難編寫正確的關閉代碼 170
13.9 測試執行緒代碼 171
13.9.1 將偽失敗看作可能的執行緒問題 171
13.9.2 先使非執行緒代碼可工作 171
13.9.3 編寫可插拔的執行緒代碼 172
13.9.4 編寫可調整的執行緒代碼 172
13.9.5 運行多於處理器數量的執行緒 172 13.9.6 在不同平台上運行 172
13.9.7 裝置試錯代碼 173
13.9.8 硬編碼 173
13.9.9 自動化 174
13.10 小結 175
13.11 文獻 175
第14章 逐步改進 176
14.1 Args的實現 177 14.2 Args:草稿 183
14.2.1 所以我暫停了 195
14.2.2 漸進 195
14.3 字元串參數 197
14.4 小結 234
第15章 JUnit內幕 235
15.1 JUnit框架 236
15.2 小結 249 第16章 重構SerialDate 251
16.1 首先,讓它能工作 252
16.2 讓它做對 254
16.3 小結 266
16.4 文獻 267
第17章 味道與啟發 269
17.1 注釋 270
17.2 環境 271
17.3 函式 271
17.4 一般性問題 272
17.5 Java 288 17.6 名稱 291
17.7 測試 294
17.8 小結 295
17.9 文獻 296
附錄A 並發編程II 297
A.1 客戶端/伺服器的例子 297
A.1.1 伺服器 297
A.1.2 添加執行緒代碼 298 A.1.3 觀察伺服器端 299
A.1.4 小結 301
A.2 執行的可能路徑 301
A.2.1 路徑數量 302
A.2.2 深入挖掘 303
A.2.3 小結 305
A.3 了解類庫 305
A.3.1 Executor框架 305
A.3.2 非鎖定的解決方案 306
A.3.3 非執行緒安全類 307
A.4 方法之間的依賴可能破壞並發代碼 308 A.4.1 容忍錯誤 309
A.4.2 基於客戶代碼的鎖定 309
A.4.3 基於服務端的鎖定 311
A.5 提升吞吐量 312
A.5.1 單執行緒條件下的吞吐量 313
A.5.2 多執行緒條件下的吞吐量 313
A.6 死鎖 314
A.6.1 互斥 315
A.6.2 上鎖及等待 315
A.6.3 無搶先機制 315
A.6.4 循環等待 315
A.6.5 不互斥 316
A.6.6 不上鎖及等待 316
A.6.7 滿足搶先機制 317
A.6.8 不做循環等待 317
A.7 測試多執行緒代碼 317
A.8 測試執行緒代碼的工具支持 320
A.9 小結 320
A.10 教程:完整代碼範例 321
A.10.1 客戶端/伺服器非執行緒代碼 321
A.10.2 使用執行緒的客戶端/伺服器代碼 324
附錄B org.jfree.date.SerialDate 327
結束語 389

相關詞條

熱門詞條

聯絡我們