重構是一種有條理的技術，用於重新建構現有的程式碼主體，改變其內部結構，而不改變其外部行為。其核心是一系列小型的行為保留轉換。每個轉換（稱為「重構」）的作用很小，但這些轉換的序列可以產生顯著的重構。由於每個重構都很小，因此出錯的可能性較低。每次重構後，系統都會保持完全運作，降低系統在重構期間嚴重損壞的機率。

重構第一版和第二版之間變更的簡要摘要

我正在完成重構書籍的新版本。以下是詳細資訊和關於我工作的定期備忘錄。

計算和格式化影音商店帳單的簡單範例開啟了我在 1999 年的重構書籍。如果使用現代 JavaScript 進行，你可以採取多種方法進行重構。我將在此探討四種方法：重構為頂層函式、重構為具有調度器的巢狀函式、使用類別，以及使用中間資料結構進行轉換。

在本文中，我將逐步介紹從實際程式碼庫中進行的一組重構。這並不是為了展示完美，而是代表現實。

許多現代網路伺服器程式碼會與上游服務通訊，這些服務會傳回 JSON 資料，對該 JSON 資料進行一些整理，然後使用時髦的單頁式應用程式框架將其傳送至豐富的客戶端網頁。與使用此類系統的人交談時，我聽到了相當多的抱怨，抱怨他們需要做多少工作來處理這些 JSON 文件。透過封裝載入策略的組合，可以避免許多這種挫折。

我們的大部分軟體邏輯都是用我們的程式語言寫的，這些語言給我們一個最佳的環境來撰寫和演進此類邏輯。但有些情況下，將此邏輯移到我們的命令式程式碼可以詮釋的資料結構中是有用的，也就是我所稱的自適應模型。在這裡，我將展示 JavaScript 中的一些產品選擇邏輯，並展示如何將其重構為編碼在 JSON 中的簡單生產規則系統。此 JSON 資料讓我們可以在使用不同程式語言的裝置之間分享此選擇邏輯，並在不更新這些裝置上的程式碼的情況下更新此邏輯。

隨著程式成長，將其分割成模組非常重要，這樣您就不需要理解所有程式才能進行小修改。這些模組通常可以由不同的團隊提供，並動態地結合。在此重構文章中，我使用表示層-領域層-資料層分層分割一個小程式。然後，我重構這些模組之間的相依性，以引入服務定位器和依賴性注入模式。這些模式適用於不同的語言，但看起來不同，所以我同時在 Java 和無類別 JavaScript 樣式中展示這些重構。

迴圈是處理集合的經典方式，但隨著程式語言中一級函式的採用率提高，集合管線成為一個有吸引力的替代方案。在本文中，我將透過一系列小範例來探討將迴圈重構成集合管線。

當我撰寫處理外部服務的程式碼時，我發現將存取程式碼分隔成獨立的物件很有價值。在這裡，我將展示如何將一些凝結的程式碼重構成此分隔的常見模式。

如果您正在驗證一些資料，通常不應該使用例外來表示驗證失敗。在這裡，我將說明如何將此類程式碼重構成使用通知模式。

一個簡單的範例，說明透過先重構程式碼讓變更更簡單，可以讓變更變得更容易。

重構已發展成一種廣為人知的技術，而且大多數軟體開發團隊至少宣稱自己會定期進行重構。然而，許多團隊並未了解重構可使用的不同工作流程，因此錯失將重構有效納入其開發活動的機會。在此簡報中，我將探討各種不同的工作流程。我希望這能鼓勵團隊將重構更深入地整合到其工作中，進而產生設計更好的程式碼庫，讓新增新功能變得更快速、更簡單。

James Shore 的《敏捷開發的藝術》是我最喜歡的敏捷軟體開發單冊書。原因之一是它非常強調讓敏捷開發有效運作的技術實務。James 和我討論重構在軟體開發中的角色、我們看到的設計變更的性質，以及如何將大型變更分解成小部分。

在過去十年左右，重構已成為一種廣泛使用的技術，用於維持程式碼庫的高內部品質。然而，大多數團隊並未充分利用重構，因為他們不知道可以使用重構的各種工作流程。在慕尼黑舉行的 OOP 2014 主題演講中，我探討了其中一些工作流程：例如垃圾收集重構、理解重構和預備重構。我也提醒大家，為什麼重構的常見理由會破壞你的最大努力。（此演講也有作為 資訊簡報 的處理方式。）

在過去十年中，我們開發並改進了許多技術，讓資料庫設計可以在應用程式開發時演化。這對敏捷方法來說是一項非常重要的功能。這些技術仰賴將持續整合和自動化重構應用於資料庫開發，以及資料庫管理員和應用程式開發人員之間的密切合作。這些技術適用於生產前和已發行的系統，以及全新專案和舊有系統。

Ruby Rogues 是 Ruby 世界中一個流行的程式設計 Podcast。他們邀請我回去討論 Ruby 版本 的 重構。我們討論了重構的定義、為什麼我們發現不太使用偵錯程式、可以做些什麼來使這本書現代化、重構工具的角色、註解是否可以善加利用、重構和重寫之間的權衡、模組化和微服務，以及軟體產業在過去二十年來如何改變。

2001 年 1 月，兩個 Java 工具跨越了重構的界線。現在 Java 中的重構有了嚴謹的工具支援

Kent Beck 在 1990 年代後期開發 極限編程 時提出了他的四個簡單設計規則。我這樣表達它們。

到目前為止，重構工具 已出現在許多語言中。在 Smalltalk 的帶領下，我們已經看到幾個 Java 工具和幾個 C# 工具。儘管有 呼籲，但 C++ 是一個顯著缺席的語言。儘管第一篇重構論文是由背景為 C++ 的 Bill Opdyke 所撰寫的。

程式碼異味是表面上顯示的跡象，通常對應到系統中更深層的問題。這個術語最初是由 Kent Beck 在協助我撰寫《重構》一書時創造的。

每當兩個或三個值聚集在一起時，請將它們變成一個 $%#$%^ 物件。

-- 我（用聲音表達會更有趣）

這是《重構》一書中我最喜歡的程式碼異味之一。當您不斷看到同幾個資料項目一起傳遞時，就會發現它。start 和 end 是資料群集想要成為範圍的一個好範例。資料群集通常是基本值，沒有人會想到將其變成物件。

在我的《重構》一書中，我給了重構幾個定義。

重構這個字從何而來？

從我開始談論和撰寫重構以來，人們一直問我如何將其納入更廣泛的軟體開發過程中。軟體開發生命週期中是否應該有重構階段？應將多少比例的迭代用於重構任務？我們應如何找出誰應該負責重構工作？儘管有些地方需要安排一些重構工作，但我比較鼓勵將重構作為一種機會主義活動，在任何需要清理程式碼的時間和地點進行，而且由任何人執行。

對影響所有使用者的介面進行變更需要兩種思考模式：實作變更本身，然後更新所有使用方式。當您嘗試同時執行這兩項時，這可能會很困難，特別是當變更在具有多個或外部客戶端的已發布介面上時。

平行變更，又稱為擴充和收縮，是一種模式，用於以安全的方式實作介面的向下不相容變更，方法是將變更分為三個不同的階段：擴充、遷移和收縮。

你能使用重構來建置一個平台嗎？

最近一篇由 Robert Cringely 撰寫的文章，最近在重構社群中引起一陣小小的騷動，因為他批評了重構。Phlip 在 重構郵件清單 上總結了回應，以一種異常克制的態度表示「...他聽起來像一個『懷疑論者』，撰寫他無意閱讀的書籍評論。」

「重構」這個術語曾經只為少數人所知，現在卻在電腦產業中廣泛流傳。我喜歡認為我對此負有部分責任，並希望它改善了一些程式設計師的生活和一些企業的獲利能力。（重要的一點是，我不是重構的始祖或發明者，只是一個記錄者。）

看起來 UIUC 的那些狡猾的人準備重構 Fortran 了。Brian Foote 在他的文章中寫到這個專案，以他無與倫比的風格。（他是軟體界最有趣的作家之一，但讓他寫任何東西通常就像從一隻活生生的劍齒虎身上拔牙，同時戴著一串剛宰殺的羊排項鍊。）（是的，我知道這是舊聞，但我在他的部落格上看到其他東西，然後找到了這個。）

當人們想到程式碼檢閱時，他們通常會想到開發團隊工作流程中的一個明確步驟。如今，在 Pull Request 上執行的整合前檢閱是最常見的程式碼檢閱機制，以至於許多人愚蠢地認為不使用 Pull Request 會消除所有進行程式碼檢閱的機會。如此狹隘的程式碼檢閱觀點不僅忽視了許多明確的檢閱機制，更重要的是忽視了可能是最強大的程式碼檢閱技術，也就是由整個團隊進行的持續精煉。

自測試程式碼是我在 重構 中使用的名稱，用於指稱編寫全面自動化測試與功能軟體相結合的做法。如果執行得當，這將允許你呼叫執行測試的單一指令，而且你可以確信這些測試將找出隱藏在你程式碼中的任何錯誤。

當我聆聽我們的開發團隊討論他們的作業時，一個常見的主題是他們不喜歡靜態中保留的事物。通常我們會看到以靜態初始值設定程式碼保留在靜態變數中的常見服務或元件。靜態（在多數語言中）最大的問題之一是您無法使用多型性以一個實作替換另一個實作。這對我們造成許多困擾，因為我們是測試的忠實愛好者，而且為了進行良好的測試，能夠以服務 Stub替換服務非常重要。