CodeReview理論與實戰(zhàn)

摘要

CodeReview是一種通過復(fù)查代碼提高代碼質(zhì)量的過程，在XP方法中占有極為重要的地位，也已經(jīng)成為軟件工程中一個不可缺少的環(huán)節(jié)。本文通過對CodeReview的一些概念和經(jīng)驗的探討，就如何進(jìn)行CodeReview和CodeReview中應(yīng)該注意什么提出一些建議。本文中涉及的問題大部分針對JAVA類代碼。同時本文不涉及CodeReview過程和組織。

關(guān)鍵詞：CodeReview，JAVA，XP，代碼質(zhì)量，軟件工程

一、CodeReview簡介

1CodeReview的目的

凡事知其然還要知其所以然，我們首先需要知道什么是CodeReview和我們使用它的目的是什么。CodeReview是一種用來確認(rèn)方案設(shè)計和代碼實現(xiàn)的質(zhì)量保證機(jī)制，通過這個機(jī)制我們可以對代碼，測試過程和注釋進(jìn)行檢查。CodeReview主要用來在軟件工程過程中改進(jìn)代碼質(zhì)量，通過CodeReview可以達(dá)到如下目的：

1，盡早地發(fā)現(xiàn)bug;

這里并不是指一些簡單的bug，而是一些可能是因為經(jīng)驗上不足而出現(xiàn)的潛在的bug。因此codereview人員一定是要比較有經(jīng)驗的人擔(dān)當(dāng)。

2，幫助初級開發(fā)人員學(xué)習(xí)高級開發(fā)人員的經(jīng)驗，以達(dá)到知識共享;

這點也很重要，使得小組成員不斷地進(jìn)步，這樣才能更有效地工作。

3，保證項目組成員有良好的溝通;

codereview人員起著小組溝通橋梁的作用，而不是去熟悉每個單元代碼，而去調(diào)試、編譯等工作，那樣還不如自己去寫整個系統(tǒng)。

4，項目或產(chǎn)品的代碼更容易維護(hù);

這里就是檢查代碼規(guī)范、代碼注釋等。使得代碼盡量統(tǒng)一化，最理想的效果是看不出是哪個具體人寫的，而是哪個Team寫的。

5，避免開發(fā)人員犯一些很常見，很普通的錯誤

2CodeReview的前提

知道了CodeReview的目的，我們就可以看看如何做CodeReview了，但在做CodeReview前我們還有事要做，所謂預(yù)則立，不預(yù)則廢，就是說如果在進(jìn)入CodeReview之前我們不做些準(zhǔn)備工作，CodeReview很容易就變得沒有意義或是流于形式，這在我們周圍是有很多例子的啊。進(jìn)入CodeReview需要檢查的條件如下：

a)CodeReview人員是否理解了CodeReview的概念和CodeReview將做什么

如果做CodeReview的人員不能理解CodeReview對項目成敗和代碼質(zhì)量的重要程度，他們的做法可能就會是應(yīng)付了事。

b)代碼是否已經(jīng)正確的build，build的目的使得代碼已經(jīng)不存在基本語法錯誤

我們總不希望高級開發(fā)人員或是主管將時間浪費在檢查連編譯都通不過的代碼上吧。

c)代碼執(zhí)行時功能是否正確

CodeReview人員也不負(fù)責(zé)檢查代碼的功能是否正確，也就是說，需要復(fù)查的代碼必須由開發(fā)人員或質(zhì)量人員負(fù)責(zé)該代碼的功能的正確性。

d)Review人員是否理解了代碼

做復(fù)查的人員需要對該代碼有一個基本的了解，其功能是什么，是拿一方面的代碼，涉及到數(shù)據(jù)庫或是通訊，這樣才能采取針對性的檢查

e)開發(fā)人員是否對代碼做了單元測試

這一點也是為了保證CodeReview前一些語法和功能問題已經(jīng)得到解決，CodeReview人員可以將精力集中在代碼的質(zhì)量上。

3CodeReview需要做什么

好了，進(jìn)入條件準(zhǔn)備好了，有人在這些條件中看到CodeReview這也不負(fù)責(zé)，那也不檢查，不禁會問，CodeReview到底做什么？其實CodeReview主要檢查代碼中是否存在以下方面問題：代碼的一致性、編碼風(fēng)格、代碼的安全問題、代碼冗余、是否正確設(shè)計以滿足需求（性能、功能等等），下邊我們一一道來。以下內(nèi)容參考了《SoftwareQualityAssurance:DocumentationandReviews》一文中的代碼檢查部分。

3．1完整性檢查（Completeness）

代碼是否完全實現(xiàn)了設(shè)計文檔中提出的功能需求

代碼是否已按照設(shè)計文檔進(jìn)行了集成和Debug

代碼是否已創(chuàng)建了需要的數(shù)據(jù)庫,包括正確的初始化數(shù)據(jù)

代碼中是否存在任何沒有定義或沒有引用到的變量、常數(shù)或數(shù)據(jù)類型

3．2一致性檢查（Consistency）

代碼的邏輯是否符合設(shè)計文檔

代碼中使用的格式、符號、結(jié)構(gòu)等風(fēng)格是否保持一致

3．3正確性檢查（Correctness）

代碼是否符合制定的標(biāo)準(zhǔn)

所有的變量都被正確定義和使用

所有的注釋都是準(zhǔn)確的

所有的程序調(diào)用都使用了正確的參數(shù)個數(shù)

3．4可修改性檢查（Modifiability）

代碼涉及到的常量是否易于修改(如使用配置、定義為類常量、使用專門的常量類等)

代碼中是否包含了交叉說明或數(shù)據(jù)字典，以描述程序是如何對變量和常量進(jìn)行訪問的

代碼是否只有一個出口和一個入口（嚴(yán)重的異常處理除外）

3．5可預(yù)測性檢查（Predictability）

代碼所用的開發(fā)語言是否具有定義良好的語法和語義

是否代碼避免了依賴于開發(fā)語言缺省提供的功能

代碼是否無意中陷入了死循環(huán)

代碼是否是否避免了無窮遞歸

3．6健壯性檢查（Robustness）

代碼是否采取措施避免運行時錯誤（如數(shù)組邊界溢出、被零除、值越界、堆棧溢出等）

3．7結(jié)構(gòu)性檢查（Structuredness）

程序的每個功能是否都作為一個可辯識的代碼塊存在

循環(huán)是否只有一個入口

3．8可追溯性檢查（Traceability）

代碼是否對每個程序進(jìn)行了唯一標(biāo)識

是否有一個交叉引用的框架可以用來在代碼和開發(fā)文檔之間相互對應(yīng)

代碼是否包括一個修訂歷史記錄，記錄中對代碼的修改和原因都有記錄

是否所有的安全功能都有標(biāo)識

3．9可理解性檢查（Understandability）

注釋是否足夠清晰的描述每個子程序

是否使用到不明確或不必要的復(fù)雜代碼，它們是否被清楚的注釋

使用一些統(tǒng)一的格式化技巧（如縮進(jìn)、空白等）用來增強(qiáng)代碼的清晰度

是否在定義命名規(guī)則時采用了便于記憶，反映類型等方法

每個變量都定義了合法的取值范圍

代碼中的算法是否符合開發(fā)文檔中描述的數(shù)學(xué)模型

3．10可驗證性檢查(Verifiability)

代碼中的實現(xiàn)技術(shù)是否便于測試

二、CodeReview經(jīng)驗檢查項

以下是在實踐中建立的檢查列表（checklist），通過分類和有針對性的檢查項，保證了CodeReview可以有的放矢。

1JAVA編碼規(guī)范方面檢查項

檢查項參照J(rèn)AVA編碼規(guī)范執(zhí)行，見《JAVA編碼規(guī)范(JavaCodeConventions)》

2面向?qū)ο笤O(shè)計方面檢查項

這幾點的范圍都很大，不可能在本文展開討論，有專門的書籍介紹這方面問題，當(dāng)然在CodeReview中主要靠經(jīng)驗來判斷。

A)類設(shè)計和抽象是否合適

B)是否符合面向接口編程的思想

C)是否采用合適的設(shè)計范式

3性能方面檢查項

性能檢查在大多數(shù)代碼中都是需要嚴(yán)重關(guān)注的方面，也是最容易出現(xiàn)問題的方面，常常有程序員寫出了功能和語法沒有絲毫問題的代碼后，正式運行時卻在性能上表現(xiàn)不佳，從而不得不做大量的返工，甚至是推倒重來。

A)在海量數(shù)據(jù)出現(xiàn)時,隊列,表,文件,在傳輸,upload等方面是否會出現(xiàn)問題,有無控制,如分配的內(nèi)存塊大小,隊列長度等控制參數(shù)

B)對hashtable,vector等集合類數(shù)據(jù)結(jié)構(gòu)的選擇和設(shè)置是否合適，如正確設(shè)置capacity,loadfactor等參數(shù)，數(shù)據(jù)結(jié)構(gòu)的是否是同步的

C)有無濫用String對象的現(xiàn)象

D)是否采用通用的線程池、對象池模塊等cache技術(shù)以提高性能

E)類的接口是否定義良好，如參數(shù)類型等，避免內(nèi)部轉(zhuǎn)換

F)是否采用內(nèi)存或硬盤緩沖機(jī)制以提高效率

G)并發(fā)訪問時的應(yīng)對策略

H)I/O方面是否使用了合適的類或采用良好的方法以提高性能（如減少序列化，使用buffer類封裝流等）

I)同步方法的使用是否得當(dāng),是否過度使用

J)遞歸方法中的疊代次數(shù)是否合適，應(yīng)該保證在合理的棧空間范圍內(nèi)

K)如果調(diào)用了阻塞方法，是否考慮了保證性能的措施

L)避免過度優(yōu)化，對性能要求高的代碼是否使用profile工具，如Jprobe等

4資源泄漏處理方面檢查項

對于JAVA來說由于存在垃圾收集機(jī)制，所以內(nèi)存泄漏不是太明顯，但使用不當(dāng)，仍然存在內(nèi)存泄漏的問題。而對于其它的語言，如C++等在這方面就要嚴(yán)重關(guān)注了。當(dāng)然數(shù)據(jù)庫連接資源不釋放的問題也是廣大程序員最常見的，相信有很多的PM被這個問題折磨的死去活來。

A)分配的內(nèi)存是否釋放，尤其在錯誤處理路徑上（對非JAVA類）

B)錯誤發(fā)生時是否所有的對象被釋放，如數(shù)據(jù)庫連接、Socket、文件等

C)是否同一個對象被釋放多次（對非JAVA類）

D)代碼是否保存準(zhǔn)確的對象reference計數(shù)（對非JAVA類）

5線程安全方面檢查項

線程安全問題實際涉及兩個方面，一個是性能，另一個是資源的一致性，我們需要在這兩方面做個權(quán)衡，現(xiàn)在就是到了權(quán)衡利弊的時候了。

A)代碼中所有的全局變量是否是線程安全的

B)需要被多個線程訪問的對象是否線程安全，檢查有無通過同步方法保護(hù)

C)同步對象上的鎖是否按相同的順序獲得和釋放以避免死鎖，注意錯誤處理代碼

D)是否存在可能的死鎖或是競爭，當(dāng)用到多個鎖時，避免出現(xiàn)類似情況：線程A獲得鎖1，然后鎖2，線程B獲得鎖2，然后鎖1

E)在保證線程安全的同時，要注意避免過度使用同步，導(dǎo)致性能降低

6程序流程方面檢查項

A)循環(huán)結(jié)束條件是否準(zhǔn)確

B)是否避免了死循環(huán)的產(chǎn)生

C)對循環(huán)的處理是否合適，如循環(huán)變量，局部對象，循環(huán)次數(shù)等能夠考慮到性能方面的影響

7數(shù)據(jù)庫處理方面

很多CodeReview人員在面對代碼中涉及到的數(shù)據(jù)庫可移植性和提高數(shù)據(jù)庫性能方面的沖突時表現(xiàn)的無所適從，凡事很難兩全其美的啊。

A)數(shù)據(jù)庫設(shè)計或SQL語句是否便于移植（注意和性能方面會存在沖突）

B)數(shù)據(jù)庫資源是否正常關(guān)閉和釋放

C)數(shù)據(jù)庫訪問模塊是否正確封裝，便于管理和提高性能

D)是否采用合適的事務(wù)隔離級別

E)是否采用存儲過程以提高性能

F)是否采用PreparedStatement以提高性能

8通訊方面檢查項

A)socket通訊是否存在長期阻塞問題

B)發(fā)送接收的數(shù)據(jù)流是否采用緩沖機(jī)制

C)socket超時處理，異常處理

D)數(shù)據(jù)傳輸?shù)牧髁靠刂茊栴}

9JAVA對象處理方面檢查項

這個檢查項的基礎(chǔ)是對JAVA對象有較深的理解，但現(xiàn)實是很多看過《ThinkinginJava》的程序員，仍然在程序中無法區(qū)分傳值和傳引用，以及對象和reference的區(qū)別。這或許就是理論和實踐難以結(jié)合的問題啊。正所謂知而不行，非真知也。

A)對象生命周期的處理,是否對象的reference已經(jīng)失效,能夠設(shè)置為null,并被回收

B)在對象的傳值和傳參方面有無問題,對象的clone方法使用是否過度

C)是否大量經(jīng)常的創(chuàng)建臨時對象

D)是否盡量使用局部對象(堆棧對象)

E)在只需要對象reference的地方是否創(chuàng)建了新的對象實例

10異常處理方面檢查項

JAVA中提供了方便的異常處理機(jī)制，但普遍存在的是異常被捕獲，但并沒有得到處理。我們可以打開一段代碼，最常見的現(xiàn)象是進(jìn)入某個方法后，一個大的try/catch將所有代碼行括住，然后在catch中將異常打印到控制臺，而且該異常是Exception對象。

A)每次當(dāng)方法返回時是否正確處理了異常，如最簡單的處理，記錄日志到日志文件中

B)是否對數(shù)據(jù)的值和范圍是否合法進(jìn)行校驗，包括采用斷言（assertion）

C)在出錯路徑上是否所有的資源和內(nèi)存都已經(jīng)釋放

D)所有拋出的異常都得到正確的處理，特別是對子方法拋出的異常，在整個調(diào)用棧中必須能夠被捕捉并處理

E)當(dāng)調(diào)用導(dǎo)致錯誤發(fā)生時，方法的調(diào)用者應(yīng)該得到一個通知

F)不要忘了對錯誤處理部分的代碼進(jìn)行測試，很多代碼在正常情況下執(zhí)行良好，而一旦出錯，整個系統(tǒng)就崩潰了

11方法（函數(shù)）方面檢查項

A)方法的參數(shù)是否都做了校驗

B)數(shù)組類結(jié)構(gòu)是否做了邊界校驗

C)變量在使用前是否做了初始化

D)返回堆對象的reference，不要返回棧對象的reference

E)方法API是否被良好定義，即是否盡量面向接口編程，便于維護(hù)和重構(gòu)

12安全方面檢查項

A)對命令行執(zhí)行的代碼，需要詳細(xì)檢查命令行參數(shù)

B)WEB類程序檢查是否對訪問參數(shù)進(jìn)行合法性驗證

C)重要信息的保存是否選用合適的加密算法

D)通訊時考慮是否選用安全的通訊方式

13其他

A)日志是否正常輸出和控制

B)配置信息如何獲得,是否有硬編碼

三、總結(jié)

通過在項目中實施CodeReview將為我們帶來多方面的好處，表現(xiàn)在提高代碼質(zhì)量，保證項目或產(chǎn)品的穩(wěn)定性，開發(fā)經(jīng)驗的積累等，具體的實施當(dāng)然也要看項目的實際情況，因為CodeReview也是需要成本的，這方面屬于CodeReview過程的問題，將在其他文章中進(jìn)行探討。

四、參考資料

Java語言編碼規(guī)范(JavaCodeConventions)SUN

SoftwareQualityAssurance:DocumentationandReviewsDoloresR.Wallace,WendyW.Peng,LauraM.Ippolito