建站
咨詢
售后
建站咨詢
新聞中心
shenfq 本文轉載自微信公眾號「愛笑的架構師」，作者雷架。轉載本文請聯系愛笑的架構師公眾號。
創(chuàng)新互聯建站為客戶提供專業(yè)的成都網站建設、做網站、程序、域名、空間一條龍服務，提供基于WEB的系統開發(fā). 服務項目涵蓋了網頁設計、網站程序開發(fā)、WEB系統開發(fā)、微信二次開發(fā)、移動網站建設等網站方面業(yè)務。
Martin Fowler：任何一個傻瓜都能寫出計算機可以理解的代碼。唯有寫出人類容易理解的代碼，才是優(yōu)秀的程序員。
大家閉著眼睛想一下什么是好代碼?也許你的腦海中漂浮著一堆詞：干凈、整潔、命名規(guī)范、注釋合理、高內聚低耦合……
人人都想寫好代碼，因為看好代碼就如同看一位五官端正的女子，心情愉悅、舒暢，而看糟糕的代碼就如同看見腐爛的食物，聞起來也有一股壞味道。
大多數人寫的代碼都不能稱之為好代碼，一方面由于自己技能限制，另一方面也可能根本就分不清好代碼和壞代碼，下面筆者結合日常編碼實踐與大家分享一下常見的代碼壞味道。
壞味道：Long Method(過長函數)
過長函數簡而言之就是函數長度超標了，包括橫向和縱向。
為什么過長函數是一種壞味道?
橫向過長會導致無法一眼就能看出這行代碼的作用，需要用鼠標慢慢往后邊拖，相信用小屏幕的小伙伴經常會遇到這個問題，拖動的過程會嚴重影響讀代碼的效率。
縱向過長其實就是出現了大函數，一個函數的行太多，使得函數難以讀懂，代碼修改難度大。
那么如何解決過長函數問題呢?
關于橫向過長的問題，一般會在 IDE 中提前配置好最大寬度，比如80字符或者120字符(具體根據公司內部規(guī)范設置)，然后格式化代碼即可解決。
比如我們在寫 Java8 stream 鏈式表達式的時候可以會很長：
- List
nodes = list.stream().filter().filter().map.filter().collect(Collectors.toList()); // 可能會非常長
其實我們可以在.之前換行，這樣看起來一目了然。
- List
nodes = list.stream() - .filter()
- .filter()
- .map
- .filter()
- .collect(Collectors.toList());
關于縱向過長的問題其實就是這個方法或者函數職責不夠單一，一個函數中堆積太多功能。
重構的手段很簡單：Extract Method，積極抽取函數或方法，隱藏細節(jié)保持職責單一。
壞味道：Large Class(過大的類)
過大的類也常常被成為上帝類(God Class)，上帝類一般是指維護了太多功能(違反單一職責原則)，連上帝也看不懂你的代碼。
知識小百科
設計模式的六大原則有：
Single Responsibility Principle：單一職責原則
Open Closed Principle：開閉原則
Liskov Substitution Principle：里氏替換原則
Law of Demeter：迪米特法則
Interface Segregation Principle：接口隔離原則
Dependence Inversion Principle：依賴倒置原則
六個原則的首字母聯合起來就是 SOLID，兩個 L 當成一個。
那如何判斷一個類是不是上帝類呢?
一般一個類同時滿足以下3個條件就是上帝類：
(1)CPFD (Capsules Providing Foreign Data) 從多個不相關類(模塊)中引用數據。
(2)WOC (Weighted Operation Count) 類的所有函數的圈復雜度之和超過65。
(3)TCC (Tight Capsule Cohesion) TCC < 1/3 類需要具有低內聚的特性(類中直接相關的方法與全部方法之比小于1/3)，也就是較少的private方法。
為什么過大的類是一種壞味道?
過大的類承擔了過多的職責，往往有很多重復代碼，并且這些重復代碼你還不容易發(fā)現，這基本就是壞味道的開始。
過大的類被子類繼承會導致其他壞味道，比如遺留的饋贈。
如何解決過大的類這種問題呢?
通過觀察這個過大類的屬性，看有沒有一些屬性有關聯，如果有可以使用 Extract Class 將這些關聯屬性抽象到一個新類中，并將與這些屬性相關的操作都 Move 到新的類中。
通過觀察這個過大類的方法，看有沒有一些函數或方法存在兄弟關聯，如果有可以使用 Extract Subclass(提煉子類)的手段將這些方法提煉到子類中，子類可以繼承父類。將相似的行為方法聚集在一個類中拆分到多個類中，可以進一步將發(fā)放調用解耦開。
以上方法循環(huán)往復，一個大類就可以拆分為多個小的且職責單一的類。
壞味道：Duplicated Code(重復代碼)
Robert C.Martin：重復可能是軟件中一切邪惡的根源。
重復代碼一般是由于復制粘貼造成的。需求迭代過程中為了不影響已有功能，通常是將之前的代碼copy一份改改，然后匆匆上線。
那為什么重復的代碼是一種壞味道呢?
最直接的弊端就是如果你想修改一段代碼邏輯，可能會遺漏，甚至需要多次修改才能確保全部修改完。
如何解決重復代碼的問題?
下面結合代碼實踐分幾個場景分別描述。
場景1：同一個類中兩個方法含有相同的表達式
- class A {
- public void method1() {
- logic1
- logic2
- logic3
- }
- public void method2() {
- logic1
- logic2
- logic4
- }
- }
重構手段：將兩個方法共同的邏輯抽象出來。重構后：
- class A {
- public void method1() {
- baseMethod();
- logic3
- }
- public void method2() {
- baseMethod();
- logic4
- }
- public void baseMethod() {
- logic1
- logic2
- }
- }
場景2：兩個具有相同父類的子類內含有相同的表達式類 A 中有一個 method1，有三段邏輯。
- class A extend Base {
- public void method1() {
- logic1
- logic2
- logic3
- }
- }
類 B 中有一個 method2，也有三段邏輯。
- class B extend Base {
- public void method2() {
- logic1
- logic2
- logic3
- }
- }
重構手段：將重復代碼抽象成一個方法放在父類中，差異部分由子類各自實現。
重構后：
- class Base {
- public void baseMethod() {
- logic1
- logic2
- }
- }
- class A extend Base {
- public void method1() {
- baseMethod();
- logic3
- }
- }
- class B extend Base {
- public void method2() {
- baseMethod();
- logic3
- }
- }
場景3：兩個毫無相關的類出現重復代碼
如果兩個沒有直接關聯的類出現重復代碼，可以考慮將重復的代碼抽象到一個獨立的普通類或者工具類中，適用方可以使用組合的方式調用。
代碼樣例這里不再贅述，與場景1和2大同小異，相信聰明的你一定能明白。
壞味道：Long Parameter List(過長參數列)
全局變量是個邪惡的東西，數據是共享的并且每個線程都可以修改，太多了容易導致程序不可控，所以大家喜歡將變量以行參的方式傳遞，久而久之參數列越來越長了。
為什么過長參數列是一種壞味道?
方法參數的數量太多會導致代碼可讀性非常差，如果有多個重載方法它們的方法參數都非常多，在寫代碼時很難判斷該調用哪一個。
當一個方法需要新增功能，每次都可能會新增一個方法參數，這樣導致調用方每次都要重新適配，小心被打哦，耗子尾汁。
如何解決過長參數列這種壞味道?
可以將多個參數封裝到一個 DTO 對象中，方法間的對象通過對象的傳輸而不是過長的參數。
數據傳輸對象(DTO)(Data Transfer Object)，是一種設計模式之間傳輸數據的軟件應用系統。
特別需要提醒的是有些情況下長參數也是合理的，因為使用參數可以避免某些依賴關系的產生。在編碼實踐中我們可以通過觀察長參數的方法，如果這個方法經常變動那你就要考慮重構這個方法了?；驹瓌t：事不過三，過三重構。
壞味道：Shotgun Surgery(散彈式修改)
為什么散彈式修改是一種代碼壞味道?
如果需要修改某個小功能，你需要在眾多不同的類中做修改，首先很難找全，其次很可能會遺漏，這種問題一般稱之為散彈式修改。
- public class A {
- @Value("${db.mysql.url}")
- private String mysqlDbUrl;
- }
- public class B {
- @Value("${db.mysql.url}")
- private String mysqlDbUrl;
- }
假如有多個類都使用了db.mysql.url這個變量，如果后面要將 mysql 切到 Oracle，那么可能會涉及到多處修改。如何解決散彈式修改這種代碼壞味道呢?
可以使用 Move Method (搬移函數)和 Move Field (搬移字段)把所有需要修改的代碼放進同1個類，如果暫時沒有合適的類，就創(chuàng)建一個。
壞味道：Speculative Generality(夸夸其談未來性)
在工作中經常會聽到有開發(fā)小伙伴說：昨天加班我將訂單模塊做了修改，未來可以……
聽到這里你可以會鼓掌：牛叉啊，提前對功能模板預留了擴展性。但是不要急于故障，你看技術總監(jiān)的臉黑著呢，為什么呢?這位小伙伴的代碼可能是一種壞味道：夸夸其談未來性。
為什么夸夸其談未來性是一種代碼壞味道?
互聯網需求迭代更新速度快，”未來可以“意味著當下并不需要，有時候過度的抽象和預留擴展也會讓系統難以理解，并且可能提前背上包袱往前走。
代碼上總是談未來可能性，會讓團隊陷入泥沼。每次有業(yè)務變動，開發(fā)人員都會考慮各種未來可能性，預留足夠多的擴展接口，這無疑極大增加了代碼復雜度，讓一個可能快速上線的需求變得慢下來。
如何解決夸夸其談未來性這種代碼壞味道呢?
在代碼架構設計中有一個原則叫：Simple Design (簡單設計原則)。
當實現當下業(yè)務代碼時需要考慮四個原則：通過測試、揭示意圖、消除重復、最少元素。
當需要為未來而寫的代碼時，可以干這些：
(1)刪除那些覺的未來有用的參數、代碼、方法調用。
(2)修正方法名，使方法名揭示當下業(yè)務場景的意圖，避免抽象的技術描述詞。
如果代碼的改動確實是未來必然會發(fā)現的，那么還是建議保留。夸夸其談未來性更多是指開發(fā)人員無依據臆測未來，導致代碼模塊被過度設計。
壞味道：Comments(過多的注釋)
在 《Clean Code》 中列舉了一些常見注釋壞味道：
- 喃喃自語
- 多余的注釋
- 誤導性注釋
- 循規(guī)方注釋
- 日志式注釋
- 廢話注釋
- 用注釋來解釋變量意思
- 用來標記位置的注釋
- 類的歸屬的注釋
- 注釋掉的代碼
為什么過多的注釋是一種代碼壞味道呢?
好的注釋可以輔助開發(fā)人員快速閱讀理解代碼，過多的注釋或壞注釋可能會降低代碼的可讀性。
在開發(fā)實踐中經常有同學修改了代碼但是注釋沒有同步修改，代碼的實現已經與注釋內容不一致，容易產生誤導。
如何解決過多的注釋這種壞味道呢?
(1)如果代碼塊不再使用請直接刪除不要使用注釋。
(2)方法、變量的命名盡量見名知意，避免用注釋再解釋一遍。
(3)如果較短的注釋不能覆蓋方法的含義，可能是這個方法職責不單一，可以考慮重構這個方法。
總結：
文章列舉了幾種比較常見的代碼壞味道，希望大家在工作編碼中多多練習，爭取人人都能寫出好代碼，讓天下沒有難讀的代碼。
本文標題：講點碼德！避免這些代碼壞味道，努力做一名優(yōu)秀的程序員
URL地址：http://m.5511xx.com/article/dhpsphh.html
