有時(shí)候，會(huì )有程序員跑到我這里說(shuō)他們不喜歡某個(gè)東西的設計，“我們需要給它來(lái)個(gè)全面的重構”，來(lái)糾正里面的錯誤。哦，哦。這聽(tīng)起來(lái)可不是個(gè)好主意。而且這聽(tīng)起來(lái)也不是重構…

重構(Refactoring)這個(gè)詞最初由Martin Fowler 和 Kent Beck給下的定義，它是

一種修改，使軟件的內部結構更容易理解，在不改變軟件的可見(jiàn)行為方式前提下使軟件更容易變更…它是一種有節制的整理代碼、使bug產(chǎn)生幾率最小化的方法。

重構的結果是引用了快捷方法、去除了重復代碼和死代碼，使設計和邏輯更加清晰。是在更好的、更聰明的使用編程語(yǔ)言。是在優(yōu)勢利用你現在知道、但當時(shí)的開(kāi)發(fā)程序員并不知道——或并沒(méi)有加以利用的信息。不斷的簡(jiǎn)化代碼，讓它們更容易理解。不斷的使它們在將來(lái)的變更變得更容易、更安全。

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

程序員，特別是做維護工作的程序員，清理代碼是他們的日常工作之一。這是基本工作，是必須要做的。Martin Fowler等人的貢獻是使重構代碼的最佳實(shí)踐方法格式化，并把常見(jiàn)的、證明切實(shí)有效的重構模式——重構的目標和重構的步驟——進(jìn)行歸檔分類(lèi)。

重構很簡(jiǎn)單。盡可能在寫(xiě)代碼前先寫(xiě)測試能夠防止你犯錯誤。小規模的、獨立的、穩妥的對代碼進(jìn)行結構上的調整，每次調整完后都要進(jìn)行測試，確保你沒(méi)有改變代碼的行為特征——功能和以前一樣，只是代碼上看著(zhù)不同。重構模式和現代化的IDE里的重構工具使重構變得容易、安全和代價(jià)低廉。

不要為了重構而重構

重構可以被當成一種能給你的代碼變更帶來(lái)幫助的措施。代碼重構應該在你進(jìn)行代碼變更前進(jìn)行，這樣能讓你確信你對代碼理解了，使你更容易、更安全的把變更引入代碼。對你的重構動(dòng)作進(jìn)行回歸測試。然后進(jìn)行糾正或變更。再次測試。之后可能需要對更多的代碼進(jìn)行重構，使你代碼變更的意圖變得更加清晰。再次進(jìn)行全面測試。重構，再變更�；蜃兏�，然后重構。

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

重構的范圍應該受你需要實(shí)施的代碼變更或代碼修正來(lái)決定——為了讓代碼變更更安全和更簡(jiǎn)潔，你應該做些什么？換句話(huà)說(shuō)：不要為了重構而重構。不要對那些你不打算進(jìn)行變更或不會(huì )變更的代碼進(jìn)行重構。

為理解而做簡(jiǎn)略重構(Scratch Refactoring)

Michael Feather的《Working Effectively with Legacy Code》這本書(shū)里提到了簡(jiǎn)略重構(Scratch Refactoring)的概念；Martin Fowler稱(chēng)之為“為理解而重構”。這是用來(lái)對付那些你不理解的(或不能忍受的)代碼，清理它們，這樣在你打算真正動(dòng)手修改它前，你能對它們是干什么的有了更好的理解，同樣也對你debug這些代碼有幫助。一旦你能清楚了一個(gè)變量或方法的真正意圖，重命名它們，給它們一個(gè)更合適的名稱(chēng)，刪除那些你不喜歡看的(或覺(jué)得沒(méi)有用的)代碼，拆解復雜的條件語(yǔ)句，把長(cháng)程序分解成數個(gè)容易理解的小程序。

不要惦記著(zhù)復查或測試這些改動(dòng)。這是為了讓你的重構快速的推進(jìn)——這能讓這些代碼以及它們的運行原理在你的大腦里產(chǎn)生一個(gè)快速但不完備的原型。從中學(xué)習，然后丟掉它們。簡(jiǎn)略重構還能讓你嘗試各種不同的重構途徑，學(xué)到更多的重構技巧。Michael Feathers建議說(shuō)，在這個(gè)過(guò)程中要留意那些看起來(lái)沒(méi)什么用處、或者特別有用的東西，這樣當你完成此練習后、要真正修改它們時(shí)，才能把事情做正確——修改時(shí)一點(diǎn)一點(diǎn)來(lái)，講究方法，邊修改邊測試。

什么是“大規�！敝貥�？

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

相對于這些較小的、行內的重構，更加重大的設計上的重構與之有明顯差異——這就是Martin Fowler所指的”大型重構”。大的、代價(jià)很高的變動(dòng)，附帶有大量的技術(shù)風(fēng)險。這不是你編程過(guò)程中的清理代碼和設計改進(jìn)：這是根本性的重新設計。

有些人喜歡把對一個(gè)系統的重新設計或重寫(xiě)或重新搭建平臺或返工叫“大規模重構”。因為技術(shù)上講，這些并不改變軟件功能特征——業(yè)務(wù)邏輯、軟件輸入和輸出仍和以前一樣，“只是”設計和代碼實(shí)現變了。它和常規重構的區別看起來(lái)就是：一個(gè)是重寫(xiě)了一段代碼，一個(gè)是重寫(xiě)了一個(gè)系統，只要你是一步一步做下來(lái)的，你都可以稱(chēng)之為“重構”——不管你是長(cháng)年累月被困于將一個(gè)老系統換成新代碼，還是對系統架構進(jìn)行大規模的改造。

“大規模重構”會(huì )變的很糟糕。你可能需要花數周、數月(甚至數年)才能完成，需要你對軟件的很多部分進(jìn)行改動(dòng)。軟件會(huì )因此不能運行，需要分多次發(fā)布這些變更，需要你做臨時(shí)的臺架(scaffolding)和變通方案——尤其是你采用短周期的敏捷開(kāi)發(fā)方法時(shí)。這時(shí)Branch by Abstraction這樣的實(shí)踐方法就派上用場(chǎng)了，它能幫你在長(cháng)周期內管理代碼中的變化。

而且在開(kāi)發(fā)新代碼的同時(shí)你還要維護舊代碼，這使得代碼版本控制很麻煩，變更起來(lái)不方便，致使代碼很脆弱，易犯錯——這正和重構所預期的目的背道而馳。有時(shí)這樣的情況會(huì )一直持續下去——這種新舊代碼交替的過(guò)程永遠不能完成，因為能獲得最大利益的部分都是最先完成，或者因為最初帶來(lái)這個(gè)想法的顧問(wèn)已經(jīng)干別的去了，或者是預算被消減，而且你也討厭維護這樣一個(gè)拖拉的項目。

這些是重構——那些不是

在這種重型的項目開(kāi)發(fā)過(guò)程中混入重構的概念是不對的。它們從根本上就是另外一種工作，帶有完全不同的開(kāi)發(fā)成本和風(fēng)險。它混淆了人們對什么是重構、重構能干什么的認識。

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

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

有些程序員認為對代碼進(jìn)行根本的、重大的修改是他們的權利和義務(wù)，在重構的名義下進(jìn)行重新設計、重寫(xiě)，為了將來(lái)，也不辜負自己的技藝。重新設計和重寫(xiě)有時(shí)候是你正確的該做的事情。但出于坦誠和表述清楚，請不要把這些活動(dòng)賦以重構的名義。