From: http://www.cnblogs.com/lane_cn/archive/2006/02/05/325782.html

什么是重構

重構，用最簡單的一句話說：就是要在不改變系統功能的情況下，對系統的內部結構進行重新調整。重構的最直接目的在于改進軟件系統的內部架構。一個好的結構可以更加適應于需求的變化，更好的滿足客戶的需求，最大限度的延長軟件系統的生命周期。

為什么要重構

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

重構的重要性要從軟件的生命周期說起。軟件不同與普通的產品，他是一種智力產品，沒有具體的物理形態。一個軟件不可能發生物理損耗，界面上的按鈕永遠不會因為按動次數太多而發生接觸不良。那么為什么一個軟件制造出來以后，卻不能永遠使用下去呢？

對軟件的生命造成威脅的因素只有一個：需求的變更。一個軟件總是為解決某種特定的需求而產生，時代在發展，客戶的業務也在發生變化。有的需求相對穩定一些，有的需求變化的比較劇烈，還有的需求已經消失了，或者轉化成了別的需求。在這種情況下，軟件必須相應的改變。

考慮到成本和時間等因素，當然不是所有的需求變化都要在軟件系統中實現。但是總的說來，軟件要適應需求的變化，以保持自己的生命力。

這就產生了一種糟糕的現象：軟件產品最初制造出來，是經過精心的設計，具有良好架構的。但是隨著時間的發展、需求的變化，必須不斷的修改原有的功能、追加新的功能，還免不了有一些缺陷需要修改。為了實現變更，不可避免的要違反最初的設計構架。經過一段時間以后，軟件的架構就千瘡百孔了。bug越來越多，越來越難維護，新的需求越來越難實現，軟件的構架對新的需求漸漸的失去支持能力，而是成為一種制約。最后新需求的開發成本會超過開發一個新的軟件的成本，這就是這個軟件系統的生命走到盡頭的時候。

重構就能夠最大限度的避免這樣一種現象。系統發展到一定階段后，使用重構的方式，不改變系統的外部功能，只對內部的結構進行重新的整理。通過重構，不斷的調整系統的結構，使系統對于需求的變更始終具有較強的適應能力。

拒絕變化 VS 擁抱變化

按照傳統的軟件設計方式，軟件的生產分為需求調查、概要設計、詳細設計、編碼、單體測試、聯合測試、現場部署幾個階段。雖說這幾個階段是可以互相滲透，但是總的來說是有一定次序的，前一個階段的工作是后一個階段工作的基礎。這就向下面這樣一種V形的模式：



往下的方向將系統進行分解，往上的方向將系統進行整合。這樣的開發形式將軟件開發分為設計前和設計后兩個階段，開發過程中存在一個重要的“里程碑”——設計說明書的。在設計說明書完成前，工程處于“設計”階段，而在設計說明書完成之后，工程則進入“實施”階段。一旦到了實施階段，任何需求或者設計上的變更都是非常困難的，需要花費大量的成本。通常為了保證工程的順利實施，開發人員常有這樣一種沖動：按住客戶的手，在需求說明書上簽字。并且告訴客戶：“從今天開始，任何需求變更都要停止，直到我們把現在這個東西做完。”這是一種拒絕變化的開發方式。

軟件系統要保持與企業的目標一致。時代在發展，人們的要求在不斷的提高，客戶的業務在不斷的發展。在這種情況下，傳統的先設計、再施工的V形式已經不能適應日益復雜的業務需要。軟件工程逐漸演化成下面這樣的過程：



說明一下：
1、軟件開發的目標要與企業目標保持一致，一個開發周期不宜時間過長，一般控制在半年到一年。系統部署后，并不意味著開發工作結束了，而是進入了下一個周期。

2、工程以循環迭代的方式前進，這并不意味輕視了設計，不是要搞邊調研、邊設計、邊施工的“三邊”工程，相反，是更加重視設計的地位。軟件開發的全過程都需要設計，軟件開發是“持續設計”的過程。同時，設計工作也不只是簡單過程分解、任務分配，而是概念設計、邏輯設計、物理設計等各個方面互相交織、齊頭并進。

傳統的軟件開發方式使用一種非常理想化的流程——先與客戶討論項目的范圍，確定哪些需要做，哪些不需要做，然后規劃一個完美的設計，不僅可以滿足現在的需求，還能很好的適應未來的需求，設計完成后開始編碼，然后測試組裝，送到現場安裝調試運行。這一系列過程就類似與發射一顆炮彈，首先要找到目標，然后根據地形、風力、目標的位置、移動速度等各種因素，計算提前量、炮彈發射的角度，計算出一個拋物線軌道，最后在合適的時間把炮彈發射出去。這一切都符合最正確的物理定律，一切都聽起來很理想。如果沒有意外條件，當然是可以擊中目標的。但是炮彈一旦發射出去，一切就失去了控制，任何環境的變化都會造成偏離目標。尤其是對于一個運動的目標來說，計算過程十分復雜，很多情況下只能靠人估計。對于不規則的運動目標只能碰碰運氣。這樣的方式，命中率是很低的。

新的軟件開發過程不追求完美的、長期的、理想的計劃，更加重視實際情況，重視需求的變化，提倡采用短期的計劃。這是一種擁抱變化的過程。就象是在炮彈上安裝了一個反饋裝置，鎖定目標后，確保大方向的正確，然后就將炮彈發射出去。炮彈在運行過程中不斷的將目標位置偏移量輸入反饋電路，根據反饋輸出調整自己的運行路線，無限的逼近目標。這樣，炮彈就擁有了制導能力，命中率大大增加。

重構就可以增加工程的調整能力，他可以把產品回復到一個穩定的狀態，可以基于這個狀態達到下一個目標。如此反復前進，更好的滿足客戶的需求。

保持兼容性

重構的目的在于改變系統的實現方式，而不改變原有的功能。這個過程中，判斷兼容性就十分的重要。一個子系統、模塊、類、函數是否與升級前保持兼容，如何判斷這個兼容性，如何保持這個兼容性，這關系到重構的成本和重構的可能性。

程序員學習寫程序代碼時，會發現隨著程序代碼愈來愈多，許多的程序代碼不斷重復出現和被使用，因此很自然的開始使用例程、子程序或是過程、函數等機制幫助我們進行程序代碼整理的工作。于是很自然的，字體的分析方式演化成這個樣子：將客戶的需求過程進行分解，一步一步的分解，直到可以直接的實現他。這就是面向過程的分析方式。

面向過程的分析方式對變化的能力是很弱的。為什么呢？因為面向過程的分析方式很容易造成一種傾向——不區分行動的主體。一個過程是沒有主體的，他不是在為自己工作，而是在為“別人”工作。當我們修改了一個過程之后，我們很難判斷這個過程是否保持向后兼容，其他過程會不會受到影響。因為這個過程對外界有意義的不僅是他的輸入和輸出，還包括每一步過程，每一步過程都可能含有一個非常隱諱的業務意義，對外界產生影響。

因此，修改一個過程是非常困難的，通常升級一個面向過程的系統，可以采用兩種方式：
1、寫新的過程；
2、在原有的過程上加開關參數。

除此以外的升級辦法都很難保證原過程和新過程的兼容性，容易造成錯誤。

為了更好的保證升級后模塊的兼容性，應該采用面向對象的分析方式。按照這樣的分析方式，一個對象為“自己”工作，他有完整的、獨立的業務含義。對象之間通過接口發生聯系，一個對象對外界有影響的部分只有接口，至于他做什么、如何做、做的對不對，則不是外界需要關心的事情。

判斷一個接口升級后是否保持兼容性就是一件比較容易的事情了。我們可以判斷接口的輸入輸出是否符合下面兩條規則：
1、升級后的輸入是升級前的輸入的超級；
2、升級后的輸出是升級前的輸出的子集。

只要符合這兩點，他就仍然可以在系統中運行，不會對其他對象造成危害。在實際的工程中，判斷這個兼容性有一個更好的辦法：自動化的單元測試。

在重構的過程中，自動化的單元測試是非常好的保障。采用自動化的單元測試，不斷運行測試，可以保證系統的結構改變的過程中，業務行為不發生改變。