### 這場游戲的本質 以下面介紹的重構手法中，你肯定會注意到一件事：重構步驟的描述，不再如前面 那么仔細。這是因為在大型重構中，情況有很多變化，我們無法告訴你準確的重構步驟；如果沒有看到實際情況，任誰都無法確切知道該怎么做。當你為某個函數添加參數時，作法可以很仔細而清楚，因為重構范圍（作用域）很清楚。但是當你分 解一個繼承體系時，由于每個繼承體系都是不同的，所以我們無法告訴你確切的重構步驟。 另外，對于這些大型重構，還有一件事需要注意：它們會耗費相當長的時間。第6 章至第11章所介紹的重構手法，都可以在數分鐘（至多一個小時）內完成，但是我們曾經進行過的一些大型重構，卻需要數月甚至數年的時間。如果你需要給一個運行中的系統添加功能，你不可能說服經理把系統停止運行兩個月讓你進行重構； 你只能一點一點地做你的工作，今天一點點，明天一點點。 在這個過程中，你應該根據需要安排自己的工作，只在需要添加新功能或修補錯誤 時才進行重構。你不必一開始就完成整個系統的重構；重構程度只要能滿足其他任務的需要就行了。反正明天你還可以回來重構。 本章范例也反映出這樣的哲學。如果要向你展示本書中所有的重構，輕易就能耗去上百頁篇幅。我們很清楚這一點，因為Martin 的確嘗試過。所以，我們把范例壓縮至「數張概略圖」的尺度。 由于大型重構可能需要花費相當長的時間，因此它們并不像其他章節介紹的重構那樣，能夠立刻讓人滿意。你必須有那么一點小小的信仰：你每天都在使你自己的程序世界更安全。 進行大規模重構時，有必要為整個開發團隊建立共識；這是小型重構所不需要的。大型重構為許許多多的修改指定了方向。整個團隊都必須意識到：有一個大型重構正在進行，每個人都應該相應地安排自己的行動。說到這里，我想給大家講個故事。 兩個家伙的車子在山頂附近拋錨了，于是他倆走下車，一人走到車的一頭，開始推車。經過毫無成果的半小時之后，車頭那家伙開口說道：『我從來不知道把車推下山這么難！』另一個家伙答道：『嘿，你說「推下山」是什么意思？難道我們不是想把車推上山嗎？』我猜你一定不想讓這個故事在你的開發團隊中重演，對吧！ 大型重構的重要性 我們已經看到，使那些小型重構突顯價值的質量（可預測的結果、可觀察的過程、 立竿見影的滿足等等〕，在大型重構中往往并不存在。既然如此，為什么大型重構還那么重要，以至于我們想要把它們放進本書？那是因為如果沒有它們，我們就可能面臨這樣的風險：投入了大把時間學習重構，在實際工作中卻無法獲得實在的利益。這對我們來說是非常糟糕的，我們不能容忍這種事情發生。 更重要的是，你之所以需要重構，決不會是因為它很好玩，而是因為你希望它能對你的程序有所幫助，讓你能夠做一些重構之前無法做的事情。 正如水草會堵塞河道一樣，在一知半解的情況下做出的設計決策，一旦堆積起來，也會使你的程序陷于癱瘓。通過重構，你可以保證隨時在程序中反映出自己對于「應該如何設計程序」的完整理解。正如水草會迅速蔓延一樣，對系統理解不夠完整的設計決策，也會很快地將它們的影響蔓延到整個程序中。要根除這種錯誤，一 個、兩個、甚至十個單獨的行為都是不夠的，只有持續而無處不在的重構才有可能竟其功。 四個大型重構 本章之中，我們將介紹四個大型重構實例。這些僅僅是例子，我們并沒有打算覆蓋所有領域。迄今為止，絕大多數關于重構的研究和實踐都集中于比較小的重構手法上，以這種方式談論大型重構，是一種非常新鮮的作法，這主要來自于：Kent 的經 \驗。在大規模重構方面，Kent 的經驗比其他所有人都要豐富。 Tease Apart Inheritance 用于處理混亂的繼承體系——這種繼承體系往往以一種令人迷惑的方式組合了數個不同方面的變化（variations）。Convert Procedural Design to Objects可以幫助你解決一個「古典」問題：如何處理程序性代碼（procedural code ）？許多使用面向對象語言的程序員，其實并沒有真正理解面向對象技術，因此你常會需要使用這項重構。如果你看到以傳統的雙層結構（two-tier， 用戶界面和數據庫）方式編寫的代碼，你能需要使用Separate Domain from Presentation 將業務邏輯（business logic）與用戶界面（user interface ）隔離開來。經驗豐富的面向對象開發人員發現：對于一個長時間、大負荷運轉的系統來說，這樣的分離是至關重要的。Extract Hierarchy 則可以將過于復雜的class 轉變為一群subclass ，從而簡化系統。