建站
咨詢
售后
建站咨詢
新聞中心
這篇文章緣起于上一個(gè)持續(xù)交付的咨詢項(xiàng)目，當(dāng)時(shí)正在指導(dǎo)客戶團(tuán)隊(duì)的Java工程師做Code Review，發(fā)現(xiàn)一個(gè)很有意思的現(xiàn)象：有一位工程師對(duì)Code Style特別在意，所以在Code Review的大部分時(shí)間中都是該工程師在指出哪里哪里的格式不對(duì)，但是團(tuán)隊(duì)并沒有找到改進(jìn)方法，每次的結(jié)論都是“下次我注意一點(diǎn)?！?/p>
我挺欣賞這位工程師對(duì)Code Style的認(rèn)真態(tài)度，所以就萌生了“怎么拯救Code Style強(qiáng)迫癥”的想法。
要點(diǎn)
- Code Style不是個(gè)人喜好問題，它會(huì)影響工作效率，團(tuán)隊(duì)?wèi)?yīng)將其當(dāng)做工程實(shí)踐予以重視。
- Code Style需要端到端的工具支持，盡早解決問題，避免技術(shù)債。
- 以Checkstyle作為核心工具支撐Java項(xiàng)目的Code Style實(shí)施方案。
一、Code Style是一項(xiàng)工程實(shí)踐
我是右側(cè)風(fēng)格的忠實(shí)擁躉，如果讓我在工作的項(xiàng)目中看到左側(cè)風(fēng)格的代碼，你猜猜我的反應(yīng)是什么。
嗯，可能我對(duì)代碼風(fēng)格確實(shí)有些強(qiáng)迫癥，但事實(shí)上，Code Style并不僅僅是代碼是否好看那么簡(jiǎn)單，如果沒有按照慣例來編寫代碼，甚至?xí)岄喿x者產(chǎn)生疑惑。
- private Listener listener = new Listener() // So Listener looks like a class?
- {}; // Oops, it is an interface
如果代碼可讀性還不足以打動(dòng)你，那么想象一下這個(gè)場(chǎng)景，你的同事說他修復(fù)了兩個(gè)空指針問題，請(qǐng)你幫忙Code Review，你查看了這個(gè)文件的修訂歷史，乍看之下有許多改動(dòng)，看來是個(gè)大動(dòng)作。然而事實(shí)上，絕大部分改動(dòng)是代碼格式調(diào)整，只有兩處改動(dòng)與需要Review的問題相關(guān)。
(看來這位同事的IDE使用了不同的自動(dòng)縮進(jìn)設(shè)置，導(dǎo)致所有行都產(chǎn)生了縮進(jìn))
之所以會(huì)產(chǎn)生以上這些影響工作效率的問題，是因?yàn)閳F(tuán)隊(duì)沒有重視Code Style，沒有把它當(dāng)做一項(xiàng)工程實(shí)踐，既沒有對(duì)其達(dá)成一致，也沒有正確地使用工具幫助實(shí)施。
二、那就按照工程實(shí)踐的標(biāo)準(zhǔn)來實(shí)施Code Style
本文將重點(diǎn)介紹Java項(xiàng)目中Code Style的工具支持，但在此之前，你的團(tuán)隊(duì)需要一起做一些決定：
1. 使用哪種Code Style?
每個(gè)人可能都有偏好的style，但在團(tuán)隊(duì)協(xié)作面前，需要一定的妥協(xié)。有些公司或組織有著統(tǒng)一的Code Style指導(dǎo)標(biāo)準(zhǔn)，蕭規(guī)曹隨是個(gè)不錯(cuò)的選擇(但是要確保這類統(tǒng)一指導(dǎo)標(biāo)準(zhǔn)在制定時(shí)參考了開發(fā)人員的意見，是切實(shí)可行的)，你的團(tuán)隊(duì)也可以自己裁剪，但至少要保證項(xiàng)目(Repository)級(jí)別上使用同一種Style。
2. 如何處理不符合Code Style的提交?
大家往往懈怠于事后補(bǔ)救的方式，我的建議是不要讓不符合約定的代碼流入代碼庫(kù)。對(duì)于遺留項(xiàng)目，尤其是大型項(xiàng)目，可以選擇一部分代碼作為實(shí)施范圍，集中修復(fù)Style問題后嚴(yán)格實(shí)施，切忌操之過急，最后團(tuán)隊(duì)疲憊不堪只得放棄。
我們都知道人工監(jiān)督檢查的方式是不可持續(xù)和不可靠的，來看看有哪些工具可以提供幫助吧。
三、懶惰是第一生產(chǎn)力
工程實(shí)踐不能沒有自動(dòng)化工具支持，在Java生態(tài)圈中，Code Style工具最出名的應(yīng)該是Checkstyle了，它可以通過XML形式的外部DSL來定義Code Style的檢查風(fēng)格，比如你可以從這里找到Google的Java Checkstyle配置文件。這里我不會(huì)詳細(xì)介紹Checkstyle本身，相反，我會(huì)更多地探討如何工程化地使用Checkstyle，在交付代碼的各個(gè)活動(dòng)中，我們都可以用到Checkstyle，進(jìn)行360°無死角的檢查。
(和Code Style相關(guān)的代碼交付生命周期)
1. 守住提交的質(zhì)量關(guān)口
為了貫徹不讓不符合約定的代碼流入代碼庫(kù)的決定，可以優(yōu)先在服務(wù)端設(shè)置Code Style的檢查關(guān)卡。
(優(yōu)先守住代碼提交時(shí)的服務(wù)端檢查，可以考慮使用CI服務(wù)器來實(shí)現(xiàn))
2. 從實(shí)現(xiàn)層面上說，有兩種方式：
一是在SCM(Source Control Management，例如Git/SVN)服務(wù)端設(shè)置檢查項(xiàng)，如果不達(dá)標(biāo)則拒絕提交，但這種方式相對(duì)不容易實(shí)現(xiàn)，而且一般SCM服務(wù)端也不由開發(fā)團(tuán)隊(duì)管理，設(shè)置起來不靈活也不方便。
二是利用持續(xù)集成服務(wù)器，開發(fā)團(tuán)隊(duì)的每一次提交都會(huì)觸發(fā)一次構(gòu)建，我們可以在構(gòu)建腳本中加入Checkstyle檢查，如果有不達(dá)標(biāo)的代碼則讓構(gòu)建失敗，以便告訴提交者立即修復(fù)Style問題。我更推薦這個(gè)方案，因?yàn)橄嚓P(guān)的工具支持都很成熟，實(shí)現(xiàn)簡(jiǎn)單，而且構(gòu)建過程可以在開發(fā)者的本地環(huán)境復(fù)制，以便在后續(xù)改進(jìn)中將Checkstyle檢查前移，提供更快的反饋。如果團(tuán)隊(duì)使用Maven/Gradle等構(gòu)建工具，可以用插件的方式實(shí)現(xiàn)Checkstyle檢查并嵌入到整個(gè)構(gòu)建過程中。這樣CI服務(wù)器只要調(diào)用構(gòu)建腳本就行了。
四、在開發(fā)者本地驗(yàn)證Style
(在開發(fā)者本地實(shí)現(xiàn)驗(yàn)證，反饋關(guān)口前移)
在實(shí)現(xiàn)了CI驗(yàn)證后，就可以著手實(shí)現(xiàn)開發(fā)者本地驗(yàn)證了，這樣開發(fā)者就不用等到提交代碼到服務(wù)端后才會(huì)獲得反饋了。由于之前采用的是構(gòu)建工具的插件方案，所以開發(fā)者在本地運(yùn)行構(gòu)建就能實(shí)現(xiàn)驗(yàn)證了。比如Gradle提供了Checkstyle插件支持，你可以在這里找到Gradle Checkstyle Plugin的詳細(xì)配置文檔，如果你使用Maven，則可以參考這里?，F(xiàn)在只需要一條命令，開發(fā)者久能在本地驗(yàn)證Code style了。(你也可以點(diǎn)擊左下角閱讀原文，查看完整的代碼示例)
本地驗(yàn)證很不錯(cuò)，但我有時(shí)候會(huì)忘記執(zhí)行。
(讓機(jī)器代勞瑣事)
有時(shí)候，開發(fā)者修改了代碼后會(huì)忘記執(zhí)行本地檢查就提交代碼了，最好能夠在提交代碼前自動(dòng)執(zhí)行檢查。如果你使用Git的話，可能會(huì)想到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的時(shí)候就會(huì)自動(dòng)觸發(fā)檢查了，如果檢查失敗則提交失敗。但問題是.git并不能提交到遠(yuǎn)程代碼倉(cāng)庫(kù)，那么除了人工分發(fā)和拷貝外，有沒有更好的方式在團(tuán)隊(duì)中共享這個(gè)機(jī)制呢?
可以曲線救國(guó)!把pre-commit納入版本控制(如下面的config/pre-commit)，再使用構(gòu)建工具的擴(kuò)展機(jī)制來自動(dòng)完成拷貝工作，這樣可以間接實(shí)現(xiàn)git hooks的團(tuán)隊(duì)間共享。
- # 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ù)時(shí)會(huì)自動(dòng)觸發(fā)installGitHooks任務(wù)
五、關(guān)閉包圍圈，編輯時(shí)反饋
(實(shí)時(shí)反饋)
之前基于構(gòu)建工具的方案都很好，但是對(duì)于開發(fā)者來說，最好能將反饋前移到編輯時(shí)，并且可視化。所幸的是，Checkstyle的生態(tài)系統(tǒng)非常成熟，各主流IDE都有插件支持，以Intellij Idea為例，可以使用checkstyle-idea插件，讓團(tuán)隊(duì)成員手工設(shè)置插件，使用項(xiàng)目的checkstyle配置文件即可(我目前還沒有找到自動(dòng)化配置的方式，或許gradle idea插件可以?)
(checkstyle-idea插件配置和效果)
有了自動(dòng)實(shí)時(shí)檢查，最好還能將IDE的自動(dòng)格式化與Checkstyle配置文件掛鉤，否則自動(dòng)格式化反倒給你添麻煩了。
(為IDE導(dǎo)入checkstyle配置文件作為自動(dòng)格式化的依據(jù))
如果你連自動(dòng)格式化都懶得按，那可以試試Save Actions插件，它可以在Intellij保存文件時(shí)自動(dòng)執(zhí)行代碼格式化等動(dòng)作。
(這個(gè)插件目前對(duì)部分文件有些問題，可以通過File path exclusion忽略)
六、總結(jié)
1、Code Style影響工作效率，團(tuán)隊(duì)?wèi)?yīng)將其當(dāng)做工程實(shí)踐予以重視。
2、Code Style不能靠人工監(jiān)督和檢查，應(yīng)該提供端到端的工具支持
- 開發(fā)環(huán)境檢查(使用各構(gòu)建工具的Checkstyle插件)
- 自動(dòng)提交檢查(git pre-commit hook與共享)
- IDE增強(qiáng)(checkstyle插件實(shí)時(shí)可視化反饋/自動(dòng)的自動(dòng)格式化!)
- 以上的工具都要依據(jù)為同一份Checkstyle配置文件，并納入版本控制
希望以上這些招數(shù)可以解救Java Code Style強(qiáng)迫癥。
【本文是專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
網(wǎng)頁(yè)標(biāo)題：拯救JavaCodeStyle強(qiáng)迫癥
本文地址：http://m.5511xx.com/article/dpoihcj.html
