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