大規(guī)模重構(gòu)

目錄
前言 1
第一部分 概述
第1 章 重構(gòu) 11
1.1 什么是重構(gòu)？ .12
1.2 什么是大規(guī)模重構(gòu)？ 14
1.3 你為什么要關心重構(gòu)？ .16
1.4 重構(gòu)的好處 17
1.4.1 開發(fā)者的生產(chǎn)力 17
1.4.2 識別bug 19
1.5 重構(gòu)的風險 19
1.5.1 嚴重的退步 20
1.5.2 挖掘出休眠的bug 20
1.5.3 范圍蔓延 .20
1.5.4 不必要的復雜度 21
1.6 何時重構(gòu)21
1.6.1 小范圍 22
1.6.2 代碼的復雜度明顯地阻礙了開發(fā) 22
1.6.3 產(chǎn)品需求的轉(zhuǎn)變 22
1.6.4 性能 23
1.6.5 使用新技術(shù) 23
1.7 何時不要重構(gòu) .24
1.7.1 為了好玩或出于無聊的原因 .24
1.7.2 因為你恰好路過 25
1.7.3 使代碼更具可擴展性.26
1.7.4 當你沒時間時 27
1.8 我們的第一個重構(gòu)示例 .27
1.8.1 簡化條件語句 29
1.8.2 提取魔法數(shù)字 31
1.8.3 提取自包含邏輯 32
第2 章 代碼是如何退化的 .37
2.1 為什么理解代碼退化很重要 38
2.2 需求的轉(zhuǎn)變 39
2.2.1 可擴展性 .39
2.2.2 可訪問性 .40
2.2.3 設備兼容性 40
2.2.4 環(huán)境改變 .41
2.2.5 外部依賴 .42
2.2.6 未使用的代碼 42
2.2.7 產(chǎn)品需求變化 43
2.3 技術(shù)債 46
2.3.1 技術(shù)決策 .47
2.3.2 缺乏持續(xù)的整理 50
2.3.3 移動得太快 51
2.4 應用我們的知識 53
第二部分 規(guī)劃
第3 章 測量我們的起點狀態(tài) .57
3.1 為什么測量重構(gòu)的影響很難？ 58
3.2 測量代碼復雜性 59
3.2.1 哈爾斯特德（Halstead）度量 59
3.2.2 循環(huán)復雜度 62
3.2.3 NPath 復雜度 65
3.2.4 代碼行數(shù) .68
3.3 測試覆蓋率指標 69
3.4 文檔 .73
3.4.1 正式文檔 .73
3.4.2 非正式文檔 75
3.5 版本控制76
3.5.1 提交信息 .77
3.5.2 聚合提交 .77
3.6 聲譽 .79
3.7 構(gòu)建完整的畫面 82
第4 章 起草計劃 83
4.1 定義你的最終狀態(tài) 84
4.1.1 旅途中 84
4.1.2 工作中 85
4.2 映射最短的距離 86
4.2.1 旅途中 86
4.2.2 工作中 87
4.3 確定戰(zhàn)略中間里程碑 89
4.3.1 旅途中 89
4.3.2 工作中 90
4.4 選擇推出策略 .94
4.4.1 明模式（Light）/ 暗模式（Dark） 95
4.4.2 Smart DNA 案例的推出 99
4.5 清理工件.100
4.6 在你的計劃中引用指標 102
4.6.1 將目標指標延伸至中間里程碑 102
4.6.2 不同的里程碑指標 103
4.7 估算 104
4.8 與其他團隊分享你的計劃 .105
4.8.1 透明度 106
4.8.2 觀點 .106
4.9 精細化計劃 108
第5 章 獲取支持 111
5.1 為什么你的經(jīng)理沒有上船 . 112
5.1.1 經(jīng)理不編碼 . 112
5.1.2 經(jīng)理們的評估方式不同 . 113
5.1.3 管理者看到的風險 113
5.1.4 管理者需要協(xié)調(diào) 114
5.2 制定令人信服的策略 115
5.2.1 使用對話策略 . 117
5.2.2 構(gòu)建對齊的“三明治” . 118
5.2.3 依賴證據(jù) 121
5.2.4 采取強硬手段 .122
5.3 認同塑造重構(gòu) 124
第6 章 構(gòu)建正確的團隊 125
6.1 識別不同類型的專家 126
6.2 匹配制度.128
6.2.1 多行業(yè)專家 .129
6.2.2 重新審視活躍貢獻者130
6.2.3 我們專家名單中的偏見 .130
6.3 重構(gòu)團隊的類型 .132
6.3.1 所有者 132
6.3.2 建議的方法 .134
6.3.3 清潔人員 134
6.4 招募動員.136
6.4.1 指標 .137
6.4.2 慷慨 .138
6.4.3 機會 .139
6.4.4 交換籌碼 139
6.4.5 重復 .140
6.5 一些結(jié)果.141
6.5.1 現(xiàn)實的場景 .141
6.5.2 最壞的情況 .141
6.6 培養(yǎng)強大的團隊 .142
第三部分 執(zhí)行
第7 章 溝通 . 147
7.1 在你的團隊內(nèi) 148
7.1.1 站會 .150
7.1.2 每周同步 151
7.1.3 回顧會議 153
7.2 在你的團隊外 154
7.2.1 開始項目時 .154
7.2.2 在項目執(zhí)行期間 157
7.3 始終迭代.162
第8 章 執(zhí)行策略 . 163
8.1 團隊建設.163
8.1.1 結(jié)對編程 164
8.1.2 保持每個人的動力 166
8.2 保持記錄.168
8.2.1 中期指標度量 .168
8.2.2 發(fā)現(xiàn)的漏洞 .169
8.2.3 清理項 170
8.2.4 記錄超出范圍的內(nèi)容170
8.3 高效編程.171
8.3.1 原型 .171
8.3.2 保持事物小巧 .172
8.3.3 測試，測試，測試 173
8.3.4 提出“愚蠢”的問題173
8.4 結(jié)論 174
第9 章 讓重構(gòu)保持有效 175
9.1 推動支持.176
9.2 傳授 177
9.2.1 主動傳授 177
9.2.2 被動傳授 180
9.3 強化 181
9.3.1 漸進式代碼檢查 181
9.3.2 代碼分析工具 .182
9.3.3 門檻與護欄 .182
9.4 將改進融入企業(yè)文化 184
第四部分 用例
第10 章 案例研究：冗余數(shù)據(jù)庫模式（Schemas） 189
10.1 Slack 101 .190
10.2 Slack 架構(gòu)101 192
10.3 可擴展性問題 195
10.3.1 啟動Slack 客戶端 .196
10.3.2 文件可見性196
10.3.3 提及 197
10.4 合并表格 198
10.4.1 收集分散的查詢 .199
10.4.2 制定遷移策略 202
10.4.3 量化我們的進展 .205
10.4.4 試圖保持團隊的動力 206
10.4.5 溝通我們的進展 .207
10.5 整理 209
10.6 經(jīng)驗教訓 211
10.7 了解代碼的歷史 212
10.7.1 確保充分的測試覆蓋率 213
10.7.2 保持團隊的動力 .213
10.7.3 專注于戰(zhàn)略里程碑 214
10.7.4 識別并依賴有意義的指標 .214
10.8 收獲 215
第11 章 案例研究：遷移到新數(shù)據(jù)庫 217
11.1 工作區(qū)分片數(shù)據(jù) 218
11.2 將channels_members 遷移到Vitess 219
11.2.1 分片方案 220
11.2.2 開發(fā)新模式 221
11.3 解決JOIN 操作中的糾纏問題 224
11.4 一個困難的推出 228
11.4.1 回填模式 229
11.4.2 暗模式 .230
11.4.3 明模式 .235
11.4.4 日落模式 237
11.5 整理 237
11.6 經(jīng)驗教訓 239
11.6.1 設定現(xiàn)實的估算 .240
11.6.2 尋找你需要的團隊成員 240
11.6.3 仔細規(guī)劃范圍 241
11.6.4 選擇一個項目溝通的單一地點 241
11.6.5 設計一個周到的推出計劃 .242
11.7 收獲 243