重構必要
一個軟體總是為解決某種特定的需求而產生，時代在發展，客戶的業務也在發生變化。有的需求相對穩定一些，有的需求變化的比較劇烈，還有的需求已經消失了，或者轉化成了別的需求。在這種情況下，軟體必須相應的改變。
考慮到成本和時間等因素，當然不是所有的需求變化都要在軟體系統中實現。但是總的說來，軟體要適應需求的變化，以保持自己的生命力。
這就產生了一種糟糕的現象：軟體產品最初製造出來，是經過精心的設計，具有良好架構的。但是隨著時間的發展、需求的變化，必須不斷的修改原有的功能、追加新的功能，還免不了有一些缺陷需要修改。為了實現變更，不可避免的要違反最初的設計構架。經過一段時間以後，軟體的架構就千瘡百孔了。bug越來越多，越來越難維護，新的需求越來越難實現，軟體的架構對新的需求漸漸的失去支持能力，而是成為一種制約。最後新需求的開發成本會超過開發一個新的軟體的成本，這就是這個軟體系統的生命走到盡頭的時候。
重構就能夠最大限度的避免這樣一種現象。系統發展到一定階段後，使用重構的方式，不改變系統的外部功能，只對內部的結構進行重新的整理。通過重構，不斷的調整系統的結構，使系統對於需求的變更始終具有較強的適應能力。
重構可以降低項目的藕合度，使項目更加模組化，有利於項目的開發效率和後期的維護。讓項目主框架突出鮮明，給人一種思路清晰，一目了然的感覺，其實重構是對框架的一種維護。
重構目標
改進軟體設計使軟體更容易被理解
幫你找到bug
提高軟體的開發速度
重構時機
在添加新功能時進行重構。
在修改bug時進行重構。
在代碼複審時進行重構。
到了最後的交付期限，不進行重構
間接層
間接層的存在的價值：允許邏輯共享；分開解釋意圖和實現；將變化加以隔離；將條件邏輯加以編碼
但是過多的間接層會導致代碼的層次太深，使代碼難以閱讀.因些要權衡加入間接層的利弊.
重構難題
關係資料庫與面向對象編程的問題——在對象模型和資料庫模型之間插入一個分隔層，這就可以隔離兩個模型各自的變化.升級某一模型時只需同時升級上述的分隔層即可.這樣的分隔層會增加系統複雜度.但是能增加靈活度.
修改接口的問題——修改已發布的接口，因為已發布的接口會供外部人員（其它公司）使用，因此，修改接口會導致引用接口的其它程式不修改程式就無法運行.修改接口的最好的辦法是增加一個新的接口，讓舊接口調用新接口.這樣原來的程式就不用修改了.對於接口的另一個建議是儘量不要發布接口.
重構與設計
重構與設計是互補的，程式應該是先設計，而在開始編碼後,設計上的不足可以用重構來彌補.設計應該是適度的設計，而不必過度的設計.如果能很容易的通過重構來適應需求的變化，那么就不必過度的設計，當需求改變時再重構代碼.
提高性能
提高性能的三種方法：
時間預算法——在設計時就對程式花費的時間進行預算，通常用於性能要求極高的實時系統.普通的企業應用程式一般對性能要求不高.只要不太慢就可以了.
持續關注法——要求程式設計師在任何時間都要設法保持系統的高性能.這個方法有個缺陷，就是大部分的程式90%的最佳化工作都是白費勁，這樣會浪費大量的時間.
良好的分解方式——這個方式是在開發程式階段不對性能投以任何關注，直到進入性能最佳化階段，再分析程式中性能差的程式，然後對這些程式進分解，查出性能差的程式，進行最佳化.
