Code Review?是一種通過復查代碼提高代碼質量的過程，在XP方法中占有極為重要的地位，也已經成為軟件工程中一個不可缺少的環節。

本文通過對Code Review的一些概念和經驗的探討，就如何進行Code Review和Code Review中應該注意什么提出一些建議。

本文中涉及的問題大部分針對Java類代碼。同時本文不涉及Code Review過程和組織。

關鍵詞：?Code Review?? JAVA??? 代碼質量?? 軟件工程

一、Code Review簡介

1 Code Review的目的

凡事知其然還要知其所以然，我們首先需要知道什么是Code Review和我們使用它的目的是什么。

Code Review是一種用來確認方案設計和代碼實現的質量保證機制，通過這個機制我們可以對代碼、測試過程和注釋進行檢查。

Code Review主要用來在軟件工程過程中改進代碼質量，通過Code Review可以達到如下目的：

• 在項目早期就能夠發現代碼中的BUG
• 幫助初級開發人員學習高級開發人員的經驗，達到知識共享
• 避免開發人員犯一些很常見，很普通的錯誤
• 保證項目組人員的良好溝通
• 項目或產品的代碼更容易維護

2 Code Review的前提

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

Code Review人員是否理解了Code Review的概念和Code Review將做什么

如果做Code Review的人員不能理解Code Review對項目成敗和代碼質量的重要程度，他們的做法可能就會是應付了事。

代碼是否已經正確的build，build的目的使得代碼已經不存在基本語法錯誤

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

代碼執行時功能是否正確

Code Review人員也不負責檢查代碼的功能是否正確，也就是說，需要復查的代碼必須由開發人員或質量人員負責該代碼的功能的正確性。

Review人員是否理解了代碼

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

開發人員是否對代碼做了單元測試

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

3 Code Review需要做什么

好了，進入條件準備好了，有人在這些條件中看到Code Review這也不負責，那也不檢查，不禁會問，Code Review到底做什么？

其實Code Review主要檢查代碼中是否存在以下方面問題：代碼的一致性、編碼風格、代碼的安全問題、代碼冗余、是否正確設計以滿足需求（性能、功能）等等

下邊我們一一道來。以下內容參考了《Software Quality Assurance: Documentation and Reviews》一文中的代碼檢查部分。

3.1 完整性檢查（Completeness）

• 代碼是否完全實現了設計文檔中提出的功能需求
• 代碼是否已按照設計文檔進行了集成和Debug
• 代碼是否已創建了需要的數據庫，包括正確的初始化數據
• 代碼中是否存在任何沒有定義或沒有引用到的變量、常數或數據類型

3.2 一致性檢查（Consistency）

• 代碼的邏輯是否符合設計文檔
• 代碼中使用的格式、符號、結構等風格是否保持一致

3.3 正確性檢查（Correctness）

• 代碼是否符合制定的標準
• 所有的變量都被正確定義和使用
• 所有的注釋都是準確的
• 所有的程序調用都使用了正確的參數個數

3.4 可修改性檢查（Modifiability）

• 代碼涉及到的常量是否易于修改(如使用配置、定義為類常量、使用專門的常量類等)
• 代碼中是否包含了交叉說明或數據字典，以描述程序是如何對變量和常量進行訪問的
• 代碼是否只有一個出口和一個入口（嚴重的異常處理除外）

3.5 可預測性檢查（Predictability）

• 代碼所用的開發語言是否具有定義良好的語法和語義
• 是否代碼避免了依賴于開發語言缺省提供的功能
• 代碼是否無意中陷入了死循環
• 代碼是否是否避免了無窮遞歸

3.6 健壯性檢查（Robustness）

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

3.7 結構性檢查（Structuredness）

• 程序的每個功能是否都作為一個可辯識的代碼塊存在
• 循環是否只有一個入口

3.8 可追溯性檢查（Traceability）

• 代碼是否對每個程序進行了唯一標識
• 是否有一個交叉引用的框架可以用來在代碼和開發文檔之間相互對應
• 代碼是否包括一個修訂歷史記錄，記錄中對代碼的修改和原因都有記錄
• 是否所有的安全功能都有標識

3.9 可理解性檢查（Understandability）

• 注釋是否足夠清晰的描述每個子程序
• 是否使用到不明確或不必要的復雜代碼，它們是否被清楚的注釋
• 使用一些統一的格式化技巧（如縮進、空白等）用來增強代碼的清晰度
• 是否在定義命名規則時采用了便于記憶，反映類型等方法
• 每個變量都定義了合法的取值范圍
• 代碼中的算法是否符合開發文檔中描述的數學模型

3.10 可驗證性檢查(Verifiability)

• 代碼中的實現技術是否便于測試

二、Code Review經驗檢查項

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

1 JAVA編碼規范方面檢查項

• 檢查項參照JAVA編碼規范執行，見《Java語言編碼規范(Java Code Conventions)》

2 面向對象設計方面檢查項

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

類設計和抽象是否合適

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

是否采用合適的設計范式

3 性能方面檢查項性能檢查

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

在海量數據出現時，隊列、表、文件，在傳輸、upload等方面是否會出現問題,有無控制，如分配的內存塊大小、隊列長度等控制參數

對hashtable,vector等集合類數據結構的選擇和設置是否合適，如正確設置capacity、load factor等參數，數據結構的是否是同步的

有無濫用String對象的現象

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

類的接口是否定義良好，如參數類型等、避免內部轉換

是否采用內存或硬盤緩沖機制以提高效率

并發訪問時的應對策略

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

同步方法的使用是否得當,是否過度使用

遞歸方法中的疊代次數是否合適，應該保證在合理的棧空間范圍內

如果調用了阻塞方法，是否考慮了保證性能的措施

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

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

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

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

錯誤發生時是否所有的對象被釋放，如數據庫連接、Socket、文件等

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

代碼是否保存準確的對象reference計數（對非JAVA類）

5 線程安全方面檢查項

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

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

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

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

?是否存在可能的死鎖或是競爭，當用到多個鎖時，避免出現類似情況：線程A獲得鎖1、然后鎖2、線程B獲得鎖2、然后鎖1

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

6 程序流程方面檢查項

循環結束條件是否準確

是否避免了死循環的產生

對循環的處理是否合適，如循環變量、局部對象、循環次數等能夠考慮到性能方面的影響

7 數據庫處理方面

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

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

數據庫資源是否正常關閉和釋放

數據庫訪問模塊是否正確封裝，便于管理和提高性能

是否采用合適的事務隔離級別

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

是否采用PreparedStatement以提高性能

8 通訊方面檢查項

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

發送接收的數據流是否采用緩沖機制

socket超時處理，異常處理

數據傳輸的流量控制問題

9 JAVA對象處理方面檢查項

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

對象生命周期的處理,是否對象的reference已經失效,能夠設置為null,并被回收

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

是否大量經常的創建臨時對象

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

在只需要對象reference的地方是否創建了新的對象實例

10 異常處理方面檢查項

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

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

是否對數據的值和范圍是否合法進行校驗，包括采用斷言（assertion）

在出錯路徑上是否所有的資源和內存都已經釋放

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

當調用導致錯誤發生時，方法的調用者應該得到一個通知

不要忘了對錯誤處理部分的代碼進行測試，很多代碼在正常情況下執行良好，而一旦出錯，整個系統就崩潰了

11 方法（函數）方面檢查項

方法的參數是否都做了校驗

數組類結構是否做了邊界校驗

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

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

方法API是否被良好定義，即是否盡量面向接口編程、便于維護和重構

12 安全方面檢查項

對命令行執行的代碼，需要詳細檢查命令行參數

web類程序檢查是否對訪問參數進行合法性驗證

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

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

13 其他

日志是否正常輸出和控制

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

三、總結

通過在項目中實施Code Review將為我們帶來多方面的好處，表現在提高代碼質量，保證項目或產品的穩定性，開發經驗的積累等，具體的實施當然也要看項目的實際情況，因為 Code Review也是需要成本的，這方面屬于Code Review過程的問題，將在其他文章中進行探討。

from:?http://blog.csdn.net/ithomer/article/details/6147178

總結

以上是生活随笔為你收集整理的什么是Code Review 代码审查的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。