什麼是重構，什麼不是重構

有時候，會有程式員跑到我這裡說他們不喜歡某個東西的設計，“我們需要給它來個全面的重構”，來糾正裡面的錯誤。哦，哦。這聽起來可不是個好主意。而且這聽起來也不是重構…

重構(refactoring)這個詞最初由 martin fowler 和 kent beck 給下的定義，它是

一種修改，使軟體的内部結構更容易了解，在不改變軟體的可見行為方式前提下使軟體更容易變更…它是一種有節制的整理代碼、使 bug 産生幾率最小化的方法。

重構的結果是引用了快捷方法、去除了重複代碼和死代碼，使設計和邏輯更加清晰。是在更好的、更聰明的使用程式設計語言。是在優勢利用你現在知道、但當時的開發程式員并不知道——或并沒有加以利用的資訊。不斷的簡化代碼，讓它們更容易了解。不斷的使它們在将來的變更變得更容易、更安全。

在這個過程中發現了 bug、修改 bug，這不是重構。優化不是重構。強化異常捕捉、增加預防性代碼不是重構。讓代碼更容易測試不是重構——盡管重構能達到相同的效果。這些所有的事都是有益的。但這些都不是重構。

重構很簡單。盡可能在寫代碼前先寫測試能夠防止你犯錯誤。小規模的、獨立的、穩妥的對代碼進行結構上的調整，每次調整完後都要進行測試，確定你沒有改變代碼的行為特征——功能和以前一樣，隻是代碼上看着不同。重構模式和現代化的 ide 裡的重構工具使重構變得容易、安全和代價低廉。

不要為了重構而重構

重構可以被當成一種能給你的代碼變更帶來幫助的措施。代碼重構應該在你進行代碼變更前進行，這樣能讓你确信你對代碼了解了，使你更容易、更安全的把變更引入代碼。對你的重構動作進行回歸測試。然後進行糾正或變更。再次測試。之後可能需要對更多的代碼進行重構，使你代碼變更的意圖變得更加清晰。再次進行全面測試。重構，再變更。或變更，然後重構。

你不是為了重構而重構，你重構是因為你想做其它的事情，而重構能幫助你完成這些事情。

重構的範圍應該受你需要實施的代碼變更或代碼修正來決定——為了讓代碼變更更安全和更簡潔，你應該做些什麼？換句話說：不要為了重構而重構。不要對那些你不打算進行變更或不會變更的代碼進行重構。

為了解而做簡略重構(scratch refactoring)

michael feather 的《working effectively with legacy code》這本書裡提到了簡略重構(scratch refactoring)的概念；martin fowler 稱之為“為了解而重構”。這是用來對付那些你不了解的(或不能忍受的)代碼，清理它們，這樣在你打算真正動手修改它前，你能對它們是幹什麼的有了更好的了解，同樣也對你 debug 這些代碼有幫助。一旦你能清楚了一個變量或方法的真正意圖，重命名它們，給它們一個更合适的名稱，删除那些你不喜歡看的(或覺得沒有用的)代碼，拆解複雜的條件語句，把長程式分解成數個容易了解的小程式。

不要惦記着複查或測試這些改動。這是為了讓你的重構快速的推進——這能讓這些代碼以及它們的運作原理在你的大腦裡産生一個快速但不完備的原型。從中學習，然後丢掉它們。簡略重構還能讓你嘗試各種不同的重構途徑，學到更多的重構技巧。michael feathers 建議說，在這個過程中要留意那些看起來沒什麼用處、或者特别有用的東西，這樣當你完成此練習後、要真正修改它們時，才能把事情做正确——修改時一點一點來，講究方法，邊修改邊測試。

什麼是“大規模”重構？

對代碼進行簡單的但又明顯的重構：消除重複，修改變量和方法名稱使其更有意義，提煉方法使代碼更易懂、更易複用，簡化條件邏輯，把無意義的數字換成命名的變量，把相似的代碼集中到一起。通過這些重構，在代碼的可了解性和可維護性上，你能得到巨大的回報。

相對于這些較小的、行内的重構，更加重大的設計上的重構與之有明顯差異——這就是 martin fowler 所指的”大型重構”。大的、代價很高的變動，附帶有大量的技術風險。這不是你程式設計過程中的清理代碼和設計改進：這是根本性的重新設計。

而且在開發新代碼的同時你還要維護舊代碼，這使得代碼版本控制很麻煩，變更起來不友善，緻使代碼很脆弱，易犯錯——這正和重構所預期的目的背道而馳。有時這樣的情況會一直持續下去——這種新舊代碼交替的過程永遠不能完成，因為能獲得最大利益的部分都是最先完成，或者因為最初帶來這個想法的顧問已經幹别的去了，或者是預算被消減，而且你也讨厭維護這樣一個拖拉的項目。

這些是重構——那些不是

在這種重型的項目開發過程中混入重構的概念是不對的。它們從根本上就是另外一種工作，帶有完全不同的開發成本和風險。它混淆了人們對什麼是重構、重構能幹什麼的認識。

重構可以、也應該融入到你寫代碼或維護代碼的過程中——作為日常開發/品質管理的組成部分，就像寫測試和代碼審查一樣。重構應該被安靜的，持續的和低調的完成。它需要我們把工作精力分出一部分給它，它需要在我們的工期評估和風險評估中考慮到它的存在。如果做的正确，你不需要去解釋或向外人驗證這部分工作。

花幾分鐘、一兩個小時做重構，就像是你開發過程中的一種修改，是工作的一部分。如果它讓你花了數天時間，或者更長，那不是重構；那是重寫，或重新設計。如果你需要明确的留出一部分時間(或整個 sprint 周期)來重構代碼，如果需要為清理代碼而申請準許，或把清理代碼作為一個開發需求，那你不是在重構——即使你用了重構的技術和工具，你仍然做的是另外一種工作。

有些程式員認為對代碼進行根本的、重大的修改是他們的權利和義務，在重構的名義下進行重新設計、重寫，為了将來，也不辜負自己的技藝。重新設計和重寫有時候是你正确的該做的事情。但出于坦誠和表述清楚，請不要把這些活動賦以重構的名義。