重構——讓你的代碼接近框架源碼

一段我們的項目搞了一次重構，我簡單做了一個 ppt，下面我們來一起分享下

代碼的壞味道

1、重複代碼（難維護）

• 提取公共函數

2、函數過長（難理解）

• 拆成若干函數

3、類過大（難理解）

• 拆成若干類

4、參數多（難用）

• 將參數封裝成結構或類

5、萬能類（改動頻繁）

• 拆，將總是一起變化的東西放在一塊兒，合久必分

6、天女散花邏輯（需求變動改很多類）

• 將各個修改點，集中起來，抽象成一個新類。

7、紅杏出牆的函數（使用了大量其他類的成員）

• 將這個函數挪到那個類裏面。

8、數據團（常一起出現的一坨數據）

• 他們那麼有基情，就在一起吧，給他們一個新的類。

9、冗餘類（如果不幹活了就幹掉他）

• 提取公共函數

10、繼承過多（父類裏面方法很多，子類只用有限幾個）

• 用代理替代繼承關係。

11、Switch 驚悚現身（從本質上說，switch 語句的問題在於重複）

• 考慮用多態替換他

12、太多註釋

避免用註釋解釋代碼，而是說明代碼的目的，背景等。好代碼會說話。

重構是軟件發展的必然：

因爲我們的軟件總是由簡單軟件向複雜軟件轉變；當軟件開始由簡單向複雜軟件轉變時我們就需要重構。

以上就是一個簡單的重構過程，重構是在日常工作不影響正常開發進度中進行的，這個需要根據我買項目的實際情況自己把握。

最後我在總結下：

1· 持續偏糾和改進軟件設計

重構和設計是相輔相成的，它和設計彼此互補。有了重構，你仍然必須做預先的設計，但是不必是最優的設計，只需要一個合理的解決方案就夠了，如果沒有重構、程序設計會逐漸腐敗變質，愈來愈像斷線的風箏，脫繮的野馬無法控制。重構其實就是整理代碼，讓所有帶着發散傾向的代碼迴歸本位。

2· 使代碼更易爲人所理解

Martin Flower 在《重構》中有一句經典的話：” 任何一個傻瓜都能寫出計算機可以理解的程序，只有寫出人類容易理解的程序纔是優秀的程序員。” 對此，筆者感觸很深，有些程序員總是能夠快速編寫出可運行的代碼，但代碼中晦澀的命名使人暈眩得需要緊握坐椅扶手，試想一個新兵到來接手這樣的代碼他會不會想當逃兵呢？

軟件的生命週期往往需要多批程序員來維護，我們往往忽略了這些後來人。爲了使代碼容易被他人理解，需要在實現軟件功能時做許多額外的事件，如清晰的排版佈局，簡明扼要的註釋，其中命名也是一個重要的方面。一個很好的辦法就是採用暗喻命名，即以對象實現的功能的依據，用形象化或擬人化的手法進行命名，一個很好的態度就是將每個代碼元素像新生兒一樣命名，也許筆者有點命名偏執狂的傾向，如能榮此雅號，將深以此爲幸。

對於那些讓人充滿迷茫感甚至誤導性的命名，需要果決地、大刀闊斧地整容，永遠不要手下留情！

3· 幫助發現隱藏的代碼缺陷

孔子說過：溫故而知新。重構代碼時逼迫你加深理解原先所寫的代碼。筆者常有寫下程序後，卻發生對自己的程序邏輯不甚理解的情景，曾爲此驚悚過，後來發現這種症狀居然是許多程序員常患的” 感冒” 當你也發生這樣的情形時，通過重構代碼可以加深對原設計的理解，發現其中的問題和隱患，構建出更好的代碼。

4· 從長遠來看，有助於提高編程效率

當你發現解決一個問題變得異常複雜時，往往不是問題本身造成的，而是你用錯了方法，拙劣的設計往往導致臃腫的編碼。

改善設計、提高可讀性、減少缺陷都是爲了穩住陣腳。良好的設計是成功的一半，停下來通過重構改進設計，或許會在當前減緩速度，但它帶來的後發優勢卻是不可低估的

作者: 程序猿的內心獨白
 來源：https://www.toutiao.com/a6584935981680427534/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ECJHJnLb0Lnbc-xRp2t27g