重構原則

• 何謂重構

重構的兩種定義，一種名詞形式，一種是動詞形式：
重構（名詞）：對軟件內部結構的一種調整，目的是在不改變軟件之可察行爲前提下，提升其可理解性，下降其修改爲本。
重構（動詞）：使用一系列重構準則（手法），在不改變軟件之可察行爲前提下，調整其結構。

重構不只僅是整理代碼，它提供了一種更高效且受控的代碼整理技術。

兩頂帽子：‘添加新功能’和‘重構’，在軟件開發過程當中，你可能會發現本身常常變換帽子，但不管什麼時候你都應該清楚本身戴的是哪一頂帽子。

個人理解：重構是種約束性的軟件結構調整行爲，它有一系列準則，其約束性是不改變軟件之可察行爲。

• 爲什麼重構？

重構改進軟件設計；

能夠改善腐敗變質的程序，你所做的就是讓全部東西回到應該的位置上；
消除重複代碼，你能夠肯定代碼將全部事物和行爲都只表述一次，惟一一次，這正是優秀設計的根本。

重構使軟件更易被理解；

編程模式的核心就是「準確說出吾人所欲」。

重構助你找到臭蟲；

搞清楚程序結構的同時，也清楚了所作的一些假設，從這個角度說，不找到臭蟲都難矣。

重構助你提升編程速度；

重構可提升軟件質量（改善設計、提高可讀性、減小錯誤），良好設計是快速軟件開發的根本。

個人理解：這四點重構的緣由，都可歸結到重構可維持良好設計這一點上，重構是方法準則，良好設計是重構的結果，這四點是良好設計需具有的條件。

• 什麼時候重構

重構原本就不是一件特別撥出時間作的事情，重構應該隨時隨地進行。

三次法則：

添加功能時一併重構；
修補錯誤時一併重構；
複審代碼時一併重構；
爲何重構有用？
程序有兩面價值：‘今天能夠爲你作什麼’和‘明天能夠爲你作什麼’。
對於今天的工做，我瞭解的很充分；對於明天的工做，我瞭解的不夠充分。但若是我純粹只是爲今天的工做，明天我將徹底沒法工做。

程序爲何如此難與的四個緣由：

難以閱讀的程序，難以修改；
邏輯重複的程序，難以修改；
添加新行爲時須要修改既有代碼者，難以修改；
帶複雜條件邏輯的程序，難以修改；
所以，咱們但願程序：

容易閱讀；
全部邏輯都只在惟一地點制定；
新的改動不會危及現有行爲；
儘量簡單表達條件邏輯。
重構是這樣一個過程：它在一個目前運行的程序上進行，企圖在不改變程序行爲的狀況下賦予上述美好性質，是咱們可以繼續保持告訴開發。

• 怎麼對經理說？

經理的角度：常常嘴巴上說本身是‘質量驅動’，其實更多的是‘進度驅動’。對於這種狀況，做者則給了一個較有爭議的建議：不要告訴經理。

個人理解：若是知足2.3的三次法則，重構行爲隨時隨地進行，重構習慣融入到程序開發、修改、複審環節中，彷佛重構與否的問題沒有理由讓經理來面對，可是那只是理想狀態，咱們有時不得不單獨拿出時間來進行重構工做，因此這時候就作你認爲該作的。

• 重構的難題

數據庫程序難以重構的兩個方面：

程序與它們背後的數據表格結構緊密耦合，難以修改；
數據遷移。
解決方法程序與數據表耦合的方案：在對象模型和數據庫模型之間插入一個分隔層，這就能夠隔離兩個模型各自的變化，升級某一個模型時無需同時升級另外一模型，只需升級上述的分隔層。這樣分隔層會增長系統複雜度，但能夠給你很大的靈活度。無需一開始就插入分隔層，能夠在發現對象模型變得不穩定時再產生它。

解決數據遷移的方案：

對象數據庫提供不一樣版本的對象之間的自動遷移功能；
無自動功能，在數據還沒有被轉移錢先運用訪問函數形成數據已轉移的假象，一旦肯定知道數據應該在何處時，就能夠一次性地將數據遷移過去，這時惟一須要修改的只有訪問函數。
重構了修改了已發佈接口的解決方案：

讓就接口調用新接口，當你要修改某個函數名稱時，請留下就函數，讓他調用新函數。千萬不要拷貝函數實現碼，那會讓你陷入重複代碼的泥沼中難以自拔；
除非真有必要，不要發佈接口，團隊內改變代碼擁有權觀念，讓每一個人均可以修改別人的代碼。
總結：不要過早發佈接口。請修改你的代碼擁有全政策，使重構更順暢。

• 什麼時候不應重構？

既有代碼是在太混亂，重構它還不如從新寫一個來得簡單；
現有代碼根本不能正常運做；
若是項目已近最後期限，你也應該避免重構。
文中經典比喻：把重構工做比作成債務，把過於複雜的代碼形成的‘維護和擴展的額外開銷’比做成要付的利息，你能夠承受必定程度的利息，但若是利息過高你就會被壓垮，你應該隨時經過重構來償還一部分債務。

• 重構與設計

重構能夠成爲預先設計的替代品，極限編程的支持者提倡這種方法，但只運用重構也能收到效果，但不是最有效途徑，xp愛好者也會進行預先設計，使用crc卡相似的東西檢驗想法，而後獲得一個可被接受的方案，而後開始編碼，而後才能重構。

重構改變了預先設計的角色，沒必要保證預先設計的準確無誤，只須要獲得一個足夠合理的解決方案就夠了。

• 重構與性能

編寫快速軟件的祕密就是首先寫出可調軟件，而後調整它以得到足夠速度。

編寫快速軟件的三種方法：

時間預算法——這一般只用於性能要求極高的實時系統。若是使用這種方法，分解你的設計時就要作好預算，給每一個組件預先分配必定資源，包括時間和執行軌跡。每一個組件絕對不能超出本身的預算，就算擁有可在不一樣組件之間調度預配時間的機制也不行；
持續關切法——這種方法要求程序員在任什麼時候間作任何事時，都要設法保持系統的高性能；
90%統計數據——以一種良好的分解方式來建造本身的程序,不對性能投以任何關切，直至進入性能優化階段，進入該階段再按照某個特定程序來調整程序性能。
性能優化階段的優化過程：首先應該以一個量測工具監控程序的運行，由它得知程序大量消耗時間和空間的位置，這樣能夠找出性能熱點（hot spot）所在的一小段代碼，對該性能熱點，使用持續關切法中的優化手段。應該小幅度進行修改，每走一步都須要編譯、測試、再次量測。若是沒有調高性能，你應該繼續這個「發現熱點、去除熱點」的過程。

一個被良好分解的程序可從兩方面幫助此種優化形式：

它讓你有比較充裕的時間進行性能調整；
它讓你在進行性能分析時便有較細的粒度。

轉自：http://www.cnblogs.com/blueclue/archive/2010/06/01/1749308.html