工作多年后，越發(fā)覺(jué)得代碼整潔真的是太重要了！尤其是在團(tuán)隊(duì)開(kāi)發(fā)中，寫(xiě)出優(yōu)雅工整的代碼，能讓同事更樂(lè)于跟你合作。

下面，將通過(guò)命名、類、函數(shù)、測(cè)試這四個(gè)章節(jié),使我們的代碼變得整潔。

1.為什么要保持代碼整潔?

不整潔的代碼隨著時(shí)間的增加而增加時(shí),生產(chǎn)力會(huì)隨之降低. 導(dǎo)致的結(jié)果就是:

代碼不易擴(kuò)展或擴(kuò)展容易引發(fā)其他問(wèn)題

程序崩潰

加班

增加公司成本(加人) 甚至可能造成公司倒閉 一圖勝千言

1.1 所以從一開(kāi)始就要保持整潔

所以在一開(kāi)始就要寫(xiě)整潔的代碼,如果有不整潔的代碼就要及時(shí)的整改. 絕對(duì)不要有以后再改,以后再說(shuō)的想法， 因?yàn)椋?/p>

laterequalnever

想想是不是這個(gè)道理,你有多少以后再說(shuō)、以后再改的東西都拋諸腦后了.

如果是一定要做的事情,那就趁早做!

1.2 如何寫(xiě)出整潔的代碼?

那么現(xiàn)在的問(wèn)題就是,怎樣的代碼才算是整潔的代碼呢:

可讀性要高: 代碼要像散文一樣優(yōu)雅易讀,見(jiàn)碼知意

拒絕重復(fù)代碼

滿足設(shè)計(jì)模式原則

單一職責(zé)

開(kāi)閉原則

里氏替換原則

依賴倒轉(zhuǎn)原則

接口隔離原則

迪米特法則

合成復(fù)用法則

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

2.命名

好的命名可提高代碼的可讀性,讓人見(jiàn)碼知意, 降低理解成本,提高效率, 減少加班.

2.1 不好的命名方式

沒(méi)有任何意義的命名方式

publicinterfaceAnimal{
voidabc();
}

現(xiàn)在我們有一個(gè)動(dòng)物的接口, 里面有一個(gè)方法abc(),看了讓人一頭霧水, 調(diào)用這個(gè)方法的人也完全不知道這個(gè)方法是干什么的,因?yàn)樗拿翢o(wú)意義

有意義的命名方式:

publicinterfaceAnimal{
voidcry();
}

我們將方法名命名為cry(喊叫,呼喊),調(diào)用的人就知道這個(gè)方法的作用是什么了.

所以命名一定要有意義且讓人見(jiàn)碼知意.

命名前后不一致 這種情況體現(xiàn)在明明是同一行為,但是卻有不同的命名,前后不一致,讓人造成混淆.

publicinterfaceStudentRepositoryextendsJpaRepository{
StudentfindOneById(
@Param("id")Stringid
);

ListqueryAllStudent(
);

}
,>

上面兩個(gè)方法都是查詢 xxx, 但是命名一會(huì)叫 query 一會(huì)叫 find,這種情況應(yīng)該加以規(guī)范,保持一致, 修改后:

publicinterfaceStudentRepositoryextendsJpaRepository{
StudentfindOneById(
@Param("id")Stringid
);

ListfindAll(
);

}
,>

命名冗余 體現(xiàn)在命名有很多沒(méi)必要的成分在里面, 并且這些"廢話"并不能幫助區(qū)分它們的區(qū)別, 例如在變量命名中添加了 Variable 這個(gè)詞, 在表名中添加了 Table 這個(gè)詞.所以命名中不要出現(xiàn)冗余的單詞 , 并且提前約定好命名的規(guī)范.

//獲取單個(gè)對(duì)象的方法用get做前綴
getXxx();
//獲取多個(gè)對(duì)象用list做前綴
listXxxx();

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

3.類

整潔的類應(yīng)滿足一下內(nèi)容:

單一職責(zé)

開(kāi)閉原則

高內(nèi)聚性

3.1單一職責(zé)

類應(yīng)該短小,類或模塊應(yīng)有且只有一條加以修改的理由 , 如果一個(gè)類過(guò)于龐大的話,那么說(shuō)明它承擔(dān)的職責(zé)過(guò)多了.

優(yōu)點(diǎn):

降低類的復(fù)雜度

提高類的可讀性

提高系統(tǒng)的可維護(hù)性

降低變更引起的風(fēng)險(xiǎn)

如何判定類是否足夠短小?

通過(guò)計(jì)算類的職責(zé)來(lái)判斷是否夠短小,類的名稱描述其全責(zé), 如果無(wú)法為某個(gè)類命以準(zhǔn)確的名稱, 這個(gè)類大概就太長(zhǎng)了, 類名越含糊,可能擁有越多的職責(zé).

職責(zé)過(guò)多的例子,可以看到以下類有兩個(gè)職責(zé):

publicabstractclassSql{
//操作SQL的職責(zé)
publicabstractvoidinsert();


//統(tǒng)計(jì)SQL操作的職責(zé)
publicabstractvoidcountInsert();

}

將統(tǒng)計(jì)的職責(zé)抽取到另一個(gè)類

publicabstractclassCountSql{

publicabstractvoidcountInsert();

}

3.2 開(kāi)閉原則

開(kāi)閉原則: 面向修改關(guān)閉, 面向擴(kuò)展開(kāi)放.

面向修改關(guān)閉意味著增加新的邏輯不會(huì)修改原有的代碼,降低了出錯(cuò)的可能性.

面向擴(kuò)展開(kāi)放則是提高了代碼的可擴(kuò)展性,可很容易的增加新的代碼邏輯.

不滿足開(kāi)閉原則的例子:

publicabstractclassSql{
publicabstractvoidinsert();
publicabstractvoidupdate();
publicabstractvoiddelete();
}

如果我們現(xiàn)在要新增查詢的操作,就需要修改Sql這個(gè)類,沒(méi)有做到面向修改關(guān)閉

重構(gòu)后:

publicabstractclassSql{
publicabstractvoidgenerate();


}

publicclassCreateSqlextendsSql{

@java.lang.Override
publicvoidgenerate(){
//省略實(shí)現(xiàn)
}
}


publicclassUpdateSqlextendsSql{

@Override
publicvoidgenerate(){
//省略實(shí)現(xiàn)
}
}

當(dāng)我們要增加刪除方法時(shí)可以很容易的擴(kuò)展.

使用大量的短小的類看似比使用少量龐大的類增加了工作量(增加了更多的類),但是真的是這樣嗎? 這里有一個(gè)很好的類比:

你是想把工具歸置到有許多抽屜、每個(gè)抽屜中裝有定義和標(biāo)記良好的組件的工具箱呢, 還是想要少數(shù)幾個(gè)能隨便把所有東西扔進(jìn)去的抽屜?

最終的結(jié)論:

系統(tǒng)應(yīng)該由許多短小的類而不是少量巨大的類組成,每個(gè)小類封裝一個(gè)權(quán)責(zé),只有一個(gè)修改的原因,并與少數(shù)其他類一起協(xié)同達(dá)成期望的系統(tǒng)行為.

3.3 內(nèi)聚

方法操作的變量越多,就越粘聚到類上. 如果一個(gè)類中的每個(gè)變量都被每個(gè)方法所使用, 則該類具有最大的內(nèi)聚性. 我們應(yīng)該將類的內(nèi)聚性保持在較高的位置. 內(nèi)聚性高意味著方法和變量互相依賴, 互相結(jié)合成一個(gè)邏輯整體.

為什么要保持高內(nèi)聚? 保持內(nèi)聚性就會(huì)得到許多短小的類,就越滿足單一職責(zé).

內(nèi)聚性低怎么辦? 如果類的內(nèi)聚性就不夠高,就將原有的類拆分為新的類和方法.

4.函數(shù)

要想讓函數(shù)變得整潔,應(yīng)保證:

只做一件事

好的命名

整潔的參數(shù)

注意返回內(nèi)容

4.1 只做一件事

what? 函數(shù)的第一規(guī)則是短小 第二規(guī)則是更短小 短小到只做一件事情. (沒(méi)錯(cuò)和類的原則很像)

why? 函數(shù)越短小,越能滿足單一職責(zé).

how? 以下是重構(gòu)前的代碼, 這個(gè)方法有三個(gè)職責(zé),并且該方法很長(zhǎng)達(dá)到了80+50+5 = 135行

publicclassPicService{

publicStringupload(){
//校驗(yàn)圖片的方法偽代碼80行

//壓縮圖片的方法偽代碼50行

//返回成功或失敗標(biāo)識(shí)0,1偽代碼5行
return"0";
}
}

原有的upload方法做了很多的事情, 重構(gòu)后只做了一件事情: 把大一些的概念(換言之,函數(shù)的名稱)拆分為另一抽象層上的一系列步驟:

publicStringupload(){
//校驗(yàn)圖片的方法
check();
//壓縮圖片的方法
compress();
//返回成功或失敗標(biāo)識(shí)0,1
return"0";
}

而里面的每個(gè)方法,也都有著自己各自的職責(zé)(校驗(yàn)圖片 、壓縮圖片 、返回結(jié)果).

4.2 函數(shù)命名

1. 函數(shù)名應(yīng)見(jiàn)名知意

函數(shù)要有描述性的名稱，不要害怕長(zhǎng)名稱.

不好的命名方式:

publicStringaddCharacter(StringoriginString,charch);

這個(gè)函數(shù)，一咋看，還不錯(cuò)，從函數(shù)字面意思看是給某個(gè)字符串添加一個(gè)字符。但是到底是在原有字符串首部添加，還是在原有字符串末尾追加呢？亦或是在某個(gè)固定位置插入呢？從函數(shù)名字完全看不出來(lái)這個(gè)函數(shù)的真正意圖，只能繼續(xù)往下讀這個(gè)函數(shù)的具體實(shí)現(xiàn)才知道。

而下面這幾個(gè)名字就比上面要好得多：

//追加到末尾
publicStringappendCharacter(StringoriginString,charch);

//插入指定位置
publicStringinsertCharacter(StringoriginString,charch,intinsertPosition);

2. 函數(shù)應(yīng)該無(wú)副作用

函數(shù)應(yīng)該無(wú)副作用， 意思就是函數(shù)應(yīng)該只做一件事，但是做這件事的時(shí)候做了另一件有副作用的事情.

例如: 校驗(yàn)密碼時(shí)會(huì)初始化 session，導(dǎo)致會(huì)話丟失。如果無(wú)法移除這種副作用，應(yīng)該在方法名中展示出來(lái)，避免用戶誤用 checkPasswordasswordAndInitializeSession, 從命名上就要體現(xiàn)副作用.

4.3 參數(shù)

1. 參數(shù)越少越好

參數(shù)越少，越容易理解，參數(shù)超過(guò)三個(gè)可以將參數(shù)進(jìn)行封裝，要按參數(shù)的語(yǔ)義進(jìn)行封裝，不一定封裝成一個(gè)大而全的參數(shù)，可以封裝為多個(gè)，原則是按語(yǔ)義補(bǔ)充; 示例:

publicListfindStudent(intage,Stringname,Stringcountry,intgender);

//封裝參數(shù)
publicListfindStudent(Studentstudent);

2. 不要使用標(biāo)識(shí)參數(shù)

標(biāo)識(shí)參數(shù)是參數(shù)為 Boolean 類型, 用戶傳遞 true or false . 不要使用標(biāo)識(shí)參數(shù)因?yàn)檫@意味著你的函數(shù)違背了單一職責(zé)(true false 兩套邏輯). 正確的做法是拆分為兩個(gè)方法:

//標(biāo)識(shí)參數(shù)方法
render(BooleanisSuite);

//重構(gòu)為兩個(gè)方法
reanderForSuite();
renderForSingleTest();

3. 不要使用輸出參數(shù)

什么是輸出參數(shù)?

將變量作為參數(shù)傳入方法,并且將變量輸出, 這就是輸出參數(shù)

publicvoidfindStudent(){
Studentstudent=newStudent();
doSomething(student);
returnstudent;
}

intdoSomething(Studentstudent){
//省略一些student邏輯
returnstudent;
}

為什么不應(yīng)該有輸出參數(shù)?

因?yàn)樵黾恿死斫獬杀驹诶锩?我們需要查看 doSomething到底對(duì) student 做了什么. student 是輸入還是輸出參數(shù)? 都不明確.

重構(gòu):

//將doSomething()方法內(nèi)聚到student對(duì)象本身
student.doSomething();

4.4 返回值

1. 分離指令與訊問(wèn)

示例代碼:

PulicBooleanaddElement(Elementelement)

指令為增加某個(gè)元素,詢問(wèn)是否成功,

這樣做的壞處是職責(zé)不單一，所以應(yīng)該拆分為兩個(gè)方法

publicvoidaddElement(Elementelement);
publicBooleanisAdd(Elementelement);

2. 使用異常替代返回錯(cuò)誤碼

直接拋出異常,而不是返回錯(cuò)誤碼進(jìn)行判斷, 可以使代碼更簡(jiǎn)潔. 因?yàn)槭褂缅e(cuò)誤碼有可能會(huì)進(jìn)行多層嵌套片段 代碼示例:

//使用錯(cuò)誤碼導(dǎo)致多層嵌套...
publicclassDeviceController{

publicvoidsendShutDown(){
DeviceHandlehandle=getHandle(DEV1);
//Checkthestateofthedevice
if(handle!=DeviceHandle.INVALID){
//Savethedevicestatustotherecordfield
retrieveDeviceRecord(handle);
//Ifnatsuspended,shutdown
if(record.getStatus()!=DEVICE_SUSPENDED){
pauseDevice(handle);
clearDeviceWorkQueue(handle);
closeDevice(handle);
}else{
logger.log("Devicesuspended.Unabletoshutdown");
}
}else{
logger.log("Invalidhandlefor:"+DEV1.tostring());
}
}

重構(gòu)后:

//將代碼拆分為一小段一小段,降低復(fù)雜度,更加清晰
publicclassDeviceController{

publicvoidsendShutDowm(){
try{
tryToShutDown();
}catch(DeviceShutDownErrore){
logger.log(e);
}

privatevoidtryToShutDown()throwsDeviceShutDownError{
DeviceHandlehandle=getHandle(DEV1);
retrieveDeviceRecord(handle);
pauseDevice(handle);
clearDeviceWorkQueue(handle);
closeDevice(handle);
}

privateDeviceHandlegetHandle(DeviceIDid){
//省略業(yè)務(wù)邏輯
thrownewDeviceShutDownError("Invalidhandlefor:"+id.tostring());
}
}

4.5 怎樣寫(xiě)出這樣的函數(shù)?

沒(méi)人能一開(kāi)始就寫(xiě)出完美的代碼, 先寫(xiě)出滿足功能的代碼,之后緊接著進(jìn)行重構(gòu)

為什么是緊接著? 因?yàn)?later equal never!

4.6 代碼質(zhì)量掃描工具

使用 SonarLint 可以幫助我們發(fā)現(xiàn)代碼的問(wèn)題,并且還提供了相應(yīng)的解決方案. 對(duì)于每一個(gè)問(wèn)題，SonarLint 都給出了示例，還有相應(yīng)的解決方案，教我們?cè)趺葱薷模瑯O大的方便了我們的開(kāi)發(fā)

比如，對(duì)于日期類型盡量用 LocalDate、LocalTime、LocalDateTime，還有重復(fù)代碼、潛在的空指針異常、循環(huán)嵌套等等問(wèn)題。

有了代碼規(guī)范與質(zhì)量檢測(cè)工具以后，很多東西就可以量化了，比如 bug 率、代碼重復(fù)率等.

5.測(cè)試

測(cè)試很重要,可以幫助我們驗(yàn)證寫(xiě)的代碼是否沒(méi)問(wèn)題,同樣的測(cè)試代碼也應(yīng)該保持整潔.

5.1 TDD

TDD 是測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（Test-Driven Development），是敏捷開(kāi)發(fā)中的一項(xiàng)核心實(shí)踐和技術(shù)，也是一種設(shè)計(jì)方法論。

優(yōu)點(diǎn)：在任意一個(gè)開(kāi)發(fā)節(jié)點(diǎn)都可以拿出一個(gè)可以使用，含少量bug并具一定功能和能夠發(fā)布的產(chǎn)品。

缺點(diǎn)：增加代碼量。測(cè)試代碼是系統(tǒng)代碼的兩倍或更多，但是同時(shí)節(jié)省了調(diào)試程序及挑錯(cuò)時(shí)間。

how?

在開(kāi)發(fā)代碼前先寫(xiě)測(cè)試

只可編寫(xiě)剛好無(wú)法通過(guò)的單元測(cè)試，不能編譯也算不通過(guò)

開(kāi)發(fā)代碼不可超過(guò)測(cè)試

關(guān)于2的解釋: 單測(cè)與生產(chǎn)代碼同步進(jìn)行，寫(xiě)到一個(gè)不可編譯的單測(cè)就開(kāi)始寫(xiě)生產(chǎn)代碼，如此反復(fù)循環(huán)，單測(cè)就能包含到所有生產(chǎn)代碼。

5.2 FIRST原則

FIRST 原則就是一個(gè)指導(dǎo)編寫(xiě)單元測(cè)試的原則

fast 快速 單測(cè)執(zhí)行應(yīng)該快速的完成

independent 獨(dú)立 單測(cè)之間相互獨(dú)立

repeatable 可重復(fù) 單測(cè)不依賴于環(huán)境，隨處可運(yùn)行

self validating 程序可通過(guò)輸出的Boolean自我驗(yàn)證，而不需要通過(guò)人工的方式驗(yàn)證（看日志輸出、對(duì)比兩個(gè)文件不同等）

timely 及時(shí) 單測(cè)在生產(chǎn)代碼之前編寫(xiě)

單元測(cè)試是代碼測(cè)試中的基礎(chǔ)測(cè)試，F(xiàn)IRST 是寫(xiě)好單元測(cè)試的重要原則，它要求我們的單元測(cè)試快速，獨(dú)立，可重復(fù)，自我校驗(yàn)，及時(shí)/完整。

5.3 測(cè)試代碼模式

開(kāi)發(fā)測(cè)試代碼可以使用 given-when-then 模式

given 制造模擬數(shù)據(jù)

when 執(zhí)行測(cè)試代碼

then 驗(yàn)證測(cè)試結(jié)果

代碼示例

/**
*Ifanitemisloadedfromtherepository,thenameofthatitemshould
*betransformedintouppercase.
*/
@Test
publicvoidshouldReturnItemNameInUpperCase(){

//Given
ItemmockedItem=newItem("it1","Item1","Thisisitem1",2000,true);
when(itemRepository.findById("it1")).thenReturn(mockedItem);

//When
Stringresult=itemService.getItemNameUpperCase("it1");

//Then
verify(itemRepository,times(1)).findById("it1");
assertThat(result,is("ITEM1"));
}

使用give-when-then 模式可提高測(cè)試代碼的可讀性.

5.4 自動(dòng)生成單測(cè)

介紹兩款 IDEA 自動(dòng)生成單測(cè)的插件

Squaretest 插件（收費(fèi)）

TestMe 插件(免費(fèi))

6.結(jié)束語(yǔ)

編寫(xiě)整潔的代碼可以讓我們 提高代碼的可讀性,使代碼變得更易擴(kuò)展。

審核編輯：劉清