本書的主要內容有：理解代碼是如何退化的，以及為什么一些退化是不可避免的。在重構之前，量化和評定你的代碼狀態。起草一個具有戰略里程碑且精心設計的執行計劃。贏得領導層的支持。建立和協調一個最z適合項目的團隊。在團隊內外進行高效溝通。正確使用重構的最z佳實踐。
一句話推薦
重獲代碼的控制權
編輯推薦
對大型、復雜的代碼庫進行重大修改是一項艱巨的任務，除非你有合適的團隊、工具和思維方式，否則幾乎不可能成功。如果你的應用程序需要進行重大改造，但你又不確定以何種可持續的方式進行，那么這本書就是為你準備的。
軟件工程師Maude Lemaire將帶領你從頭到尾經歷整個重構過程。你將了解她在Slack的關鍵發展時期是如何提高性能和重構的，并從這些經驗中得到啟發，書中利用兩個案例研究來說明這些技術是如何在實際工作中產生影響的。本書將有助于你獲得一種新的能力，使你更高效地進行重構。
專家推薦
在一個巨大的、不斷變化的代碼庫中，保持生產力似乎是一個西西弗斯式的任務。本書將這一過程分解成一個個你可以立即應用的步驟。
Cal Henderson
Slack首席技術官
我喜歡這本書中的案例研究。我希望我能把這本書送給過去的自己，幫助以前的我更好的規劃大型遷移。書中有很多我需要去努力學習的經驗。
Julia Evans
《Wizard Zines》的作者
前言雖然有很多關于重構的書籍，但大多數都是處理如何一行行改進代碼的細節問題。我認為重構最困難的部分通常不是找到改進手頭代碼的精確方法，而是需要在其周圍進行的所有其他事情。事實上，我甚至可能會說，在任何大型軟件項目中，小事情很少有意義，協調復雜的變化才是最大的挑戰。這本書是我試圖幫助你解決那些困難問題的嘗試。它是多年經驗的結晶，我曾經進行過各種規模的重構項目。在Slack 任職期間，我領導的許多項目使公司得以大規模擴展，我們的產品已經能夠支持擁有25000 名員工的客戶，甚至是擁有高達500000 名員工的客戶。我們開發的有效重構策略需要能夠適應組織的爆炸性增長，與此同時，我們的工程團隊在同一時期幾乎增長了6 倍。成功地規劃和執行一個既影響到你的大部分代碼庫又涉及越來越多工程師的項目絕非易事。我希望這本書能給你提供你所需要的工具和資源來做到這一點。誰應該閱讀這本書如果你在與幾十個甚至更多的工程師一起處理大型、復雜的代碼庫，那么本書就適合你！如果你是一名初級工程師，想通過對公司產生廣泛、有意義的影響并開始構建更高級別的技能，大規模重構項目可以是實現這一目標的好方法。這些項目的影響范圍廣泛，超越了你所在的團隊（它們也不是高級工程師馬上就能搶走的那種光鮮項目）。這是一個非常好的機會，讓你獲得新的專業技能（并加強你已有的技能）。本書將教會你如何從頭到尾順利地完成這類項目。本書也是高度技術性的高級工程師的有價值資源，這類工程師可以自己編寫沒有任何問題的代碼，但卻感到其他人不理解他們工作的價值而感到沮喪。如果你感到孤立無援，正在尋找方法提升你周圍其他人的水平，本書可以教給你所需的策略，幫助他人從你的角度看到重要的技術問題。對于希望幫助團隊通過大規模重構的技術經理，本書可以幫助你了解如何在每個步驟中更好地支持你的團隊。這里沒有大量的技術內容，因此，如果你會以管理的角色參與到大規模重構（工程經理、產品經理、項目經理），都可以從這些思想中受益。為什么寫這本書當我開始進行第一個大規模的重構時，我理解代碼需要改變的原因和方式，但最困惑我的是如何安全、逐步地引入這些變化，而不會傷及其他人的利益。我渴望產生跨職能影響，并沒有停下來思考重構可能對其他人的工作產生的影響，以及我如何激勵他們幫助我完成它。我只是一直在沖刺（可以在第10 章中閱讀有關此重構的內容）。隨后的幾年中，我重構了許多行代碼，并成為一些重構不當的受害者。我從這些經歷中學到的教訓似乎很重要，因此我開始在許多會議上演講。我的演講引起了數百名工程師的共鳴，他們都像我一樣，在自己的公司中經歷了有效重構大面積代碼的問題。顯然，我們的軟件教育存在某種差距，特別是在專業軟件編寫的核心方面。在許多方面，這本書試圖教授計算機科學課程中未涵蓋的重要內容，僅僅因為在課堂上教授這些內容太困難了。也許這些內容在書中也無法教授，但為什么不試一試呢？本書的組織結構本書分為四部分，按照計劃和執行大規模重構所需的工作的大致時間順序進行組織，如下所述。 第一部分概述。介紹重構背后的重要概念。─ 第 1 章重構。討論了重構的基礎知識以及對比大規模重構與較小規模的重構有何不同。─ 第 2 章代碼是如何退化的。描述代碼可能退化的多種方式以及如何將其納入有效的重構中。 第二部分規劃。涵蓋了計劃成功重構所需的所有知識。─ 第 3 章測量我們的起點狀態。提供一個概述，介紹在進行任何改進之前，你可以使用哪些指標來衡量你的重構旨在解決的問題。─ 第 4 章起草計劃。解釋了一個全面的執行計劃的重要組成部分以及如何制定一個執行計劃。─ 第 5 章獲取支持。討論了不同的方法來獲取工程領導支持你的重構。─ 第 6 章構建正確的團隊。描述了如何確定哪些工程師最適合參與重構以及如何為他們提供建議。 第三部分執行。關注在重構過程中如何確保重構順利進行。─ 第 7 章溝通。探討如何最好地促進團隊內部和與任何外部利益相關者之間的良好溝通。─ 第 8 章執行策略。看看如何在重構過程中保持動力的幾種方法。─ 第 9 章讓重構保持有效。提供了幾個建議，以確保你進行的重構所引入的更改得以保留。 第四部分用例，包含兩個案例研究，都是從我在Slack 工作期間參與的項目中提取的。這些重構影響了我們核心應用程序的大部分，真正地達到了規模。我希望這些能夠幫助闡述書中第一部分到第三部分討論的概念。這個順序并不是一成不變的，僅僅因為我們進入了新的階段，并不意味著我們不應該在必要時重新審視我們之前的假設。例如，你可能會以一個強烈的團隊意識開始你的重構工作，但是在起草執行計劃的過程中，你可能會發現你需要比最初預期的更多的工程師。這沒關系，這種情況經常發生！排版約定本書使用以下排版約定。斜體（Italic）表示新術語、URL、電子郵件地址、文件名和文件擴展名。等寬字體（Constant width）表示程序片段，以及正文中出現的程序元素，例如變量、函數名、數據類型、語句和關鍵字。使用代碼示例補充材料（代碼示例、練習等）可在以下鏈接下載：https://github.com/qcmaude/refactoring-at-scale。本書是要幫你完成工作的。一般來說，如果本書提供了示例代碼，你可以把它用在你的程序或文檔中。除非你使用了很大一部分代碼，否則無需聯系我們獲得許可。比如，用本書的幾個代碼片段寫一個程序就無需獲得許可。銷售或分發OReilly圖書的示例需要獲得許可，引用本書中的示例代碼回答問題無需獲得許可，將書中大量的代碼放到你的產品文檔中需要獲得許可。我們很希望但并不強制要求你在引用本書內容時加上引用說明。引用說明一般包括書名、作者、出版社和ISBN，例如：Refactoring at Scale by Maude Lemaire(OReilly). Copyright 2021 Maude Lemaire, 978-1-492-07553-0 。如果你覺得自己對示例代碼的使用超出了上述許可范圍，請通過permissions@oreilly.com 與我們聯系。OReilly 在線學習平臺（OReilly Online Learning）近40 年來，OReilly Media 致力于提供技術和商業培訓、知識和卓越見解，來幫助眾多公司取得成功。公司獨有的專家和改革創新者網絡通過OReilly 書籍、文章以及在線學習平臺，分享他們的專業知識和實踐經驗。OReilly 在線學習平臺按照您的需要提供實時培訓課程、深入學習渠道、交互式編程環境以及來自OReilly 和其他200 多家出版商的大量書籍與視頻資料。更多信息，請訪問網站：https://www.oreilly.com/。聯系我們任何有關本書的意見或疑問，請按照以下地址聯系出版社。美國：OReilly Media, Inc.1005 Gravenstein Highway NorthSebastopol, CA 95472中國：北京市西城區西直門南大街2 號成銘大廈C 座807 室（100035）奧萊利技術咨詢（北京）有限公司勘誤、示例和其他信息，請訪問https://oreil.ly/refactoring-at-scale。對于本書的評論和技術性問題，請發送電子郵件到errata@oreilly.com.cn。要了解更多OReilly 圖書和培訓的信息，請訪問https://oreilly.com。我們的Facebook：https://linkedin.com/company/oreilly-media。我們的Twitter：https://twitter.com/oreillymedia。我們的YouTube：https://www.youtube.com/oreillymedia。致謝寫一本書并不是一件容易的事情，這本書也不例外，沒有很多人的貢獻是不可能完成的。首先，我要感謝OReilly 的編輯Jeff Bleiel。Jeff 把一個沒有經驗的作者（我）變成了一位出版的作者。他的反饋總是非常準確，幫助我更有條理地組織我的思路，并鼓勵我在我寫得太啰嗦時進行刪減（這種情況經常發生）。我簡直無法想象有比他更好的編輯。其次，我要感謝少數幾個朋友和同事，他們閱讀了幾章的早期版本：Morgan Jones、Ryan Greenberg 和Jason Liszka。他們的反饋讓我確信我的想法是正確的，并且對廣泛的讀者有價值。對于鼓勵和引發思考的談話，感謝Joann、Kevin、Chase 和Ben。我要感謝Maggie Zhou，在第二個案例研究章節（第11 章）中與我共同撰寫。她是我曾經一起工作過的最有思想、最聰明、最有活力的同事之一，我很高興讓世界讀到我們一起的冒險！非常感謝我的技術審稿人David Cottrell 和Henry Robinson。David 是我大學時的好朋友，在Google 工作多年，領導了許多大規模的重構。他后來創立了自己的公司。Henry 是我在Slack 的同事，做出了無數的開源貢獻，并親眼見證了硅谷公司的爆炸式增長。他們都是非常有責任心的工程師，這本書從他們的指導和智慧中受益匪淺。我感激他們花費許多時間來驗證書中的內容。最終手稿中的任何不準確之處都是我的錯誤。感謝所有曾經和我一起重構過東西的人。你們太多了，無法一一列舉，但你們知道自己是誰。你們都對本書中的思想產生了影響。感謝我的家人（Simon、Marie-Josée、Fran?ois-Rémi、Sophie、Sylvia、Gerry、Stephanie 和Celia）在場外為我加油。最后，感謝我的丈夫Avery。謝謝你的耐心，謝謝你給我寫作的時間、空間和鼓勵。謝謝你讓我占用了無數個下午來討論一個、兩個（或三個、四個）想法。謝謝你相信我。這本書和你一樣屬于我。我愛你。
Maude Lemaire是Slack的一名軟件工程師，她的工作是提升產品性能，以支持一些世界上最z大的組織。她的大部分時間都在進行人員管理、網絡調用、重構復雜的代碼塊、整合冗余的數據庫，以及為其他開發者構建工具。
目錄
前言 1
第一部分 概述
第1 章 重構 11
1.1 什么是重構？ .12
1.2 什么是大規模重構？ 14
1.3 你為什么要關心重構？ .16
1.4 重構的好處 17
1.4.1 開發者的生產力 17
1.4.2 識別bug 19
1.5 重構的風險 19
1.5.1 嚴重的退步 20
1.5.2 挖掘出休眠的bug 20
1.5.3 范圍蔓延 .20
1.5.4 不必要的復雜度 21
1.6 何時重構21
1.6.1 小范圍 22
1.6.2 代碼的復雜度明顯地阻礙了開發 22
1.6.3 產品需求的轉變 22
1.6.4 性能 23
1.6.5 使用新技術 23
1.7 何時不要重構 .24
1.7.1 為了好玩或出于無聊的原因 .24
1.7.2 因為你恰好路過 25
1.7.3 使代碼更具可擴展性.26
1.7.4 當你沒時間時 27
1.8 我們的第一個重構示例 .27
1.8.1 簡化條件語句 29
1.8.2 提取魔法數字 31
1.8.3 提取自包含邏輯 32
第2 章 代碼是如何退化的 .37
2.1 為什么理解代碼退化很重要 38
2.2 需求的轉變 39
2.2.1 可擴展性 .39
2.2.2 可訪問性 .40
2.2.3 設備兼容性 40
2.2.4 環境改變 .41
2.2.5 外部依賴 .42
2.2.6 未使用的代碼 42
2.2.7 產品需求變化 43
2.3 技術債 46
2.3.1 技術決策 .47
2.3.2 缺乏持續的整理 50
2.3.3 移動得太快 51
2.4 應用我們的知識 53
第二部分 規劃
第3 章 測量我們的起點狀態 .57
3.1 為什么測量重構的影響很難？ 58
3.2 測量代碼復雜性 59
3.2.1 哈爾斯特德（Halstead）度量 59
3.2.2 循環復雜度 62
3.2.3 NPath 復雜度 65
3.2.4 代碼行數 .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 構建完整的畫面 82
第4 章 起草計劃 83
4.1 定義你的最終狀態 84
4.1.1 旅途中 84
4.1.2 工作中 85
4.2 映射最短的距離 86
4.2.1 旅途中 86
4.2.2 工作中 87
4.3 確定戰略中間里程碑 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 為什么你的經理沒有上船 . 112
5.1.1 經理不編碼 . 112
5.1.2 經理們的評估方式不同 . 113
5.1.3 管理者看到的風險 113
5.1.4 管理者需要協調 114
5.2 制定令人信服的策略 115
5.2.1 使用對話策略 . 117
5.2.2 構建對齊的三明治 . 118
5.2.3 依賴證據 121
5.2.4 采取強硬手段 .122
5.3 認同塑造重構 124
第6 章 構建正確的團隊 125
6.1 識別不同類型的專家 126
6.2 匹配制度.128
6.2.1 多行業專家 .129
6.2.2 重新審視活躍貢獻者130
6.2.3 我們專家名單中的偏見 .130
6.3 重構團隊的類型 .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 一些結果.141
6.5.1 現實的場景 .141
6.5.2 最壞的情況 .141
6.6 培養強大的團隊 .142
第三部分 執行
第7 章 溝通 . 147
7.1 在你的團隊內 148
7.1.1 站會 .150
7.1.2 每周同步 151
7.1.3 回顧會議 153
7.2 在你的團隊外 154
7.2.1 開始項目時 .154
7.2.2 在項目執行期間 157
7.3 始終迭代.162
第8 章 執行策略 . 163
8.1 團隊建設.163
8.1.1 結對編程 164
8.1.2 保持每個人的動力 166
8.2 保持記錄.168
8.2.1 中期指標度量 .168
8.2.2 發現的漏洞 .169
8.2.3 清理項 170
8.2.4 記錄超出范圍的內容170
8.3 高效編程.171
8.3.1 原型 .171
8.3.2 保持事物小巧 .172
8.3.3 測試，測試，測試 173
8.3.4 提出愚蠢的問題173
8.4 結論 174
第9 章 讓重構保持有效 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 將改進融入企業文化 184
第四部分 用例
第10 章 案例研究：冗余數據庫模式（Schemas） 189
10.1 Slack 101 .190
10.2 Slack 架構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 經驗教訓 211
10.7 了解代碼的歷史 212
10.7.1 確保充分的測試覆蓋率 213
10.7.2 保持團隊的動力 .213
10.7.3 專注于戰略里程碑 214
10.7.4 識別并依賴有意義的指標 .214
10.8 收獲 215
第11 章 案例研究：遷移到新數據庫 217
11.1 工作區分片數據 218
11.2 將channels_members 遷移到Vitess 219
11.2.1 分片方案 220
11.2.2 開發新模式 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 經驗教訓 239
11.6.1 設定現實的估算 .240
11.6.2 尋找你需要的團隊成員 240
11.6.3 仔細規劃范圍 241
11.6.4 選擇一個項目溝通的單一地點 241
11.6.5 設計一個周到的推出計劃 .242
11.7 收獲 243
新書資訊