前言雖然有很多關(guān)于重構(gòu)的書籍，但大多數(shù)都是處理如何一行行改進代碼的細節(jié)問題。我認為重構(gòu)最困難的部分通常不是找到改進手頭代碼的精確方法，而是需要在其周圍進行的所有其他事情。事實上，我甚至可能會說，在任何大型軟件項目中，小事情很少有意義，協(xié)調(diào)復(fù)雜的變化才是最大的挑戰(zhàn)。這本書是我試圖幫助你解決那些困難問題的嘗試。它是多年經(jīng)驗的結(jié)晶，我曾經(jīng)進行過各種規(guī)模的重構(gòu)項目。在Slack 任職期間，我領(lǐng)導(dǎo)的許多項目使公司得以大規(guī)模擴展，我們的產(chǎn)品已經(jīng)能夠支持擁有25000 名員工的客戶，甚至是擁有高達500000 名員工的客戶。我們開發(fā)的有效重構(gòu)策略需要能夠適應(yīng)組織的爆炸性增長，與此同時，我們的工程團隊在同一時期幾乎增長了6 倍。成功地規(guī)劃和執(zhí)行一個既影響到你的大部分代碼庫又涉及越來越多工程師的項目絕非易事。我希望這本書能給你提供你所需要的工具和資源來做到這一點。誰應(yīng)該閱讀這本書如果你在與幾十個甚至更多的工程師一起處理大型、復(fù)雜的代碼庫，那么本書就適合你！如果你是一名初級工程師，想通過對公司產(chǎn)生廣泛、有意義的影響并開始構(gòu)建更高級別的技能，大規(guī)模重構(gòu)項目可以是實現(xiàn)這一目標的好方法。這些項目的影響范圍廣泛，超越了你所在的團隊（它們也不是高級工程師馬上就能搶走的那種光鮮項目）。這是一個非常好的機會，讓你獲得新的專業(yè)技能（并加強你已有的技能）。本書將教會你如何從頭到尾順利地完成這類項目。本書也是高度技術(shù)性的高級工程師的有價值資源，這類工程師可以自己編寫沒有任何問題的代碼，但卻感到其他人不理解他們工作的價值而感到沮喪。如果你感到孤立無援，正在尋找方法提升你周圍其他人的水平，本書可以教給你所需的策略，幫助他人從你的角度看到重要的技術(shù)問題。對于希望幫助團隊通過大規(guī)模重構(gòu)的技術(shù)經(jīng)理，本書可以幫助你了解如何在每個步驟中更好地支持你的團隊。這里沒有大量的技術(shù)內(nèi)容，因此，如果你會以管理的角色參與到大規(guī)模重構(gòu)（工程經(jīng)理、產(chǎn)品經(jīng)理、項目經(jīng)理），都可以從這些思想中受益。為什么寫這本書當我開始進行第一個大規(guī)模的重構(gòu)時，我理解代碼需要改變的原因和方式，但最困惑我的是如何安全、逐步地引入這些變化，而不會傷及其他人的利益。我渴望產(chǎn)生跨職能影響，并沒有停下來思考重構(gòu)可能對其他人的工作產(chǎn)生的影響，以及我如何激勵他們幫助我完成它。我只是一直在沖刺（可以在第10 章中閱讀有關(guān)此重構(gòu)的內(nèi)容）。隨后的幾年中，我重構(gòu)了許多行代碼，并成為一些重構(gòu)不當?shù)氖芎φ摺Ｎ覐倪@些經(jīng)歷中學(xué)到的教訓(xùn)似乎很重要，因此我開始在許多會議上演講。我的演講引起了數(shù)百名工程師的共鳴，他們都像我一樣，在自己的公司中經(jīng)歷了有效重構(gòu)大面積代碼的問題。顯然，我們的軟件教育存在某種差距，特別是在專業(yè)軟件編寫的核心方面。在許多方面，這本書試圖教授計算機科學(xué)課程中未涵蓋的重要內(nèi)容，僅僅因為在課堂上教授這些內(nèi)容太困難了。也許這些內(nèi)容在書中也無法教授，但為什么不試一試呢？本書的組織結(jié)構(gòu)本書分為四部分，按照計劃和執(zhí)行大規(guī)模重構(gòu)所需的工作的大致時間順序進行組織，如下所述。 第一部分概述。介紹重構(gòu)背后的重要概念。─ 第 1 章重構(gòu)。討論了重構(gòu)的基礎(chǔ)知識以及對比大規(guī)模重構(gòu)與較小規(guī)模的重構(gòu)有何不同。─ 第 2 章代碼是如何退化的。描述代碼可能退化的多種方式以及如何將其納入有效的重構(gòu)中。 第二部分規(guī)劃。涵蓋了計劃成功重構(gòu)所需的所有知識。─ 第 3 章測量我們的起點狀態(tài)。提供一個概述，介紹在進行任何改進之前，你可以使用哪些指標來衡量你的重構(gòu)旨在解決的問題。─ 第 4 章起草計劃。解釋了一個全面的執(zhí)行計劃的重要組成部分以及如何制定一個執(zhí)行計劃。─ 第 5 章獲取支持。討論了不同的方法來獲取工程領(lǐng)導(dǎo)支持你的重構(gòu)。─ 第 6 章構(gòu)建正確的團隊。描述了如何確定哪些工程師最適合參與重構(gòu)以及如何為他們提供建議。 第三部分執(zhí)行。關(guān)注在重構(gòu)過程中如何確保重構(gòu)順利進行。─ 第 7 章溝通。探討如何最好地促進團隊內(nèi)部和與任何外部利益相關(guān)者之間的良好溝通。─ 第 8 章執(zhí)行策略。看看如何在重構(gòu)過程中保持動力的幾種方法。─ 第 9 章讓重構(gòu)保持有效。提供了幾個建議，以確保你進行的重構(gòu)所引入的更改得以保留。 第四部分用例，包含兩個案例研究，都是從我在Slack 工作期間參與的項目中提取的。這些重構(gòu)影響了我們核心應(yīng)用程序的大部分，真正地達到了規(guī)模。我希望這些能夠幫助闡述書中第一部分到第三部分討論的概念。這個順序并不是一成不變的，僅僅因為我們進入了新的階段，并不意味著我們不應(yīng)該在必要時重新審視我們之前的假設(shè)。例如，你可能會以一個強烈的團隊意識開始你的重構(gòu)工作，但是在起草執(zhí)行計劃的過程中，你可能會發(fā)現(xiàn)你需要比最初預(yù)期的更多的工程師。這沒關(guān)系，這種情況經(jīng)常發(fā)生！排版約定本書使用以下排版約定。斜體（Italic）表示新術(shù)語、URL、電子郵件地址、文件名和文件擴展名。等寬字體（Constant width）表示程序片段，以及正文中出現(xiàn)的程序元素，例如變量、函數(shù)名、數(shù)據(jù)類型、語句和關(guān)鍵字。使用代碼示例補充材料（代碼示例、練習(xí)等）可在以下鏈接下載：https://github.com/qcmaude/refactoring-at-scale。本書是要幫你完成工作的。一般來說，如果本書提供了示例代碼，你可以把它用在你的程序或文檔中。除非你使用了很大一部分代碼，否則無需聯(lián)系我們獲得許可。比如，用本書的幾個代碼片段寫一個程序就無需獲得許可。銷售或分發(fā)OReilly圖書的示例需要獲得許可，引用本書中的示例代碼回答問題無需獲得許可，將書中大量的代碼放到你的產(chǎn)品文檔中需要獲得許可。我們很希望但并不強制要求你在引用本書內(nèi)容時加上引用說明。引用說明一般包括書名、作者、出版社和ISBN，例如：Refactoring at Scale by Maude Lemaire(OReilly). Copyright 2021 Maude Lemaire, 978-1-492-07553-0 。如果你覺得自己對示例代碼的使用超出了上述許可范圍，請通過permissions@oreilly.com 與我們聯(lián)系。OReilly 在線學(xué)習(xí)平臺（OReilly Online Learning）近40 年來，OReilly Media 致力于提供技術(shù)和商業(yè)培訓(xùn)、知識和卓越見解，來幫助眾多公司取得成功。公司獨有的專家和改革創(chuàng)新者網(wǎng)絡(luò)通過OReilly 書籍、文章以及在線學(xué)習(xí)平臺，分享他們的專業(yè)知識和實踐經(jīng)驗。OReilly 在線學(xué)習(xí)平臺按照您的需要提供實時培訓(xùn)課程、深入學(xué)習(xí)渠道、交互式編程環(huán)境以及來自O(shè)Reilly 和其他200 多家出版商的大量書籍與視頻資料。更多信息，請訪問網(wǎng)站：https://www.oreilly.com/。聯(lián)系我們?nèi)魏斡嘘P(guān)本書的意見或疑問，請按照以下地址聯(lián)系出版社。美國：OReilly Media, Inc.1005 Gravenstein Highway NorthSebastopol, CA 95472中國：北京市西城區(qū)西直門南大街2 號成銘大廈C 座807 室（100035）奧萊利技術(shù)咨詢（北京）有限公司勘誤、示例和其他信息，請訪問https://oreil.ly/refactoring-at-scale。對于本書的評論和技術(shù)性問題，請發(fā)送電子郵件到errata@oreilly.com.cn。要了解更多OReilly 圖書和培訓(xùn)的信息，請訪問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 把一個沒有經(jīng)驗的作者（我）變成了一位出版的作者。他的反饋總是非常準確，幫助我更有條理地組織我的思路，并鼓勵我在我寫得太啰嗦時進行刪減（這種情況經(jīng)常發(fā)生）。我簡直無法想象有比他更好的編輯。其次，我要感謝少數(shù)幾個朋友和同事，他們閱讀了幾章的早期版本：Morgan Jones、Ryan Greenberg 和Jason Liszka。他們的反饋讓我確信我的想法是正確的，并且對廣泛的讀者有價值。對于鼓勵和引發(fā)思考的談話，感謝Joann、Kevin、Chase 和Ben。我要感謝Maggie Zhou，在第二個案例研究章節(jié)（第11 章）中與我共同撰寫。她是我曾經(jīng)一起工作過的最有思想、最聰明、最有活力的同事之一，我很高興讓世界讀到我們一起的冒險！非常感謝我的技術(shù)審稿人David Cottrell 和Henry Robinson。David 是我大學(xué)時的好朋友，在Google 工作多年，領(lǐng)導(dǎo)了許多大規(guī)模的重構(gòu)。他后來創(chuàng)立了自己的公司。Henry 是我在Slack 的同事，做出了無數(shù)的開源貢獻，并親眼見證了硅谷公司的爆炸式增長。他們都是非常有責(zé)任心的工程師，這本書從他們的指導(dǎo)和智慧中受益匪淺。我感激他們花費許多時間來驗證書中的內(nèi)容。最終手稿中的任何不準確之處都是我的錯誤。感謝所有曾經(jīng)和我一起重構(gòu)過東西的人。你們太多了，無法一一列舉，但你們知道自己是誰。你們都對本書中的思想產(chǎn)生了影響。感謝我的家人（Simon、Marie-Josée、Fran?ois-Rémi、Sophie、Sylvia、Gerry、Stephanie 和Celia）在場外為我加油。最后，感謝我的丈夫Avery。謝謝你的耐心，謝謝你給我寫作的時間、空間和鼓勵。謝謝你讓我占用了無數(shù)個下午來討論一個、兩個（或三個、四個）想法。謝謝你相信我。這本書和你一樣屬于我。我愛你。