本文向大家介紹Code Review的主要內容，以及流行的檢查Code Conventions的工具。同時，對于目前應用最為廣泛的CheckStyle的應用給出詳細的介紹，也列舉了很多使用CheckStyle的最佳實踐。
一、Code Review & Code Conventions
質量是衡量一個軟件是否成功的關鍵要素。而對于商業軟件系統，尤其是企業應用軟件系統來說，除了軟件運行質量、文檔質量以外，代碼的質量也是非常重要的。軟件開發進行到編碼階段的時候，最大的風險就在于如何保證代碼的易讀性和一致性，從而使得軟件的維護的代價不會很高。
在軟件開發的過程中，以下幾種情形隨處可見：
1) 軟件維護時間長，而且維護人員的積極性不高：
做過軟件維護的開發人員，尤其是在接手不是自己開發產品的源碼的時候，即使有良好的文檔說明，仍然會對代碼中冗長、沒有注釋的段落“嘆為觀止”。理解尚且如此困難，何況要修改或者增加新的功能。因此，很多開發人員不愿意進行軟件維護的工作。
2）新的開發人員融入團隊的時間比較長：
除了沒有良好的培訓、文檔等有效的機制以外，每個人一套的編碼風格，也容易造成新成員對于已有代碼的理解不夠，甚至出現偏差。
編碼規范，作為解決以上問題的方案已經得到了很長時間的應用。而在產品或者項目實際開發的過程中，僅有Code Conventions是不能解決Code的問題的。它往往和Code Review配合，作為代碼質量保證的手段。
1.1. Code Review的層次與內容
Code Review就是審查代碼的質量。根據形式分為兩種，一種是交叉代碼審查，就是自己的代碼由他人來檢查，就象檢查作業一樣；另一種是代碼會審，就是以會議的形式，大家共同審核代碼的質量。
Code Review 的目的有：
·在項目早期就能夠發現代碼中的BUG；
·幫助初級開發人員學習高級開發人員的經驗，達到知識共享；
·避免開發人員犯一些很常見，很普通的錯誤；
·保證項目組人員的良好溝通；
·項目或產品的代碼更容易維護；
一般情況下，Code Review的內容與層次如下：
·編碼風格與代碼規范一致性：檢查代碼是否符合編碼規范，確保所有人寫的代碼基本一致；
·代碼滿足基本的功能要求：檢查代碼的邏輯實現，以及單元測試的編寫策略，確認實現功能性需求；
·代碼滿足性能等非功能性需求：非功能性需求一般不便于測試，需要借助一定的工具和Review人員的素質，針對編碼中對于性能影響的瓶頸給出解決方案；
·去除冗余，提高代碼可讀性：適當使用 Refactorying技術，去除代碼中的Bad Smell；如果有需要，可以Refactorying to Pattern。
1.2. Code Conventions的尷尬境地
從Code Review的層次分析中我們可以看到，Code Conventions是其基礎。而實際的情況是，在軟件開發中，兩者都淪為“宣傳口號”，而非切實執行的實踐。
造成這種情形的原因有二：
1. Code Conventions是開發過程的“道德”而非“法律”：很多時候，由于沒有有效的工具或者輔助手段的支持，是否遵守編碼規范是依靠開發人員的“道德素養”－自覺遵守，而非實際考核的指標；
2. Code Review的基石不牢：在第一種原因的影響下，Code Review執行的過程中，如果花費了大量的時間在代碼規范的檢查上，那么對于更為重要的程序執行邏輯、性能、易讀性等的評審投入的精力就有限的；而這種情況反過來也使得對于編碼規范的檢查，通常都是走過場。最后，還是每個人一套規范，只要最終交付的產品完成指定的功能就可以啦。
二、CheckStyle
面對以上描述的Code Conventions的尷尬境地，陸續有開發人員提出了自己的解決方案。目前，對于JAVA的代碼規范的檢查，已經有很多成熟的工具，例如CheckStyle、PMD以及Jalopy等[3]。其中，CheckStyle的應用非常廣泛，眾多開源項目都使用它作為檢查代碼規范的工具，尤其是 Jakarta 的很多項目，例如Maven、 Torque等。
2.1. CheckStyle是什么？
CheckStyle是SourceForge下的一個項目，提供了一個幫助JAVA開發人員遵守某些編碼規范的工具。它能夠自動化代碼規范檢查過程，從而使得開發人員從這項重要，但是枯燥的任務中解脫出來[1]。
2.2. CheckStyle檢驗的主要內容
CheckStyle默認提供一下主要檢查內容：
·Javadoc注釋
·命名約定
·標題
·Import語句
·體積大小
·空白
·修飾符
·塊
·代碼問題
·類設計
·混合檢查（包活一些有用的比如非必須的System.out和printstackTrace）
從上面可以看出，CheckStyle提供了大部分功能都是對于代碼規范的檢查，而沒有提供象PMD和Jalopy那么多的增強代碼質量和修改代碼的功能。但是，對于團隊開發，尤其是強調代碼規范的公司來說，它的功能已經足夠強大。
2.3. CheckStyle的主要運行方式
目前，CheckStyle的版本是3.0，與以前的版本不同，它的配置文件是基于XML而非Properties文件。
它的3.0版本提供了兩種運行的方式：
·命令行工具
·ANT任務
同時，CheckStyle目前有很多針對流行IDE的插件，例如Eclipse、IntelliJ IDEA、JBuilder等。但是，大部分都是基于2.4的版本，新版本的特性不支持，同時配置也較為復雜。
因為一般情況下，如果與開發過程與環境集成起來，編碼規范的檢查會更加有效，因此，作為ANT任務的運行方式使用的更加普遍。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
