優(yōu)秀的團(tuán)隊為了保證可讀性、可維護(hù)性、避免重復(fù)踩坑與保證代碼質(zhì)量，都會推出一些開發(fā)規(guī)范來遵守。開發(fā)規(guī)范是前置主動要求團(tuán)隊成員遵守的，而光靠意識是難以保證完全遵守規(guī)范的，所以還需要一些工具輔助。當(dāng)然即使有工具做這些事情，規(guī)范也是必須推廣的，讓大家先仔細(xì)讀讀，畢竟直接寫出優(yōu)秀的代碼是最好的，然后再輔助工具乃最佳實踐。

開發(fā)規(guī)范

一流公司制定規(guī)范，二流公司申請專利，三流公司生產(chǎn)產(chǎn)品。所以目前公開規(guī)范的大多是大廠的規(guī)范。

目前知道大廠公開的Java開發(fā)規(guī)范

Google開發(fā)規(guī)范 github markdown格式 點我查看

阿里巴巴開發(fā)規(guī)范 PDF格式 點我查看最新版

華為開發(fā)規(guī)范

Oracle開發(fā)規(guī)范

阿里巴巴的開發(fā)規(guī)范，雖然不是單純的規(guī)范，還包括了開發(fā)中的各種坑從主觀上的一些強(qiáng)制規(guī)定，但是總體上還是很有用的，可以拿來部分or全部直接執(zhí)行。

獨立的組件

1. FindBugs

只尋找可能存在bug的地方，不注重樣式或者格式，它試圖只尋找真正的缺陷或者潛在的性能問題。

特點

基于class分析，如果你clean了再去執(zhí)行發(fā)現(xiàn)沒有執(zhí)行生成報告，所以需要編譯后才能執(zhí)行分析

有maven插件，有IDE插件（eclipse插件，也有idea插件）

開發(fā)時不用使用maven插件，要編譯執(zhí)行檢測生成xml然后再生成網(wǎng)頁查看結(jié)果，挺麻煩。如果要與Jenkins集成的時候，maven插件就有用了，集成方式點我

開發(fā)時使用IDE插件非常方便

插件中Bug Explorer 中的灰色圖標(biāo)處為 Bug 類型，紅色圖標(biāo)表示 bug 較為嚴(yán)重，黃色的圖標(biāo)表示 bug 為警告程度

代碼缺陷分類

根據(jù)缺陷的性質(zhì)，大致可以分為下列幾類

Bad practice 不好的做法

Correctness 可能有不正確

Dodgy code 糟糕的代碼

Experimental 實驗

Internationalization 國際化

Malicious code vulnerility 惡意的代碼漏洞

Multithreaded correctness 多線程問題

Performance 性能問題

FindBugs官方網(wǎng)站上也給出了一些案例：案例點我

排除單個規(guī)則

如果是排除一類規(guī)則，點擊IDE旁邊的提示選擇排除類型就行

可以針對規(guī)則排除單獨類中的接觸限制，使用注解

@edu.umd.cs.findbugs.annotations.SuppressFBWarnings

要加入依賴 provided代表只在編譯時依賴，打包后就沒有這個依賴了IDE旁邊提示也有這種，不過不會加入以下依賴，需要手動在POM中加入

<dependency>

? ? <groupId>com.google.code.findbugs</groupId>

? ? <artifactId>annotations</artifactId>

? ? <version>3.0.1</version>

? ? <scope>provided</scope>

</dependency>

<dependency>

? ? <groupId>com.google.code.findbugs</groupId>

? ? <artifactId>jsr305</artifactId>

? ? <version>3.0.1</version>

? ? <scope>provided</scope>

</dependency>

2. CheckStyle

代碼樣式風(fēng)格檢查，專門check代碼規(guī)范風(fēng)格的，比如縮進(jìn)，換行操作，命名大項目往往是有很多人一起完成的，然而每個人都有自己的style，導(dǎo)致整個項目的代碼不僅存在不符合語言規(guī)范的情況，而且讀起來非常困難。因此，這樣的項目中都會引入Checkstyle，來規(guī)范大家的編碼風(fēng)格，盡量做到統(tǒng)一和合理。所以使用checkStyle檢查到問題

官方文檔：http://checkstyle.sourceforge.net/checks.html

工具界面

插件

單個文件check

特點

基于源碼，無需編譯

有maven插件，與IDE插件（eclipse插件，也有idea插件）。idea的一些細(xì)節(jié)配置

可以自定義規(guī)則

CheckStyle底層基于antlr對源碼進(jìn)行處理

可以配置哪些文件不檢查

規(guī)范配置

配置位置

sun_checks.xml 默認(rèn)自帶sun公司的開發(fā)規(guī)范，有點嚴(yán)格

google_checks.xml 下載下來好像有點問題，可能與版本有關(guān) 查看

華為的規(guī)范 很多公司都會用華為的規(guī)范改改

自定義的規(guī)范 比較了解配置規(guī)則的情況下配置技巧

我們在代碼寫完之后，還要花時間去手動解決Checkstyle提示的問題，這是一個非常無聊和耗時的工作。其實很多問題使用IDE的格式化已經(jīng)能解決一部分，所以最好能提供一個IDE的formatter配置，整個團(tuán)隊都用這個配置導(dǎo)入IDE，這樣用用快捷鍵就能解決一些問題，非常easy。

3. PMD

與findbug類似找bug用，還有規(guī)范，比如說注釋不全

特點

有maven插件，與IDE插件（eclipse插件，也有idea插件）

增強(qiáng)代碼質(zhì)量和修改代碼的功能

錯誤分類

可能的bug——空的try/catch/finally/switch塊。

無用代碼(Dead code)：無用的本地變量，方法參數(shù)和私有方法。

空的if/while語句。

過度復(fù)雜的表達(dá)式——不必要的if語句，本來可以用while循環(huán)但是卻用了for循環(huán)。

可優(yōu)化的代碼：浪費性能的String/StringBuffer的使用。

集合組件

1. IdeaIDE的QAPlug

這個插件是匯集這前面說的3個插件的結(jié)果，不用每次都運行3個插件分別排錯，1鍵運行3個同時匯總整合，非常方便，所以其他的不用裝了，就用這個就行了！與sonar平臺的功能類似！如果公司沒有搭建sonarqube平臺的話，本地使用這個最佳

插件下載安裝

依次下載 QAPlug、QAPlug-Checkstyle、QAPlug-FindBugs、QAPlug-PMD

分類

這個插件會把3個插件的錯誤分類匯總

Efficiency 效能

Maintainability 可維護(hù)性

Reliability 可靠性

Usability 可用性

2. SonarQube

代碼質(zhì)量管理系統(tǒng)相當(dāng)于QAPlug的工程獨立出一個服務(wù)器部署，可以配置規(guī)則，掃描代碼，集成了很多靜態(tài)掃描工具2015年3月的時候就看到一篇文章介紹這個平臺了，那時候還沒有太過關(guān)注，后來發(fā)現(xiàn)這個是個很好的平臺

3. Sonarlint

是SonarQube的配套的IDE插件，配置遠(yuǎn)程服務(wù)器的地址,選取要拉去規(guī)則的項目，然后本地就可以執(zhí)行校驗了，用的遠(yuǎn)程的規(guī)則這樣還是很方便的，規(guī)則可以同一在SonarQube維護(hù)，不用每個人本地導(dǎo)入，團(tuán)隊的話用這個最適合

Sonarlint安裝與拉取列表失敗問題解決見

擴(kuò)充-Lint概念

Sonarlint是一個Lint工具，其實Lint的含義就代表代碼靜態(tài)分析的工具，協(xié)助開發(fā)的工具，尤其是前端經(jīng)常使用，比如插件eslint：檢查JavaScript錯誤非常方便

4. JArchitect

多種分析工具的聚合工具是一個商業(yè)性的收費的分析工具可以匯聚checkstyle、findbugs、pmd的xml，然后分類總結(jié)生成圖表不過是收費的，也沒有idea插件，不用

代碼覆蓋率工具

idea自帶了代碼覆蓋率插件還不錯跑單元測試的時候以代碼覆蓋率的方式運行就行了一般邏輯覆蓋率60%就差不多了，核心模塊80%覆蓋標(biāo)準(zhǔn)即可

運行方法

總結(jié)

首先要從意識上要遵守規(guī)范，風(fēng)格統(tǒng)一，需要制定一份Java開發(fā)規(guī)范，我比較傾向于直接使用阿里的Java規(guī)范吧，簡單實用，也不過分嚴(yán)格其次要選擇靜態(tài)代碼工具，沒有SonarQube的話用QAPlug是很好的選擇，有的話裝個Sonarlint插件就可以了代碼覆蓋率通過idea自帶的即可

有些人可能很排斥規(guī)范，總感覺條條框框太多，不符合自己的自由風(fēng)格，但是軟件不是開發(fā)完上線就結(jié)束的過程，而是需要持續(xù)迭代維護(hù)升級的過程，新人會接手，要有可讀性可維護(hù)性。項目大了，人多了也是需要規(guī)范化才能更好的融合協(xié)作，讓混亂變得有序一個人的優(yōu)秀靠的是經(jīng)驗，一個團(tuán)隊的優(yōu)秀靠的是規(guī)范。有了這些規(guī)范與工具，就可以大大的提高團(tuán)隊的整體素質(zhì)與水平，尤其是大廠開發(fā)人員，這個是必須有的。