這篇文章緣起于上一個持續(xù)交付的咨詢項目，當(dāng)時正在指導(dǎo)客戶團(tuán)隊的Java工程師做Code Review，發(fā)現(xiàn)一個很有意思的現(xiàn)象：有一位工程師對Code Style特別在意，所以在Code Review的大部分時間中都是該工程師在指出哪里哪里的格式不對，但是團(tuán)隊并沒有找到改進(jìn)方法，每次的結(jié)論都是“下次我注意一點。”

我挺欣賞這位工程師對Code Style的認(rèn)真態(tài)度，所以就萌生了“怎么拯救Code Style強(qiáng)迫癥”的想法。

要點

• Code Style不是個人喜好問題，它會影響工作效率，團(tuán)隊?wèi)?yīng)將其當(dāng)做工程實踐予以重視。
• Code Style需要端到端的工具支持，盡早解決問題，避免技術(shù)債。
• 以Checkstyle作為核心工具支撐Java項目的Code Style實施方案。

一、Code Style是一項工程實踐

我是右側(cè)風(fēng)格的忠實擁躉，如果讓我在工作的項目中看到左側(cè)風(fēng)格的代碼，你猜猜我的反應(yīng)是什么。

嗯，可能我對代碼風(fēng)格確實有些強(qiáng)迫癥，但事實上，Code Style并不僅僅是代碼是否好看那么簡單，如果沒有按照慣例來編寫代碼，甚至?xí)岄喿x者產(chǎn)生疑惑。

private Listener listener = new Listener() // So Listener looks like a class?   
{}; // Oops, it is an interface 

如果代碼可讀性還不足以打動你，那么想象一下這個場景，你的同事說他修復(fù)了兩個空指針問題，請你幫忙Code Review，你查看了這個文件的修訂歷史，乍看之下有許多改動，看來是個大動作。然而事實上，絕大部分改動是代碼格式調(diào)整，只有兩處改動與需要Review的問題相關(guān)。

(看來這位同事的IDE使用了不同的自動縮進(jìn)設(shè)置，導(dǎo)致所有行都產(chǎn)生了縮進(jìn))

之所以會產(chǎn)生以上這些影響工作效率的問題，是因為團(tuán)隊沒有重視Code Style，沒有把它當(dāng)做一項工程實踐，既沒有對其達(dá)成一致，也沒有正確地使用工具幫助實施。

二、那就按照工程實踐的標(biāo)準(zhǔn)來實施Code Style

本文將重點介紹Java項目中Code Style的工具支持，但在此之前，你的團(tuán)隊需要一起做一些決定：

1. 使用哪種Code Style?

每個人可能都有偏好的style，但在團(tuán)隊協(xié)作面前，需要一定的妥協(xié)。有些公司或組織有著統(tǒng)一的Code Style指導(dǎo)標(biāo)準(zhǔn)，蕭規(guī)曹隨是個不錯的選擇(但是要確保這類統(tǒng)一指導(dǎo)標(biāo)準(zhǔn)在制定時參考了開發(fā)人員的意見，是切實可行的)，你的團(tuán)隊也可以自己裁剪，但至少要保證項目(Repository)級別上使用同一種Style。

2. 如何處理不符合Code Style的提交?

大家往往懈怠于事后補(bǔ)救的方式，我的建議是不要讓不符合約定的代碼流入代碼庫。對于遺留項目，尤其是大型項目，可以選擇一部分代碼作為實施范圍，集中修復(fù)Style問題后嚴(yán)格實施，切忌操之過急，最后團(tuán)隊疲憊不堪只得放棄。

我們都知道人工監(jiān)督檢查的方式是不可持續(xù)和不可靠的，來看看有哪些工具可以提供幫助吧。

三、懶惰是第一生產(chǎn)力

工程實踐不能沒有自動化工具支持，在Java生態(tài)圈中，Code Style工具最出名的應(yīng)該是Checkstyle了，它可以通過XML形式的外部DSL來定義Code Style的檢查風(fēng)格，比如你可以從這里找到Google的Java Checkstyle配置文件。這里我不會詳細(xì)介紹Checkstyle本身，相反，我會更多地探討如何工程化地使用Checkstyle，在交付代碼的各個活動中，我們都可以用到Checkstyle，進(jìn)行360°無死角的檢查。

(和Code Style相關(guān)的代碼交付生命周期)

1. 守住提交的質(zhì)量關(guān)口

為了貫徹不讓不符合約定的代碼流入代碼庫的決定，可以優(yōu)先在服務(wù)端設(shè)置Code Style的檢查關(guān)卡。

(優(yōu)先守住代碼提交時的服務(wù)端檢查，可以考慮使用CI服務(wù)器來實現(xiàn))

2. 從實現(xiàn)層面上說，有兩種方式：

一是在SCM(Source Control Management，例如Git/SVN)服務(wù)端設(shè)置檢查項，如果不達(dá)標(biāo)則拒絕提交，但這種方式相對不容易實現(xiàn)，而且一般SCM服務(wù)端也不由開發(fā)團(tuán)隊管理，設(shè)置起來不靈活也不方便。

二是利用持續(xù)集成服務(wù)器，開發(fā)團(tuán)隊的每一次提交都會觸發(fā)一次構(gòu)建，我們可以在構(gòu)建腳本中加入Checkstyle檢查，如果有不達(dá)標(biāo)的代碼則讓構(gòu)建失敗，以便告訴提交者立即修復(fù)Style問題。我更推薦這個方案，因為相關(guān)的工具支持都很成熟，實現(xiàn)簡單，而且構(gòu)建過程可以在開發(fā)者的本地環(huán)境復(fù)制，以便在后續(xù)改進(jìn)中將Checkstyle檢查前移，提供更快的反饋。如果團(tuán)隊使用Maven/Gradle等構(gòu)建工具，可以用插件的方式實現(xiàn)Checkstyle檢查并嵌入到整個構(gòu)建過程中。這樣CI服務(wù)器只要調(diào)用構(gòu)建腳本就行了。

四、在開發(fā)者本地驗證Style

(在開發(fā)者本地實現(xiàn)驗證，反饋關(guān)口前移)

在實現(xiàn)了CI驗證后，就可以著手實現(xiàn)開發(fā)者本地驗證了，這樣開發(fā)者就不用等到提交代碼到服務(wù)端后才會獲得反饋了。由于之前采用的是構(gòu)建工具的插件方案，所以開發(fā)者在本地運行構(gòu)建就能實現(xiàn)驗證了。比如Gradle提供了Checkstyle插件支持，你可以在這里找到Gradle Checkstyle Plugin的詳細(xì)配置文檔，如果你使用Maven，則可以參考這里。現(xiàn)在只需要一條命令，開發(fā)者久能在本地驗證Code style了。(你也可以點擊左下角閱讀原文，查看完整的代碼示例)

本地驗證很不錯，但我有時候會忘記執(zhí)行。

(讓機(jī)器代勞瑣事)

有時候，開發(fā)者修改了代碼后會忘記執(zhí)行本地檢查就提交代碼了，最好能夠在提交代碼前自動執(zhí)行檢查。如果你使用Git的話，可能會想到Git commit hook，比如這是我常用的pre-commit hook

#!/bin/sh 
# From gist at https://gist.github.com/chadmaughan/5889802 
 
# stash any unstaged changes 
git stash -q --keep-index 
 
# run the tests with the gradle wrapper 
./gradlew clean build 
 
# store the last exit code in a variable 
RESULT=$? 
 
# unstash the unstashed changes 
git stash pop -q 
 
# return the './gradlew build' exit code 
exit $RESULT 

將該腳本拷貝到.git/hooks/下，在執(zhí)行g(shù)it commit的時候就會自動觸發(fā)檢查了，如果檢查失敗則提交失敗。但問題是.git并不能提交到遠(yuǎn)程代碼倉庫，那么除了人工分發(fā)和拷貝外，有沒有更好的方式在團(tuán)隊中共享這個機(jī)制呢?

可以曲線救國!把pre-commit納入版本控制(如下面的config/pre-commit)，再使用構(gòu)建工具的擴(kuò)展機(jī)制來自動完成拷貝工作，這樣可以間接實現(xiàn)git hooks的團(tuán)隊間共享。

# build.gradle 
 
task installGitHooks(type: Copy) { //將pre-commit拷貝到指定位置 
  from new File(rootProject.rootDir, 'config/pre-commit') 
  into { 
    new File(rootProject.rootDir, '.git/hooks') 
  } 
  fileMode 0755 
} 
 
build.dependsOn installGitHooks //設(shè)置執(zhí)行build任務(wù)時會自動觸發(fā)installGitHooks任務(wù) 

五、關(guān)閉包圍圈，編輯時反饋

(實時反饋)

之前基于構(gòu)建工具的方案都很好，但是對于開發(fā)者來說，最好能將反饋前移到編輯時，并且可視化。所幸的是，Checkstyle的生態(tài)系統(tǒng)非常成熟，各主流IDE都有插件支持，以Intellij Idea為例，可以使用checkstyle-idea插件，讓團(tuán)隊成員手工設(shè)置插件，使用項目的checkstyle配置文件即可(我目前還沒有找到自動化配置的方式，或許gradle idea插件可以?)

(checkstyle-idea插件配置和效果)

有了自動實時檢查，最好還能將IDE的自動格式化與Checkstyle配置文件掛鉤，否則自動格式化反倒給你添麻煩了。

(為IDE導(dǎo)入checkstyle配置文件作為自動格式化的依據(jù))

如果你連自動格式化都懶得按，那可以試試Save Actions插件，它可以在Intellij保存文件時自動執(zhí)行代碼格式化等動作。

(這個插件目前對部分文件有些問題，可以通過File path exclusion忽略)

六、總結(jié)

1、Code Style影響工作效率，團(tuán)隊?wèi)?yīng)將其當(dāng)做工程實踐予以重視。

2、Code Style不能靠人工監(jiān)督和檢查，應(yīng)該提供端到端的工具支持

• 開發(fā)環(huán)境檢查(使用各構(gòu)建工具的Checkstyle插件)
• 自動提交檢查(git pre-commit hook與共享)
• IDE增強(qiáng)(checkstyle插件實時可視化反饋/自動的自動格式化!)
• 以上的工具都要依據(jù)為同一份Checkstyle配置文件，并納入版本控制

希望以上這些招數(shù)可以解救Java Code Style強(qiáng)迫癥。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文