重構[術語]

重構（Refactoring）就是通過調整程式代碼改善軟體的質量、性能，使其程式的設計模式和架構更趨合理，提高軟體的擴展性和維護性。

重構必要

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

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

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

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

重構可以降低項目的耦合度，使項目更加模組化，有利於項目的開發效率和後期的維護。讓項目主框架突出鮮明，給人一種思路清晰，一目了然的感覺，其實重構是對框架的一種維護。

重構目標

•改進軟體設計使軟體更容易被理解

•幫你找到bug

•提高軟體的開發速度

重構時機

在添加新功能時進行重構。

在修改bug時進行重構。

在代碼複審時進行重構。

到了最後的交付期限，不進行重構

間接層

間接層的存在的價值：允許邏輯共享；分開解釋意圖和實現；將變化加以隔離；將條件邏輯加以編碼

但是過多的間接層會導致代碼的層次太深，使代碼難以閱讀.因此要權衡加入間接層的利弊.

重構難題

關係資料庫與面向對象編程的問題——在對象模型和資料庫模型之間插入一個分隔層，這就可以隔離兩個模型各自的變化.升級某一模型時只需同時升級上述的分隔層即可.這樣的分隔層會增加系統複雜度.但是能增加靈活度.

修改接口的問題——修改已發布的接口，因為已發布的接口會供外部人員（其它公司）使用，因此，修改接口會導致引用接口的其它程式不修改程式就無法運行.修改接口的最好的辦法是增加一個新的接口，讓舊接口調用新接口.這樣原來的程式就不用修改了.對於接口的另一個建議是儘量不要發布接口.

重構與設計

重構與設計是互補的，程式應該是先設計，而在開始編碼後,設計上的不足可以用重構來彌補.設計應該是適度的設計，而不必過度的設計.如果能很容易的通過重構來適應需求的變化，那么就不必過度的設計，當需求改變時再重構代碼.

提高性能

提高性能的三種方法：

時間預算法——在設計時就對程式花費的時間進行預算，通常用於性能要求極高的實時系統.普通的企業應用程式一般對性能要求不高.只要不太慢就可以了.

持續關注法——要求程式設計師在任何時間都要設法保持系統的高性能.這個方法有個缺陷，就是大部分的程式90%的最佳化工作都是白費勁，這樣會浪費大量的時間.

良好的分解方式——這個方式是在開發程式階段不對性能投以任何關注，直到進入性能最佳化階段，再分析程式中性能差的程式，然後對這些程式進分解，查出性能差的程式，進行最佳化.

重構的原因

臃腫的類: 類之所以會臃腫，是因為開發者缺乏對最基本的編碼原則，即“單一職責原則”（SRP）的理解。這些類往往會變得很臃腫，是由於不同的且在功能上缺少關聯的方法都放在了相同的類裡面。

長方法: 方法之所以會變得很長主要是有以下幾個原因：

許多沒有關聯性的、功能複雜的模組的代碼都放在相同的方法內。這主要是開發者缺乏SRP的概念。

多種條件都放在同一個方法內，這在長方法內經常會發生的。這是由於缺乏McCabe代碼複雜度和SRP的概念的比較。

大量的傳參: 我經常遇到這幾種情況，一些方法跟另一些方法進行互動，或者調用另一些方法的時候傳入大量的參數。這就會出現如果更改了其中一個參數，就得在多個方法內進行更改。

常量值無處不在: 經常會發現開發者（尤其是新手）會使用一些具有明確含義的常量值（主要是魔鬼數字），但沒有給它們賦予合適的常量變數。這會降低代碼的可讀性和可理解性。

模糊的方法名