重構（Refactoring）就是在不改變軟件現有功能的基礎上，通過調整程序代碼改善軟件的質量、性能，使其程序的設計模式和架構更趨合理，提高軟件的擴展性和維護性。

　　也許有人會問，為什么不在項目開始時多花些時間把設計做好，而要以后花時間來重構呢？要知道一個完美得可以預見未來任何變化的設計，或一個靈活得可以容納任何擴展的設計是不存在的。系統設計人員對即將著手的項目往往只能從大方向予以把控，而無法知道每個細枝末節，其次永遠不變的就是變化，提出需求的用戶往往要在軟件成型后，始才開始"品頭論足"，系統設計人員畢竟不是先知先覺的神仙，功能的變化導致設計的調整再所難免。所以"測試為先，持續重構"作為良好開發習慣被越來越多的人所采納，測試和重構像黃河的護堤，成為保證軟件質量的法寶。

　　一、為什么要重構（Refactoring）

　　在不改變系統功能的情況下，改變系統的實現方式。為什么要這么做？投入精力不用來滿足客戶關心的需求，而是僅僅改變了軟件的實現方式，這是否是在浪費客戶的投資呢？

　　重構的重要性要從軟件的生命周期說起。軟件不同與普通的產品，他是一種智力產品，沒有具體的物理形態。一個軟件不可能發生物理損耗，界面上的按鈕永遠不會因為按動次數太多而發生接觸不良。那么為什么一個軟件制造出來以后，卻不能永遠使用下去呢？
　　對軟件的生命造成威脅的因素只有一個：需求的變更。一個軟件總是為解決某種特定的需求而產生，時代在發展，客戶的業務也在發生變化。有的需求相對穩定一些，有的需求變化的比較劇烈，還有的需求已經消失了，或者轉化成了別的需求。在這種情況下，軟件必須相應的改變。
　　考慮到成本和時間等因素，當然不是所有的需求變化都要在軟件系統中實現。但是總的說來，軟件要適應需求的變化，以保持自己的生命力。
　　這就產生了一種糟糕的現象：軟件產品最初制造出來，是經過精心的設計，具有良好架構的。但是隨著時間的發展、需求的變化，必須不斷的修改原有的功能、追加新的功能，還免不了有一些缺陷需要修改。為了實現變更，不可避免的要違反最初的設計構架。經過一段時間以后，軟件的架構就千瘡百孔了。bug越來越多，越來越難維護，新的需求越來越難實現，軟件的構架對新的需求漸漸的失去支持能力，而是成為一種制約。最后新需求的開發成本會超過開發一個新的軟件的成本，這就是這個軟件系統的生命走到盡頭的時候。
　　重構就能夠最大限度的避免這樣一種現象。系統發展到一定階段后，使用重構的方式，不改變系統的外部功能，只對內部的結構進行重新的整理。通過重構，不斷的調整系統的結構，使系統對于需求的變更始終具有較強的適應能力。

　　通過重構可以達到以下的目標：

　　· 持續偏糾和改進軟件設計
　　重構和設計是相輔相成的，它和設計彼此互補。有了重構，你仍然必須做預先的設計，但是不必是最優的設計，只需要一個合理的解決方案就夠了，如果沒有重構、程序設計會逐漸腐敗變質，愈來愈像斷線的風箏，脫韁的野馬無法控制。重構其實就是整理代碼，讓所有帶著發散傾向的代碼回歸本位。

　　· 使代碼更易為人所理解
　　Martin Flower在《重構》中有一句經典的話："任何一個傻瓜都能寫出計算機可以理解的程序，只有寫出人類容易理解的程序才是優秀的程序員。"對此，筆者感觸很深，有些程序員總是能夠快速編寫出可運行的代碼，但代碼中晦澀的命名使人暈眩得需要緊握坐椅扶手，試想一個新兵到來接手這樣的代碼他會不會想當逃兵呢？
　　軟件的生命周期往往需要多批程序員來維護，我們往往忽略了這些后來人。為了使代碼容易被他人理解，需要在實現軟件功能時做許多額外的事件，如清晰的排版布局，簡明扼要的注釋，其中命名也是一個重要的方面。一個很好的辦法就是采用暗喻命名，即以對象實現的功能的依據，用形象化或擬人化的手法進行命名，一個很好的態度就是將每個代碼元素像新生兒一樣命名，也許筆者有點命名偏執狂的傾向，如能榮此雅號，將深以此為幸。
　　對于那些讓人充滿迷茫感甚至誤導性的命名，需要果決地、大刀闊斧地整容，永遠不要手下留情！

　　· 幫助發現隱藏的代碼缺陷
　　孔子說過：溫故而知新。重構代碼時逼迫你加深理解原先所寫的代碼。筆者常有寫下程序后，卻發生對自己的程序邏輯不甚理解的情景，曾為此驚悚過，后來發現這種癥狀居然是許多程序員常患的"感冒"。當你也發生這樣的情形時，通過重構代碼可以加深對原設計的理解，發現其中的問題和隱患，構建出更好的代碼。

　　· 從長遠來看，有助于提高編程效率
　　當你發現解決一個問題變得異常復雜時，往往不是問題本身造成的，而是你用錯了方法，拙劣的設計往往導致臃腫的編碼。
　　改善設計、提高可讀性、減少缺陷都是為了穩住陣腳。良好的設計是成功的一半，停下來通過重構改進設計，或許會在當前減緩速度，但它帶來的后發優勢卻是不可低估的。