代碼混亂的常見(jiàn)問(wèn)題

很多時(shí)候我們項(xiàng)目迭代到后期，項(xiàng)目會(huì)變得很混亂，往往只有少數(shù)人能知道某段代碼是干嘛的和該如何去改，或者是干脆誰(shuí)都不知道，只能靠通過(guò)注釋去猜測(cè)這段代碼可能的作用。原因有可能是因?yàn)閳F(tuán)隊(duì)內(nèi)部的人事變動(dòng)，導(dǎo)致原先寫(xiě)這段代碼的人不再管理這段代碼了，并且代碼寫(xiě)的實(shí)在是屎沒(méi)人捋的清。往往我們稱(chēng)這類(lèi)代碼為“祖?zhèn)鞔a”，就像祖宗傳下來(lái)的代碼一樣，沒(méi)人懂沒(méi)人敢動(dòng)。祖?zhèn)鞔a一多，這個(gè)項(xiàng)目就變成了屎一樣，開(kāi)發(fā)人員在這基礎(chǔ)上迭代就如同屎海翻騰，惡心別人也惡心自己。這是一個(gè)很可怕的惡性循環(huán)，我們?nèi)绾稳ケ苊膺@種事情發(fā)生呢？先讓我們分析下這類(lèi)代碼的通病

代碼又臭又長(zhǎng)

我見(jiàn)過(guò)最長(zhǎng)的方法是5000多行，那段代碼沒(méi)人敢動(dòng)，只敢往下加 if else，每次需要改這段代碼的開(kāi)發(fā)都戰(zhàn)戰(zhàn)兢兢，生怕出現(xiàn)什么莫名其妙的bug。java 可是一門(mén)面向?qū)ο蟮恼Z(yǔ)言，一個(gè)方法里面有5000多行可以說(shuō)是很可惡的事情了。我想一開(kāi)始代碼長(zhǎng)度可能沒(méi)這么夸張，是什么導(dǎo)致這種結(jié)果的？一個(gè)是當(dāng)初寫(xiě)這段代碼的人本身寫(xiě)的是直來(lái)直去的方法，一堆if else ；后面迭代的開(kāi)發(fā)，面對(duì)這么長(zhǎng)的代碼瞬間失去了從頭讀到尾的耐心，直接繼續(xù)在后面加 if else 迭代，最后這個(gè)方法就變成了一個(gè)縫合怪一樣的玩意。

好的 sql 可以很大程度上簡(jiǎn)化代碼的復(fù)雜程度，但是太過(guò)復(fù)雜sql 本身就會(huì)給后來(lái)的開(kāi)發(fā)人員造成閱讀困難，結(jié)果又是變成一條無(wú)人敢動(dòng)的祖?zhèn)鞔a，我想這應(yīng)該是不少公司極度抵制存儲(chǔ)過(guò)程的原因之一。當(dāng)然不少銀行應(yīng)用開(kāi)發(fā)還是大量使用存儲(chǔ)過(guò)程，存儲(chǔ)過(guò)程有用武之地的，但是一個(gè)又臭又長(zhǎng)的存儲(chǔ)過(guò)程就等著變成祖?zhèn)鞔a吧。當(dāng)年我見(jiàn)到一個(gè)60多個(gè)join的sql，看到第一眼就驚為天人從此難以忘懷，當(dāng)然那段sql也成了沒(méi)人敢去動(dòng)的代碼了。

代碼邏輯不明

代碼邏輯不明所以是我們開(kāi)發(fā)很容易去犯的毛病，是一個(gè)不致命卻煩人的毛病。在代碼上的體現(xiàn)是，邏輯判斷寫(xiě)的比較反人類(lèi)各種雙重否定是肯定，不把你繞暈不罷休?；蛘呤菍?xiě)起代碼來(lái)東一榔頭西一棒槌，讓人不知道你想干嘛。導(dǎo)致這個(gè)的原因有可能是開(kāi)發(fā)人員在需求理解上出現(xiàn)偏差，做到后面發(fā)現(xiàn)不對(duì)勁，再回去改又不大可能了，只能硬著頭皮往下寫(xiě)，結(jié)果就是代碼彎彎繞繞；還有很重要的鍋是在產(chǎn)品經(jīng)理，任意變更需求，想一出是一出，開(kāi)發(fā)人員無(wú)奈只能跟著想一出寫(xiě)一出。還用可能是開(kāi)發(fā)人員方法或者類(lèi)命名太藝術(shù)了，什么四川方言拼音這種沒(méi)有十年腦血栓想不出的命名咱就不說(shuō)了。就說(shuō)那種國(guó)產(chǎn)凌凌漆式的無(wú)厘頭命名——這看上去是個(gè)刮胡刀實(shí)際上是個(gè)吹風(fēng)機(jī)，就這種不知道讓人說(shuō)什么好。

規(guī)劃代碼的核心思想

吐槽了一堆代碼規(guī)范問(wèn)題，接下來(lái)我們說(shuō)說(shuō)如何去規(guī)范我們的代碼以及如何做到就算開(kāi)發(fā)人員更換了，或者項(xiàng)目轉(zhuǎn)手給他人了，仍然可以讓后面的開(kāi)發(fā)可以無(wú)礙的去閱讀代碼修改代碼。當(dāng)然各個(gè)公司/團(tuán)隊(duì)都有自己的一套代碼規(guī)范，比如項(xiàng)目的結(jié)構(gòu)、代碼命名風(fēng)格、代碼格式等等。不同團(tuán)隊(duì)有不同的風(fēng)格，但核心思想是大同小異的。接下來(lái)我就我個(gè)人的開(kāi)發(fā)經(jīng)驗(yàn)來(lái)分享一下一些代碼規(guī)范的思想。

花葉論

就我個(gè)人而言，這個(gè)理解是我代碼規(guī)范中最淺顯也是最核心的思想，只要稍微動(dòng)動(dòng)腦子就能想出這個(gè)思路出來(lái)?；蛟S我們做業(yè)務(wù)開(kāi)發(fā)的時(shí)候，大部分都在寫(xiě)crud，感覺(jué)似乎這部分代碼沒(méi)什么規(guī)范好說(shuō)的，其實(shí)不然。對(duì)一段業(yè)務(wù)代碼而言，我們可以將其分為四類(lèi)：

數(shù)據(jù)校驗(yàn)

業(yè)務(wù)邏輯

數(shù)據(jù)轉(zhuǎn)換

數(shù)據(jù)庫(kù)交互（查詢(xún)與持久化）

大部分時(shí)候我們最關(guān)心的是邏輯判斷相關(guān)的代碼，其次是數(shù)據(jù)庫(kù)交互，對(duì)于遠(yuǎn)程調(diào)用的方法，我們就視其為一個(gè)普通的方法以簡(jiǎn)化模型，方法調(diào)用算業(yè)務(wù)邏輯部分的代碼，對(duì)于讀代碼的人而言基本上不關(guān)心數(shù)據(jù)校驗(yàn)和數(shù)據(jù)的轉(zhuǎn)換（DTO轉(zhuǎn)VO等）。因此，代碼應(yīng)該分出一個(gè)主次，應(yīng)該盡量把主邏輯給凸顯出來(lái)，最好一眼看去就能讓人明白這個(gè)方法或者這個(gè)類(lèi)干了啥，步驟是什么樣的。對(duì)于那些不重要但必要的代碼我稱(chēng)其為葉，對(duì)于那些主要的代碼我稱(chēng)其為花。葉是為了襯托花的，因此我們應(yīng)該將那些葉子代碼精簡(jiǎn)或者隱藏起來(lái)。

隱藏葉子代碼，突出主干邏輯的一些手法

1）Converter（轉(zhuǎn)換器）

大部分時(shí)候我們使用 bean 拷貝使用的是BeanUtils這個(gè)類(lèi)來(lái)完成，然而一些稍微復(fù)雜的實(shí)體轉(zhuǎn)換，這個(gè)類(lèi)就無(wú)法勝任了，這個(gè)時(shí)候我們只能手動(dòng)的 get set ,往往就是這些get set 方法掩蓋了主干邏輯，讓代碼結(jié)構(gòu)不清晰。因此我建議在你的業(yè)務(wù)邏輯代碼中引入1）Converter這個(gè)角色來(lái)專(zhuān)門(mén)負(fù)責(zé)數(shù)據(jù)的傳遞與轉(zhuǎn)換。

2）manager 層

無(wú)論我們使用的持久層框架是哪一種，jpa 或者 mybatis 我覺(jué)得我們都應(yīng)該對(duì)持久層的部分方法進(jìn)行簡(jiǎn)單封裝一下，這也是阿里規(guī)范里面提倡的。這樣做好處是明顯的，我們做一個(gè)查詢(xún)時(shí)往往要 set 一些查詢(xún)條件或者對(duì)查詢(xún)結(jié)果進(jìn)行一些簡(jiǎn)單的判斷，往往這類(lèi)操作在業(yè)務(wù)代碼可能有比較高的重復(fù)性。如果把這些代碼放到業(yè)務(wù)邏輯代碼里面，少量還好，多了的話就顯得很臃腫了。如果把這種代碼移到manager層里面去，不僅主業(yè)務(wù)邏輯代碼不會(huì)被干擾，還能提高一定的代碼復(fù)用率。

3）方法簡(jiǎn)單封裝

假設(shè)我們一個(gè)方法要完成一段邏輯要分成三大步，而每一個(gè)步驟又分成幾個(gè)小步驟，那我們就可以將這個(gè)方法拆分成三個(gè)方法，然后在這三個(gè)方法里面完成各自的步驟。這手法是很簡(jiǎn)單的，想必大家都能想到，但是我這里要介紹的是簡(jiǎn)化復(fù)雜方法封裝的神器——函數(shù)式編程，我這里指的函數(shù)式編程不僅僅是 stream 流和 lambda 表達(dá)式的使用。函數(shù)式編程封裝適用的場(chǎng)景是：整個(gè)流程比較固定，但是某幾個(gè)步驟變化是不確定的。我們可以去看看java.util.function這個(gè)包的源碼，你會(huì)發(fā)現(xiàn)這個(gè)包下面全是接口，這些接口被稱(chēng)為函數(shù)式接口。這些函數(shù)式接口總體上分為四類(lèi)：

Function 類(lèi)型：傳入一個(gè)bean 返回另外一個(gè)bean

Consumer 類(lèi)型：傳入一個(gè)bean 無(wú)返回值

Predicate 類(lèi)型：傳入一個(gè)bean 返回布爾值

Supplier 類(lèi)型：沒(méi)有入?yún)?，有出?/p>

以 Consumer 的使用為例：

public User getUser(Consumer consumer){
User user=new User();
consumer.accept(user);
user=userMapper.getUser(user);
return user;
}

public void doSomething1(){
User user=getUser(user->{user.setId(1L)});
}

public void doSomething2(){
User user=getUser(user->{user.setName("xxx")});
}

函數(shù)式編程的想象空間很大，使用的得當(dāng)必定會(huì)簡(jiǎn)化你的代碼，提高代碼復(fù)用率。但是在多線程中使用函數(shù)時(shí)要留意數(shù)據(jù)的可見(jiàn)性問(wèn)題。

日志和注釋的一些個(gè)人經(jīng)驗(yàn)

1）日志

首先我們要明白日志是給人看的，你加這段日志時(shí)要考慮清楚，有沒(méi)有人會(huì)去查這段日志，這段日志有沒(méi)有用。然后我們查閱日志的時(shí)候，一般會(huì)通過(guò)關(guān)鍵詞去搜索；因此我們打的日志一定要有關(guān)鍵詞，而且這個(gè)關(guān)鍵詞不要和其他日志重復(fù)，不要過(guò)長(zhǎng)，便于搜索才是王道。大部分情況我們查看日志都是為了追溯bug，那么一個(gè)基本原則就是能通過(guò)日志分析出業(yè)務(wù)邏輯或者流程的走向，對(duì)此我建議打日志的地方：

數(shù)據(jù)更新：我們有必要知道寫(xiě)庫(kù)的數(shù)據(jù)是不是正確的數(shù)據(jù)；

條件分支：便于我們分析業(yè)務(wù)走的哪一條邏輯；

批量寫(xiě)庫(kù)：打上數(shù)據(jù)量大小的日志，便于我們分析性能瓶頸。

并不是所有的這些地方都應(yīng)該打上日志，有的時(shí)候我們可能只需要通過(guò)一兩條日志就能分析出整個(gè)流程的問(wèn)題點(diǎn)在哪，這個(gè)時(shí)候其他的日志就顯得多余了。還有我們打完日志之后應(yīng)該在本地環(huán)境追溯一下，看看這些日志自己是否能讀懂，是否有必要，是否少了重要參數(shù)。

2）注釋

最基本的兩個(gè)注釋——類(lèi)注釋?zhuān)椒ㄗ⑨屜嚓P(guān)規(guī)范阿里開(kāi)發(fā)手冊(cè)上就有，我這里就不復(fù)述了，我分享下我寫(xiě)注釋的個(gè)人習(xí)慣。方法注釋上除了基本的注釋?zhuān)疫€會(huì)將產(chǎn)品需求的原文貼重要的部分上去再寫(xiě)上日期，這樣做的好處是讓別人明白產(chǎn)品需求要求干啥這個(gè)方法該干啥，而且產(chǎn)品經(jīng)理偷偷改需求你還能有追查的根據(jù)，有個(gè)小本本偷偷記錄他的罪行。

代碼注釋我分享一個(gè)我偷師來(lái)的小技巧：

pulic void test(){
/** 1. 從excel 獲取 vo*/
Workbook workBook = getWorkBook(wookbookStream);
//獲取成員信息
Sheet userSheet = workBook.getSheetAt(3);
Map userVOMap = getUserForExcel(file, userSheet);
// 獲取項(xiàng)目vo
Sheet projectSheet = workBook.getSheetAt(0);
ProjectVO projectVO = getProjectForExcel(file, isInsert, userVOMap);
// 獲取任務(wù)vo
Sheet taskSheet = workBook.getSheetAt(1);
Map taskVOMap = getTaskListForExcel(file, taskSheet, userVOMap);
/** 2. 插入數(shù)據(jù) */
if (isInsert.get()){
......
}
/** 3.寫(xiě)入異常信息 */
if (!isInsert.get()) {
.....
}
}

如你所見(jiàn)，對(duì)于主干的步驟 我用/** 1. *//** 2. */javadoc的注釋來(lái)標(biāo)注了，而普通的注釋我用//標(biāo)注，因?yàn)閕dea 在純黑主題下會(huì)給/**這樣的注釋配上綠色，會(huì)比較顯眼。我通過(guò)這種方式來(lái)強(qiáng)調(diào)我代碼哪些是花，哪些是葉子。當(dāng)然這種方式實(shí)際上是不大符合代碼規(guī)范的，小伙伴們理性取舍，這種手法未必好。

六大基本原則

對(duì)于面向?qū)ο蟮牡恼Z(yǔ)言，六大基本是很重要的開(kāi)發(fā)準(zhǔn)則，但似乎大部分人在寫(xiě)代碼的時(shí)候都不大在意這個(gè)，這也是導(dǎo)致一個(gè)方法變得又臭又長(zhǎng)的一個(gè)重要原因之一。對(duì)于類(lèi)的復(fù)雜度我們應(yīng)該遵循單一職責(zé)原則——一個(gè)類(lèi)或者方法承擔(dān)的職責(zé)越多，它被復(fù)用的可能性就越小，重構(gòu)或者修改起來(lái)就會(huì)變得困難重重，我們應(yīng)該盡量讓一個(gè)方法只去做一件事情。

對(duì)于許多代碼我們只要通過(guò)一些簡(jiǎn)單的手法就能很好的提高其擴(kuò)展性，比如通過(guò)接口去實(shí)現(xiàn)類(lèi)與類(lèi)之間的協(xié)作就能提前解決掉許多未知隱患，而且運(yùn)用得當(dāng)?shù)那闆r下還能滿(mǎn)足開(kāi)閉原則與里氏替換原則，其實(shí)service層的設(shè)計(jì)就有那么點(diǎn)味道了，而且spring的特性也支持接口注入List和map，然而許多開(kāi)發(fā)多年的同學(xué)都不知道這個(gè)特性，這個(gè)特性在許多場(chǎng)景下可以提高代碼的擴(kuò)展性，眾所周知，map可以減少代碼的 if else 分支。

方法命名 ‘潛規(guī)則’

很多時(shí)候，好的方法命名本身就是對(duì)代碼的一種注釋?zhuān)疫@里好的方法命名是指大家約定俗成的命名規(guī)則。如果你多留心各個(gè)開(kāi)源框架的代碼都會(huì)發(fā)現(xiàn)一些特定的命名規(guī)則。阿里開(kāi)發(fā)手冊(cè)里面也列舉不少命名前綴與后綴的規(guī)范，其實(shí)各個(gè)團(tuán)隊(duì)可以根據(jù)自己的實(shí)際情況規(guī)定一些命名規(guī)則，降低團(tuán)隊(duì)內(nèi)部的代碼閱讀的成本。

介紹過(guò)部分命名規(guī)則，感興趣的小伙伴可以去看看。

代碼提交及版本控制

正確代碼提交日志格式可以幫助開(kāi)發(fā)人員及時(shí)的縷清代碼的修改歷史，從而快速的定位問(wèn)題。以git為例，我們大部分人提交日志就是幾個(gè)字而已，當(dāng)然你能夠通過(guò)日志去定位到自己的修改歷史的話，這樣做也沒(méi)什么大問(wèn)題，但是對(duì)于團(tuán)隊(duì)而言，你的修改日志要讓別人能看懂就得按一定的格式來(lái)寫(xiě)了。Git Commit message的 Angular規(guī)范中定義的 commit message 格式有3個(gè)內(nèi)容：

Header Header部分有3個(gè)字段：type(必需), scope(可選), subject(必需)

Body 部分是對(duì)本次 commit 的詳細(xì)描述，可以分成多行。

Footer不常用，可為空 包括不兼容變動(dòng)、關(guān)閉issue。

這里由于篇幅問(wèn)題不細(xì)說(shuō)，感興趣的小伙伴可以百度查查資料。我們團(tuán)隊(duì)不一定要按照這么嚴(yán)格的規(guī)則來(lái)，但是可以制定一個(gè)類(lèi)似的規(guī)范來(lái)管理提交日志。

對(duì)于團(tuán)隊(duì)而言，gitflow 是一個(gè)很不錯(cuò)的開(kāi)發(fā)流程。可以很大程度上管理好我們的分支代碼，避免團(tuán)隊(duì)的人由于誤操作而導(dǎo)致某個(gè)重要分支出現(xiàn)問(wèn)題。下面貼出gitflow 流程圖，對(duì)于其具體內(nèi)容同樣不會(huì)介紹太多，感興趣的小伙伴去百度吧

幫助代碼規(guī)范的工具

本節(jié)主要介紹提高代碼質(zhì)量的idea插件和框架，當(dāng)然大名鼎鼎的 阿里代碼規(guī)范插件咱就不介紹了，想必大家多少了解。不過(guò)本人感覺(jué)這個(gè)插件并不適合一些團(tuán)隊(duì)，一是感覺(jué)這個(gè)規(guī)范太過(guò)嚴(yán)格，對(duì)開(kāi)發(fā)人員素質(zhì)要求太高，二是有的團(tuán)隊(duì)有自己的規(guī)范規(guī)則，而且有可能和阿里規(guī)范沖突，不適用于這個(gè)插件。下面介紹的插件可能不適合一些小伙伴。我列舉出來(lái)大家自己尋思吧。

mapstruct

對(duì)于我而言是很喜歡這個(gè)東西的，這個(gè)框架解決的問(wèn)題其實(shí)就是我上文提到的花葉論中的 “數(shù)據(jù)轉(zhuǎn)換” 的問(wèn)題。其實(shí)不少公司也有類(lèi)似的概念——定義一個(gè)工具類(lèi)作用是將 DO轉(zhuǎn)VO 或者 VO轉(zhuǎn)DTO等，一般這類(lèi)類(lèi)都是以converter結(jié)尾。而mapstruct這個(gè)框架通過(guò)編譯器生成字節(jié)碼來(lái)自動(dòng)的生成bean的轉(zhuǎn)換類(lèi)。我們想將一個(gè)bean的數(shù)據(jù)賦值給另外一個(gè)bean只需要去定義接口即可。這樣既減輕了開(kāi)發(fā)人員的工作量還將無(wú)意義的get和set方法從邏輯代碼塊中剔除出去。這個(gè)框架的缺點(diǎn)是字節(jié)碼緩存問(wèn)題，用過(guò)類(lèi)似自動(dòng)生成字節(jié)碼工具的小伙伴應(yīng)該知道——mapstruct 是根據(jù)接口去自動(dòng)生成類(lèi)的，當(dāng)我們更新了接口的時(shí)候，這個(gè)類(lèi)有可能沒(méi)重新生成，當(dāng)然這只有用idea調(diào)試的時(shí)候才會(huì)有的問(wèn)題，所以也不必太擔(dān)心。

checkStyle

idea checkStyle 插件可以通過(guò)自定義配置文件來(lái)統(tǒng)一團(tuán)隊(duì)的代碼風(fēng)格和代碼規(guī)范，降低團(tuán)隊(duì)的交流成本，一般配合 save actions Reborn 使用更佳。關(guān)于checkStyle的配置文件網(wǎng)上也不少，這里也不貼出來(lái)占篇幅了。

git flow

前文提到過(guò)git flow 給團(tuán)隊(duì)帶來(lái)的好處，idea也有對(duì)應(yīng)的插件——git Flow Integration，可以通過(guò)這個(gè)插件來(lái)規(guī)范我們的流程：

開(kāi)發(fā)新功能選擇 start Feature 拉取分支，修復(fù)bug 選擇 Start Bugfix 拉取分支，等等。此外還有 push on finish等功能，小伙伴如果感興趣可以百度。

Git Commit Template

這個(gè)主要是用來(lái)規(guī)范git commit 的一個(gè)idea插件小工具了，github上也有類(lèi)似的開(kāi)源插件。團(tuán)隊(duì)內(nèi)部也可以自己開(kāi)發(fā)一個(gè)類(lèi)似插件，比較簡(jiǎn)單，成本也不高。

代碼規(guī)范的一些個(gè)人看法就聊到這了，喜歡的小伙伴可以分享一下哦。

CloudLinux將在本季度推出AlmaLinux取代CentOS