Code Review與CheckStyle
本文向大家介紹Code Review的主要內(nèi)容，以及流行的檢查Code Conventions的工具。同時，對于目前應(yīng)用最為廣泛的CheckStyle的應(yīng)用給出詳細的介紹，同時，也列舉了很多使用CheckStyle的最佳實踐。
1. Code Review & Code Conventions
質(zhì)量是衡量一個軟件是否成功的關(guān)鍵要素。而對于商業(yè)軟件系統(tǒng)，尤其是企業(yè)應(yīng)用軟件系統(tǒng)來說，除了軟件運行質(zhì)量、文檔質(zhì)量以外，代碼的質(zhì)量也是非常重要的。軟件開發(fā)進行到編碼階段的時候，最大的風(fēng)險就在于如何保證代碼的易讀性和一致性，從而使得軟件的維護的代價不會很高。
在軟件開發(fā)的過程中，以下幾種情形隨處可見：
1． 軟件維護時間長，而且維護人員的積極性不高：
做過軟件維護的開發(fā)人員，尤其是在接手不是自己開發(fā)產(chǎn)品的源碼的時候，即使有良好的文檔說明，仍然會對代碼中冗長、沒有注釋的段落“嘆為觀止”。理解尚且如此困難，何況要修改或者增加新的功能。因此，很多開發(fā)人員不愿意進行軟件維護的工作。
2． 新的開發(fā)人員融入團隊的時間比較長：
除了沒有良好的培訓(xùn)、文檔等有效的機制以外，每個人一套的編碼風(fēng)格，也容易造成新成員對于已有代碼的理解不夠，甚至出現(xiàn)偏差。
編碼規(guī)范，作為解決以上問題的方案已經(jīng)得到了很長時間的應(yīng)用。而在產(chǎn)品或者項目實際開發(fā)的過程中，僅有Code Conventions是不能解決Code的問題的。它往往和Code Review配合，作為代碼質(zhì)量保證的手段。
1.1. Code Review的層次與內(nèi)容
Code Review就是審查代碼的質(zhì)量。根據(jù)形式分為兩種，一種是交叉代碼審查，就是自己的代碼由他人來檢查，就象檢查作業(yè)一樣；另一種是代碼會審，就是以會議的形式，大家共同審核代碼的質(zhì)量。
Code Review 的目的有[2]：
2 在項目早期就能夠發(fā)現(xiàn)代碼中的BUG；
2 幫助初級開發(fā)人員學(xué)習(xí)高級開發(fā)人員的經(jīng)驗，達到知識共享；
2 避免開發(fā)人員犯一些很常見，很普通的錯誤；
2 保證項目組人員的良好溝通；
2 項目或產(chǎn)品的代碼更容易維護；
一般情況下，Code Review的內(nèi)容與層次如下：
2 編碼風(fēng)格與代碼規(guī)范一致性：檢查代碼是否符合編碼規(guī)范，確保所有人寫的代碼基本一致；
2 代碼滿足基本的功能要求：檢查代碼的邏輯實現(xiàn)，以及單元測試的編寫策略，確認實現(xiàn)功能性需求；
2 代碼滿足性能等非功能性需求：非功能性需求一般不便于測試，需要借助一定的工具和Review人員的素質(zhì)，針對編碼中對于性能影響的瓶頸給出解決方案；
2 去除冗余，提高代碼可讀性：適當(dāng)使用 Refactorying技術(shù)，去除代碼中的Bad Smell；如果有需要，可以Refactorying to Pattern。
1.2. Code Conventions的尷尬境地
從Code Review的層次分析中我們可以看到，Code Conventions是其基礎(chǔ)。而實際的情況是，在軟件開發(fā)中，兩者都淪為“宣傳口號”，而非切實執(zhí)行的實踐。
造成這種情形的原因有二：
1. Code Conventions是開發(fā)過程的“道德”而非“法律”：很多時候，由于沒有有效的工具或者輔助手段的支持，是否遵守編碼規(guī)范是依靠開發(fā)人員的“道德素養(yǎng)”－自覺遵守，而非實際考核的指標；
2. Code Review的基石不牢：在第一種原因的影響下，Code Review執(zhí)行的過程中，如果花費了大量的時間在代碼規(guī)范的檢查上，那么對于更為重要的程序執(zhí)行邏輯、性能、易讀性等的評審?fù)度氲木陀邢薜?；而這種情況反過來也使得對于編碼規(guī)范的檢查，通常都是走過場。最后，還是每個人一套規(guī)范，只要最終交付的產(chǎn)品完成指定的功能就可以啦。
2. CheckStyle
面對以上描述的Code Conventions的尷尬境地，陸續(xù)有開發(fā)人員提出了自己的解決方案。目前，對于JAVA的代碼規(guī)范的檢查，已經(jīng)有很多成熟的工具，例如CheckStyle、PMD以及Jalopy等[3]。其中，CheckStyle的應(yīng)用非常廣泛，眾多開源項目都使用它作為檢查代碼規(guī)范的工具，尤其是 Jakarta 的很多項目，例如Maven、 Torque等。
2.1. CheckStyle是什么？
CheckStyle是SourceForge下的一個項目，提供了一個幫助JAVA開發(fā)人員遵守某些編碼規(guī)范的工具。它能夠自動化代碼規(guī)范檢查過程，從而使得開發(fā)人員從這項重要，但是枯燥的任務(wù)中解脫出來[1]。
2.2. CheckStyle檢驗的主要內(nèi)容
CheckStyle默認提供一下主要檢查內(nèi)容：
2 Javadoc注釋
2 命名約定
2 標題
2 Import語句
2 體積大小
2 空白
2 修飾符
2 塊
2 代碼問題
2 類設(shè)計
2 混合檢查（包活一些有用的比如非必須的System.out和printstackTrace）
從上面可以看出，CheckStyle提供了大部分功能都是對于代碼規(guī)范的檢查，而沒有提供象PMD和Jalopy那么多的增強代碼質(zhì)量和修改代碼的功能。但是，對于團隊開發(fā)，尤其是強調(diào)代碼規(guī)范的公司來說，它的功能已經(jīng)足夠強大。
2.3. CheckStyle的主要運行方式
目前，CheckStyle的版本是3.0，與以前的版本不同，它的配置文件是基于XML而非Properties文件。
它的3.0版本提供了兩種運行的方式：
2 命令行工具
2 ANT任務(wù)
同時，CheckStyle目前有很多針對流行IDE的插件，例如Eclipse、IntelliJ IDEA、JBuilder等。但是，大部分都是基于2.4的版本，新版本的特性不支持，同時配置也較為復(fù)雜。
因為一般情況下，如果與開發(fā)過程與環(huán)境集成起來，編碼規(guī)范的檢查會更加有效，因此，作為ANT任務(wù)的運行方式使用的更加普遍。
在ANT的build.xml文件中添加CheckStyle任務(wù)的步驟如下：
1. 將checkstyle-all-3.1.jar拷貝到項目的LIB目錄；
2. 建立配置文件；
3. 聲明CheckStyle任務(wù)：
<taskdef resource="checkstyletask.properties"
classpath="${lib}/checkstyle-all-3.1.jar"/>
4. 建立CheckStyle任務(wù)：
<target name="checkstyle">
<checkstyle config="${config}/sun_checks.xml">
<fileset dir="${src}" includes=" **/*.java" />
</checkstyle>
</target>
2.4. 定制CheckStyle
CheckStyle的執(zhí)行基于XML配置文件，它的主要組成部分是：
2 Module：整個配置文件就是一棵Module樹。根節(jié)點是Checker Module。
2 Properties：它來決定一個Module如何進行檢查。每個Module都有一個默認值，如果不滿足開發(fā)需求，可以設(shè)定其它的值。
下面是一個示例：
<module name="MethodLength">
<property name="max" value="60"/>
</module>
它表示，如果方法或者構(gòu)造函數(shù)的長度超過60行，CheckStyle就會報錯。而默認值是150行。
以下是一段CheckStyle對于Maven項目源文件的檢查報告：
Method 'createExpression' is not designed for extension - needs to be abstract, final or empty. 91
Unable to get class information for JellyException. 91
Line has trailing spaces. 93
Line has trailing spaces. 104
Method 'evaluate' is not designed for extension - needs to be abstract, final or empty. 113
Parameter context should be final. 113
Line has trailing spaces. 130
Method 'getExpressionText' is not designed for extension - needs to be abstract, final or empty. 131
Line has trailing spaces. 134
Line has trailing spaces. 135
Method 'toString' is not designed for extension - needs to be abstract, final or empty. 137
Method 'isSupportAntVariables' is not designed for extension - needs to be abstract, final or empty. 156
Method 'setSupportAntVariables' is not designed for extension - needs to be abstract, final or empty. 168
Parameter supportAntVariables should be final. 168
'supportAntVariables' hides a field. 168
Method 'isValidAntVariableName' is not designed for extension - needs to be abstract, final or empty. 183
Parameter text should be final. 183
一般情況下，與IDE集成在一起使用的時候，點擊出錯的條目，可以跳轉(zhuǎn)到相應(yīng)的代碼。
3. CheckStyle的最佳實踐
3.1. Sun’s Code Conventions的修改
在CheckStyle的最新發(fā)布版本中，有一個對于Sun的Java編碼規(guī)范的配置文件信息。但是，其中有很多條目并不一定符合項目開發(fā)的需要。就算是對于很多優(yōu)秀的開源項目，按照這個規(guī)范來進行檢查，也會出現(xiàn)成千上萬的錯誤。
下面提出的一些修改意見，是從實際項目執(zhí)行過程中總結(jié)出來的，可以作為大家的參考。我們以CheckStyle3.0配置文件的順序來介紹：
1. 去除對于每個包都有一個package.html文件的限制；
<!--<module name="PackageHtml"/>-->
2. 修改對于JavaDoc Comments的限定：對于很多使用Code Generator的項目來說，需要將手寫代碼與生成代碼、單元測試代碼的檢查分開進行；
3. 修改對于體積大小的限制：目前，很多顯示器都是17寸，而且打印方面的限制也比以前有所改善，同時，由于代碼中Factory等模式的運用，以及有意義的方法名稱等約定，默認每行代碼的長度（80）是遠遠不能滿足要求；對于方法長度等等，也應(yīng)該根據(jù)項目情況自行決定：
<module name="FileLength"/>
<module name="LineLength">
<property name="max" value="120"/>
</module>
<module name="MethodLength">
<property name="max" value="300"/>
</module>
<module name="ParameterNumber"/>
4. 修改對于Throws的的限制：允許Throws Unchecked Exception以及Throws Subclass Of Another Declared Exception。
<module name="RedundantThrows">
<property name="allowUnchecked" value="true"/>
<property name="allowSubclasses" value="true"/>
</module>
5. 修改成員變量的可視性：一般情況下，應(yīng)該允許Protected Members以及Package Visible Members。
<module name="VisibilityModifier">
<property name="protectedAllowed" value="true"/>
<property name="packageAllowed" value="true"/>
</module>
3.2. CheckStyle應(yīng)用的最佳實踐
采用CheckStyle以后，編碼規(guī)范的檢查就變得及其簡單，可以作為一項切實可行的實踐加以執(zhí)行。
一般情況下，在項目小組中引入CheckStyle可以按照下面的步驟進行：
1． 強調(diào)Code Review與Code Conventions的重要作用；
2． 介紹CheckStyle；
3． 初步應(yīng)用CheckStyle：參照CheckStyle附帶的配置文件，酌情加以剪裁，在項目的Ant配置文件中，添加CheckStyle任務(wù)，可以單獨執(zhí)行；
4． 修改、定型CheckStyle的配置文件：按照基本配置文件執(zhí)行一段時間（2～3周），聽取開發(fā)人員的反饋意見，修改配置信息；
5． 作為開發(fā)過程的日常實踐，強制執(zhí)行CheckStyle：穩(wěn)定CheckStyle的配置信息，同時將CheckStyle任務(wù)作為Build的依賴任務(wù)或者配置源碼控制系統(tǒng)（目前，CheckStyle可以與
CVS有效集成），使得代碼在加入系統(tǒng)之前必須通過檢查。
同時需要指出的是，CheckStyle的有效執(zhí)行需要依賴兩個條件：
2 Ant的廣泛應(yīng)用：CheckStyle基于Ant執(zhí)行的方式比較容易，而且可以在項目內(nèi)容形成一致的執(zhí)行環(huán)境。同時，也比較容易與其它任務(wù)，例如Build等發(fā)生關(guān)聯(lián)。
2 IDE Format Code的強大功能：由于CheckStyle本身并沒有提供很強大的Code Format等功能，因此，需要借助IDE的幫助，從而使得在發(fā)生錯誤的時候，可以很容易的進行修復(fù)。目前，主流的Java IDE都提供了這方面的功能，IDEA在這方面尤其突出。它提供的統(tǒng)一、可定義的Code Format Template（項目小組內(nèi)部可以使用統(tǒng)一模板）以及方便的快捷鍵功能(Ctrl+Alt+T：Format Code, Ctrl+Alt+O：Optimize Import等)。
4. 結(jié)論
利用CheckStyle可以方便的對于編碼的Code Conventions進行檢查，同時，也有效地減少了Code Review的工作，使得Reviw人員的精力更多的集中到邏輯和性能檢查。
參考文獻：
[1] CheckStyle Project Website
[2] Code Review 理論與實戰(zhàn) CSDN
[3] 輕松有效檢查Java代碼的三個工具 ZDNet China