重構

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

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

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

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

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

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

在修改bug時進行重構。

在代碼複審時進行重構。

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

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

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

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

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

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

提高性能的三種方法：

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

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

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

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

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

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

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

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

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

模糊的方法名 ^[2]