代碼混亂的常見問題

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

代碼又臭又長

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

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

代碼邏輯不明

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

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

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

花葉論

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

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

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

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

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

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

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

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

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

2）manager 層

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

3）方法簡單封裝

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

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

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

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

Supplier 類型：沒有入?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ì)簡化你的代碼，提高代碼復(fù)用率。但是在多線程中使用函數(shù)時(shí)要留意數(shù)據(jù)的可見性問題。

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

1）日志

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

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

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

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

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

2）注釋

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

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

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.寫入異常信息 */
if (!isInsert.get()) {
.....
}
}

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

六大基本原則

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

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

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

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

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

代碼提交及版本控制

正確代碼提交日志格式可以幫助開發(fā)人員及時(shí)的縷清代碼的修改歷史，從而快速的定位問題。以git為例，我們大部分人提交日志就是幾個(gè)字而已，當(dāng)然你能夠通過日志去定位到自己的修改歷史的話，這樣做也沒什么大問題，但是對(duì)于團(tuán)隊(duì)而言，你的修改日志要讓別人能看懂就得按一定的格式來寫了。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。

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

對(duì)于團(tuán)隊(duì)而言，gitflow 是一個(gè)很不錯(cuò)的開發(fā)流程?？梢院艽蟪潭壬瞎芾砗梦覀兊姆种Тa，避免團(tuán)隊(duì)的人由于誤操作而導(dǎo)致某個(gè)重要分支出現(xiàn)問題。下面貼出gitflow 流程圖，對(duì)于其具體內(nèi)容同樣不會(huì)介紹太多，感興趣的小伙伴去百度吧

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

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

mapstruct

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

checkStyle

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

git flow

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

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

Git Commit Template

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

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

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