重構小記（重構，改善既有代碼的設計讀后總結）

我們要時時刻刻保持一顆項目要重構的心。
在非技術出身的領導看來，能用的代碼就是好代碼，只關注功能。
在工程師看來，代碼不僅要好用，更要好看，好理解，好修改。
重構就是讓你的代碼更時尚，更方便，更高效。

什么是重構

在不改變現有行為的前提下，通過改變內部結構，提高項目的可理解性和易修改性。
所以重構的目的就是使項目更容易理解和修改。

重構時機

代碼復雜（復雜到不想改了或者改不動了）
時間允許（進度驅動轉為質量驅動）
代碼潔癖（容不得一點壞味道）
項目遷移（項目交接后遷移并重構）

重構常用快捷鍵（以idea為例）

shift + F6（一鍵修改變量名，變量名不規范常用）
ctrl + F6（一鍵修改類名或方法名，也是命名不規范修改常用）
ctrl + alt + m（將選中代碼一鍵抽出成函數，過長函數常用）
ctrl + t（將選中代碼提取至各種塊中，比如if-else；try-catch等）

具體重構細節

重復代碼

重構時應該把重復代碼提煉出來，可以提煉到公共父類，或者靜態函數等地方。

過長函數

重構時應該避免過長的函數，應該盡量的將大函數分解成多個小函數，并標明每個小函數的意思。

過大的類

一個類最好不要做太多事情，也不要有太多的代碼，否則就會難以理解。

過長參數列

方法的入參如果超過5個，就試著將一些入參抽成一個對象，用對象來作為入參。

發散式變化

一個類中，如果每次修改都要設計到幾個不同的函數，那么就要考慮將這個類拆分了。
針對某一外界變化的所有相應修改，都應該只發生在單一類中。

霰彈式修改

與發散式變化相反
當發現某種變化必須在多個不同類中做許多修改，就應該把這些所有需要修改的代碼放入同一個類中。

依戀情節

將總是一起變化的東西放在一塊

數據泥團

兩個類中相同的字段，應該擁有他們自己的對象

平行繼承體系

是霰彈式修改的特殊情況
每當你為某個類怎增加一個子類，也必須為另一個類相應增加一個子類，就該重構了
一般策略是：讓一個繼承體系的實例引用另一個繼承體系的實例。

冗贅類

如果一個類的所得不值其身價，它就應該消失

夸夸其談未來性

如果一個類其實沒多大作用，只是想著以后會怎么樣怎么樣，就先把他去掉

令人迷惑的暫時字段

如果類中的某些實例變量僅為某種特殊情況而設，那么就需要把這些變量和其相關函數都提煉到一個獨立類中。

中間人

如果某個類接口有一般的函數都委托給其他類，那么就是過度調用了。這時候應該去掉委托，直接調用。

親昵關系

如果兩個類過于親密，有太多相互調用引用的地方，就必須拆散。
注意，繼承往往會造成過度親密，因為子類對父類的了解總是超過父類的主觀愿望，這時候就應該用委托代替繼承
詳細做法就是去掉原繼承，將原父類當成子類的一個屬性，用到父類的方法時去委托調用就行。

不完美的庫類

當引用的庫不能滿足我們的需求，需要擴展庫類的功能時，考慮引入本地擴展（創建子類繼承原庫中的父類或者父類委托）

被拒絕的饋贈

如果子類不需要繼承父類的所有函數和數據，這就意味著繼承體系的錯誤。這時應該去掉繼承關系，用父類委托來代替（原父類作為原子類的一個屬性）

過多的注釋

注釋應該是簡單明了，而不是為難懂的代碼擦屁股，解決這類問題，還需要從代碼提煉等方面做起，增加代碼的可讀性。

總結

以上是生活随笔為你收集整理的重构，体现一个工程师的基本素养和底蕴的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。