[[417063]]

本文轉(zhuǎn)載自微信公眾號(hào)「BAT的烏托邦」，作者YourBatman。轉(zhuǎn)載本文請(qǐng)聯(lián)系BAT的烏托邦公眾號(hào)。

前言

你好，我是方同學(xué)(YourBatman)

上篇文章【方同學(xué)】是如何高效的使用IntelliJ IDEA 再一次勾起了較多讀者對(duì)IDEA的興趣，讓我沒(méi)想到的是一個(gè)小小的IDE開(kāi)發(fā)工具而已，甚至都與Java語(yǔ)言沒(méi)有直接關(guān)系，竟然也能寫(xiě)成一個(gè)系列。也許它代表著一種態(tài)度，一種程序員對(duì)工具使用的態(tài)度，not only code。圖片認(rèn)識(shí)我的朋友可能比較清楚，筆者近些年一直從事和帶領(lǐng)團(tuán)隊(duì)從事基礎(chǔ)架構(gòu)、中間件的研發(fā)工作。眾所周知，寫(xiě)基建代碼與業(yè)務(wù)開(kāi)發(fā)有不同，它對(duì)代碼質(zhì)量、可靠性、性能、軟件長(zhǎng)久生命力均會(huì)有更高要求，畢竟基礎(chǔ)不牢，地動(dòng)山搖是共識(shí)。

本文就為你分享，筆者是如何借助IDEA自帶的一些能力，對(duì)書(shū)寫(xiě)的代碼進(jìn)行(質(zhì)量)審查的。工具的出生就為提效，熟練使用對(duì)個(gè)人甚至團(tuán)隊(duì)都有好處。

所屬專欄

BATutopia-IntelliJ IDEA

相關(guān)下載

【女?huà)zKnife-Initializr工程】訪問(wèn)地址：https://start.yourbatman.cn 或 http://152.136.106.14:8761

Java開(kāi)發(fā)軟件包(Mac)：https://wangpan.yourbatman.cn/s/rEH0 提取碼：javakit

程序員專用網(wǎng)盤(pán)上線啦，開(kāi)放注冊(cè)送1G超小容量，幫你實(shí)踐做減法：https://wangpan.yourbatman.cn

版本約定

IntelliJ IDEA 2021.2

正文

提高代碼質(zhì)量的手段

代碼作為軟件的載體，是軟件最為重要的組成部分。所以一個(gè)軟件的質(zhì)量如何，很大程度上是由代碼質(zhì)量決定的。也許在寫(xiě)幾句hello world的時(shí)候軟件質(zhì)量尚可，但隨著時(shí)間的推移、代碼量的增加、需求的多變、團(tuán)隊(duì)協(xié)作日益復(fù)雜等因素的加入，往往在質(zhì)量這條路上漸行漸遠(yuǎn)。驀然回首，是不是感覺(jué)自己已忘初心，但依舊砥礪前行呢?

殊不知，代碼并非編譯通過(guò)，萬(wàn)事大吉，編譯只是最最最最基礎(chǔ)的保證而已。

大部分程序員是期望寫(xiě)出高質(zhì)量的代碼，對(duì)自己的代碼質(zhì)量要求是較高追求的?？梢坏┯龅节s工壓力，尤其是在 deadline 之前，就很可能會(huì)把完成度很低的代碼交出去，心想“反正有人給我檢查，到時(shí)候再說(shuō)吧”。但是，這些代碼就好比是一臺(tái)“行走的Bug制造機(jī)”，后患無(wú)窮。作為你的領(lǐng)導(dǎo)看到這樣的代碼上線，可謂慌得一批。

既然趕工期、deadline這種“事件”無(wú)法避免，并且團(tuán)隊(duì)內(nèi)程序員的水平/追求也高低不一，怎么辦?隨著軟件行業(yè)的發(fā)展，出現(xiàn)了一批又一批的方法論、手段、工具用于整體提升軟件質(zhì)量，下面按照離程序員由近及遠(yuǎn)的順序從兩個(gè)方面簡(jiǎn)要了解一下。

程序員側(cè) - 最行之有效

代碼是由程序員寫(xiě)的，最了解它的莫過(guò)于程序員自己。因此在本側(cè)若能夠做好質(zhì)量把控關(guān)，是最行之有效的。正所謂在離“用戶”最近的地方發(fā)現(xiàn)問(wèn)題、解決問(wèn)題往往效率最高的。

當(dāng)然，從品控的方式方法上，自然也有成套的解決方案。處在程序員側(cè)，有個(gè)非常大的優(yōu)勢(shì)：可借助IDE提供的“超強(qiáng)”能力，高效的進(jìn)行代碼審查工作。

IDE通用代碼審查

什么叫通用代碼審查?說(shuō)白了就是關(guān)乎代碼格式、方法/變量命名、基礎(chǔ)語(yǔ)法合理性等等，一般的IDE都有這樣的能力。

比如本文接下來(lái)將要講的IDEA代碼審查能力，就是提供的這方面的能力。

靜態(tài)代碼檢測(cè)

借助checkstyle、p3c這類工具，對(duì)代碼進(jìn)行靜態(tài)檢測(cè)，能夠提早發(fā)現(xiàn)很多運(yùn)行期潛在的bug/風(fēng)險(xiǎn)點(diǎn)。靜態(tài)代碼檢測(cè)對(duì)Java這種靜態(tài)語(yǔ)言效果極佳，這也是靜態(tài)語(yǔ)言的巨大優(yōu)勢(shì)之一：健壯性強(qiáng)。它對(duì)動(dòng)態(tài)語(yǔ)言(如Python、PHP等)有點(diǎn)無(wú)能為力，效果欠佳。

拿Java舉例，像Long.equals(Integer)這種無(wú)數(shù)人踩過(guò)的坑，通過(guò)靜態(tài)代碼檢測(cè)就可以規(guī)避。另外，代碼規(guī)范、格式等等都可以通過(guò)靜態(tài)代碼檢測(cè)來(lái)實(shí)現(xiàn)很好的約束。值得注意的是，別看只是格式，這也很重要，很多時(shí)候程序出現(xiàn)bug，代碼格式才是原罪。對(duì)于一個(gè)普通的程序員來(lái)講，第一任務(wù)是要寫(xiě)出人能看得懂的代碼，其次才是機(jī)器。

單元測(cè)試

單元測(cè)試(UT)，是指對(duì)軟件中的最小可測(cè)試單元進(jìn)行檢查和驗(yàn)證。那什么叫最小可測(cè)單元呢?以Java語(yǔ)言為例，最小可測(cè)單元就是一個(gè)方法/函數(shù)。

寫(xiě)出一個(gè)可單測(cè)的代碼其實(shí)是非常困難的，有工作經(jīng)驗(yàn)的程序員或多或少經(jīng)歷過(guò)“拒絕寫(xiě)單元測(cè)試”的情況，根據(jù)我的經(jīng)驗(yàn)，出現(xiàn)這種畏難情緒的根本原因是：不會(huì)寫(xiě)，沒(méi)有可“抄”的，畢竟ctrl c + ctrl v才是第一生產(chǎn)力嘛，讓自己去搞，沒(méi)有的事。

國(guó)內(nèi)的開(kāi)發(fā)環(huán)境尚處在初、中期，普遍對(duì)單元測(cè)試的重視度不夠。主要原因我認(rèn)為有兩點(diǎn)：

寫(xiě)好UT需要花費(fèi)一定時(shí)間，而國(guó)內(nèi)行情一般“工期緊”，較少做中長(zhǎng)期規(guī)劃

業(yè)務(wù)邏輯代碼分層不夠、耦合嚴(yán)重，導(dǎo)致寫(xiě)UT代碼時(shí)工作量劇增，近乎無(wú)法單測(cè)

久而久之，積重難返。等到最后上級(jí)領(lǐng)導(dǎo)說(shuō)要關(guān)注代碼質(zhì)量要求寫(xiě)單元測(cè)試的時(shí)候，受到的阻礙情緒將會(huì)是空前的，然后就陷入了惡性循環(huán)。

關(guān)于UT，開(kāi)發(fā)者公認(rèn)的事實(shí)：UT是確保代碼健壯性極其有效的手段。根據(jù)現(xiàn)實(shí)情況，我本人對(duì)UT的態(tài)度是：盡量不要自頂向下的強(qiáng)推，而應(yīng)疏。

單元測(cè)試其實(shí)是一門(mén)嚴(yán)重被低估的“學(xué)問(wèn)”，經(jīng)常是領(lǐng)導(dǎo)大嘴一巴說(shuō)要寫(xiě)，至于怎么寫(xiě)可能領(lǐng)導(dǎo)自己也不知道，甚至可能從來(lái)沒(méi)寫(xiě)過(guò)。正所謂己所不欲勿施于人，我認(rèn)為UT覆蓋率問(wèn)題應(yīng)該上升到方案級(jí)別，而不只是只有一個(gè)字：寫(xiě)。

畏難情緒是順人性的，是天性的表現(xiàn)。在代碼的世界了，不會(huì)才覺(jué)得難，才會(huì)抗拒。畢竟寫(xiě)UT遠(yuǎn)沒(méi)有寫(xiě)業(yè)務(wù)代碼來(lái)得那么的“輕松”。針對(duì)此問(wèn)題，可采用榜樣的力量逐步疏通、滲透。對(duì)于個(gè)人來(lái)講，應(yīng)該迎難而上，追求更高質(zhì)量的代碼。

CI/CD側(cè) - 統(tǒng)一卡點(diǎn)

雖然說(shuō)在程序員側(cè)進(jìn)行一些質(zhì)量把控環(huán)節(jié)效果是最佳的，但此方式高度依賴程序員本身的綜合水平和自覺(jué)性，可靠性是明顯不夠的。因此在實(shí)際生產(chǎn)上，需要輔助一些集中式卡點(diǎn)行為來(lái)做保障。

Code Review

對(duì)每個(gè)提測(cè)的分支，(至少在上線前)必須要進(jìn)行CR(code review)環(huán)節(jié)。此環(huán)節(jié)比較出名的工具有：Gitlab(商業(yè)版)、Fisheye等

集中式靜態(tài)代碼檢測(cè)

簡(jiǎn)而言之，就是將你本地靜態(tài)代碼監(jiān)測(cè)的能力搬到云端，進(jìn)行集中檢測(cè)。一般可分為全量檢測(cè)和增量檢測(cè)。此環(huán)節(jié)比較出名的工具有：sonar、cubase等

集成測(cè)試

對(duì)多個(gè)系統(tǒng)進(jìn)行集成測(cè)試、邊界測(cè)試。該環(huán)節(jié)一般屬于QA人工介入階段，和業(yè)務(wù)邏輯強(qiáng)關(guān)聯(lián)，是最為耗時(shí)的階段之一。

持續(xù)集成流水線工具

在軟件發(fā)布階段，也會(huì)有一些相應(yīng)的審核、卡點(diǎn)機(jī)制。此環(huán)節(jié)比較出名的工具有：jenkins、hudson等

借助IDEA審查你的代碼

做個(gè)小調(diào)查：有多少同學(xué)從來(lái)沒(méi)有使用過(guò)甚至從來(lái)沒(méi)有看過(guò)IDEA的code菜單呢?

不管你看沒(méi)看過(guò)，應(yīng)該直接或間接的使用過(guò)其相關(guān)功能。比如這個(gè)Generate...

自動(dòng)為JavaBean生成get/set方法、構(gòu)造器、hashCode()、toString()等方法。也許你會(huì)說(shuō)現(xiàn)在用lombok基本不使用它了，對(duì)，這是事實(shí)。但是，再不濟(jì)，像Override Methods、Implement Methods這些功能都用過(guò)吧，畢竟我不信方法復(fù)寫(xiě)、方法實(shí)現(xiàn)這種模板代碼你會(huì)一字一句手敲~

那么，接下來(lái)重點(diǎn)向你介紹code菜單里面的代碼審查功能，順帶也分享筆者是如何利用IDEA提供的這些能力去幫助自己、甚至幫助團(tuán)隊(duì)提高代碼質(zhì)量、保證代碼質(zhì)量的。

代碼審查相關(guān)功能在Code菜單這里(如下圖)。兩條灰色的線條將這幾項(xiàng)歸為一類：

以這段示例代碼為例審查：

package cn.yourbatman; 
 
import org.springframework.boot.SpringApplication; 
import org.springframework.boot.autoconfigure.SpringBootApplication; 
import org.springframework.boot.autoconfigure.AutoConfigureAfter; 
 
@SpringBootApplication 
public class Application { 
 
    private String name; 
    private String agee; 
 
    public static void main(String[] args) { 
        SpringApplication.run(Application.class, args); 
    } 
 
    public boolean fun1(boolean bool) { 
        return bool ? true : false; 
    } 
 
    public String fun2(String s) { 
        return s.toString(); 
    } 
} 

Inspect Code...審查你的代碼

Inspect：檢查、審查。

點(diǎn)擊OK運(yùn)行，在problem視窗里可以看到“有問(wèn)題”的代碼：

經(jīng)過(guò)審查，本工程里的“壞味道”代碼就在problem視窗指出了。如圖，IDEA針對(duì)性的提供了便捷的一鍵處理按鈕，你可以快速處理，非常智能化和人性化有木有。

到這，你可能不禁想問(wèn)：IDEA怎么知道這是壞味道代碼的?遵照什么規(guī)則?顯然，一切都是“有法可依”，它在這：設(shè)置 -> Editor -> Inspections

一般來(lái)講，Inspections保持默認(rèn)即可。但我會(huì)把拼寫(xiě)檢查(畢竟英語(yǔ)并非咱母語(yǔ)，偶爾單詞拼寫(xiě)錯(cuò)誤甚至用拼音是可以原諒的，關(guān)掉它以節(jié)約點(diǎn)性能開(kāi)銷嘛)相關(guān)的關(guān)掉：Spelling、Typo

注意：Inspect Code只會(huì)幫你把壞味道代碼“揪出來(lái)”，改還是不改的決策權(quán)還在于你自己。

Code Cleanup...精煉你的代碼

不同于Inspect Code幫你指出壞味道的代碼，它比較“狠”，會(huì)拿你的代碼直接開(kāi)刀。如下：

執(zhí)行該動(dòng)作不需要同意，IDEA會(huì)直接動(dòng)手修改你的代碼。

當(dāng)然嘍，你duck不必?fù)?dān)心它改亂了：它有且只做同等語(yǔ)義的替換，使得代碼組織起來(lái)更優(yōu)雅，絕不會(huì)影響到程序的正確執(zhí)行。

Tips：有時(shí)候人容易理解和優(yōu)雅寫(xiě)法是相沖的，這個(gè)時(shí)候你就得三思是否有必要執(zhí)行此功能嘍

Analyze Code...分析你的代碼

它是一個(gè)功能集的統(tǒng)稱。

問(wèn)：為何這些功能被放在二級(jí)目錄下?答：相對(duì)來(lái)說(shuō)不太常用。這是基本的產(chǎn)品設(shè)計(jì)邏輯嘛：常用的放在一級(jí)目錄，不常用的功能下層

Silent Code Cleanup

靜悄悄的完成精煉你的代碼操作，執(zhí)行結(jié)果同Code Cleanup。我的使用情況：基本不用

Run Inspection by name

如果覺(jué)得每次運(yùn)行Inspect Code把所有的規(guī)則都走一遍太慢了，那么就可以使用此功能：只運(yùn)行指定名稱的規(guī)則

我的使用情況：基本不用?，F(xiàn)在微服務(wù)開(kāi)發(fā)模式，每個(gè)應(yīng)用“體積”都很小，1s和0.5s的差異who care呢

View Offline Inspection Results

離線查看代碼分析的結(jié)果。此功能的存在，是因?yàn)閜roblem結(jié)果是可以導(dǎo)出的：

我的使用情況：只使用過(guò)幾次。那是我要給團(tuán)隊(duì)做分享，所以通過(guò)導(dǎo)出文件來(lái)保留“現(xiàn)場(chǎng)”，從而在分享時(shí)在導(dǎo)入方便說(shuō)明問(wèn)題。

Infer Nullify

Infer：推斷。此功能作用是在方法參數(shù)、返回值里幫你推斷：哪些必須不能為null、哪些可以為null

以這個(gè)方法為例：

public String fun2(String s) { 
    return s.toString(); 
} 

內(nèi)部調(diào)用了s的toString()方法，因此s肯定不能為null，進(jìn)而推斷出返回值也就不可能為null。因此，運(yùn)行IDEA的此功能后，代碼會(huì)被改成這樣：方法簽名的語(yǔ)義更加明確

public @NotNull String fun2(@NotNull String s) { 
    return s.toString(); 
} 

值得注意的是，注解它只用于表達(dá)語(yǔ)義，運(yùn)行期無(wú)任何作用。另外，該功能要正常執(zhí)行需要此依賴包才行：

若沒(méi)有此依賴，執(zhí)行時(shí)會(huì)彈出提示你添加依賴：

此時(shí)點(diǎn)擊ok就能自動(dòng)幫你把依賴加上了，非常方便。

Tips：點(diǎn)ok后此框不會(huì)消失，但實(shí)際依賴已經(jīng)加上，不用重復(fù)點(diǎn)哦，否則會(huì)重復(fù)添加依賴的。這是IDEA的一個(gè)小bug

我的使用情況：從未使用過(guò)。因?yàn)槲伊?xí)慣使用功能更強(qiáng)大的Bean Validation，不僅語(yǔ)義明確，runtime時(shí)期也會(huì)生效。

Locate Duplicate

顧名思義，幫你定位重復(fù)代碼，以便做封裝、抽象。

我的使用情況：在review組員代碼的時(shí)候，用得較多。查找結(jié)果還是蠻有參考價(jià)值的，推薦使用

Dependencies...

IDEA在Project視窗，把依賴統(tǒng)一全部放在了External Libraries里，就像這樣：

若是一個(gè)多模塊的項(xiàng)目，此時(shí)只想查看某1個(gè)模塊的依賴的話，通過(guò)External Libraries就無(wú)能為力了。這個(gè)時(shí)候一般有兩種辦法來(lái)查看具體某個(gè)模塊的依賴：

通過(guò)Maven視窗查看

這種方式，它對(duì)于中小型服務(wù)可以解決絕大部分問(wèn)題，因?yàn)橐蕾嚥欢嗖浑y定位。但是它的明顯缺點(diǎn)是：不夠直觀。并不能一眼看出來(lái)模塊的最終依賴。比如某個(gè)依賴是間接依賴進(jìn)來(lái)的，這時(shí)通過(guò)這種方式就非常不直觀了;又比如多個(gè)地方引入了a.jar，也就無(wú)法一眼看出來(lái)最終使用的是哪個(gè)版本的a.jar啦

通過(guò)本處的Dependencies功能

這個(gè)依賴分析功能非常、非常、非常強(qiáng)大。它不僅僅能幫你分析出每個(gè)類(粒度非常細(xì))依賴哪些庫(kù)，還能分析出依賴了本project的哪些類。該功能在閱讀他人代碼(or開(kāi)源代碼)時(shí)非常有用

我的使用情況：較為頻繁。我在閱讀開(kāi)源代碼的時(shí)候使用較多，通過(guò)依賴分析，能夠較快的掌握作者的整體設(shè)計(jì)意圖，具有更全面的視野。

Backward Dependencies...

上面功能是查看自己依賴了誰(shuí)，該功能表示誰(shuí)依賴了自己。

Module、Cycle Dependencies...

用于分析本工程的模塊粒度的依賴關(guān)系，是否存在循環(huán)依賴等，使用起來(lái)比較簡(jiǎn)單，不詳細(xì)解釋了。

Analyze Stack Trace or Thread Dump...

又一神器，這個(gè)工具我可太愛(ài)了。字面含義：分析堆棧，或者內(nèi)存dump。

例如有這么一個(gè)場(chǎng)景：線上服務(wù)出bug拋了異常，日志文件里留下的是堆棧信息，面對(duì)這個(gè)堆棧信息你如何快速定位到問(wèn)題代碼呢?

這個(gè)時(shí)候一般是在這個(gè)黑框里逐行的找，找到“熟悉”的一行(有行號(hào))，然后返回到IDEA里找到對(duì)應(yīng)的類，問(wèn)題定位路徑其實(shí)還蠻長(zhǎng)的。

其實(shí)duck不必這么麻煩，IDEA為咱們提供了非常好用的分析工具，你只需要：

• 復(fù)制堆棧信息
• 在IDEA里Code -> Analyze Stack Trace or Thread Dump打開(kāi)分析窗口

點(diǎn)擊ok，控制臺(tái)里就能顯示出堆棧信息，和本地調(diào)試一模一樣的效果了有木有。

這里我演示的是該功能的最簡(jiǎn)單使用場(chǎng)景，除了分析這種簡(jiǎn)單的堆棧外，還可以分析dump文件，還可以自定義分析器(比如class文件混淆、加密了)等等，最終目的就是讓開(kāi)發(fā)者有種本地化“分析線上問(wèn)題”的體驗(yàn)。

關(guān)于本功能的更多使用方式，感興趣的同學(xué)在真正用起來(lái)的時(shí)，可自己發(fā)現(xiàn)。

總結(jié)

本文以IDEA作為著力點(diǎn)，我主要想輸出的兩個(gè)觀點(diǎn)是：

• 單元測(cè)試被低估了
• IDEA的代碼審查能力被低估了 

作為一個(gè)開(kāi)發(fā)者，很多時(shí)候人與人的差異體現(xiàn)在知道的多與少、知道和不知道上，畢竟大家的教育背景、智商大都差異不大，會(huì)得多一點(diǎn)并且讓這些能支撐自己總是好的。