重構改善代碼--代碼的壞味道

     關於重構的重要目標之一，即是讓代碼更容易讓人閱讀和理解。其實，代碼的好與壞在必定程度上是如出一轍的，至少對計算機而言，能正常工做的代碼都不算太壞。可是，代碼也必須能讓其餘人看懂碼農的思想世界，這纔是重構存在的意義了。可是，重構的時機把握遠比理解重構的意義重要的多。下面簡單說明下，重構的時機問題。

　　1、重複代碼結構或語句塊，儘可能抽取成獨立的模塊，類或函數都可；

　　2、過長的函數，儘可能將函數縮小，減少中間變量，局部變量、參數等變量；須要特別註釋的代碼儘可能函數模塊化，積極分解函數，並儘可能爲函數取一個顧名思義的好名稱也很重要；條件表達式和循環部分也能夠提煉成函數；

　　3、過大的類，函數功能過於複雜，不便於理解和使用；變量多，代碼多，邏輯複雜；

　　4、參數列表過長，參數容易被遺漏；

　　5、發散式變化的代碼，若是需求改變，須要修改多類代碼，每每須要將代碼的改變集中在一處或類中，主要是一個類受多種變化的影響；

　　6、代碼的一處改變，須要修改多個類中的代碼，主要是一種變化引起多個類相應修改；

　　7、對象技術的要點是：將數據和對數據的操做包裝在一塊兒的編程技術，若是一個類中的方法使用其餘類中的數據比使用所在類中的數據更多，說明方法須要移動到相應的類中更加合理，這就是依戀情結；

　　8、數據泥團：數據項也喜歡扎墩兒，若是許多類中出現相同的數據項，能夠考慮雷同的數據項提煉成一個類處理；

　　9、基本類型偏執：編程環境中，通常都有基本類型和符合類型，若是符合類型數據用的地方夠多，最好提煉成類使用更方便；

　　10、switch現身的地方：凡是出現switch的地方，基本會出現較多判斷的場合，能夠將其提煉成函數；

　　11、平行繼承體系：當爲一個類增長一個子類時，必須爲另外一個類增長子類時，須要重構了；

　　12、冗餘類：若是一個類的投入比產值還多，就須要被K掉了；

　　十3、過多的規劃代碼：預備的處理方式或變量歷來沒有用過，刪除；抽象類使用不足，能夠變成具體類；類的做用只是用來測試，刪除；

　　十4、使人眼花繚亂的字段：只爲特定做用的變量；使用狀況很少的多個字段，能夠將其提煉成一個類；

　　十5、耦合過分的調用鏈：若是一個調用A時調用B，B調用C，C調用D，D調用E，最後使用E提供的數據，存在耦合過分；

　　十6、委託過分：一個封裝好的類中若是大部分函數都和外面代碼有關聯就是委託過分；

　　十7、狎暱關係：若是類中的私有成員常被其餘類惦記，說明須要重構了；

　　十8、殊途同歸：若是兩個函數簽名不同，作着一樣的事情，須要重構；

　　十9、類庫的不完美：面向對象的最終目標是代碼複用，而類庫是最直接的展示形式，若是隻是須要添加類庫的個別功能，能夠自行處理，不然須要重構類庫；

　　二10、純粹的數據類：只包含有基本的數據和對數據的基本訪問的類，這些類應儘可能隱藏；

　　二11、應用拒絕：子類在繼承父類的數據成員和函數成員時，不須要全部的成員時，須要改進繼承的套路；

　　二12、過多的註釋：若是代碼須要大段的代碼註釋，每每不如直接用簡單的代碼實現效果更好；

　　

編程終極法則：事不過三，三則重構。是說第一次作某件事時儘管放心去作；第二次作某件相似的事時，會產生好感，不管如何還能夠去作；第三次再重作某件相似的事時，就應該重構。重構的時機，嚴格來講，重構應該是隨時隨地的才行，非要說具體的時機：添加功能時重構；修補錯誤時重構；複審代碼時重構；就足夠了。