一些敏捷團隊在實施敏捷開發中忙于編碼、忙于UnitTest、忙于溝通、忙于Build等，雖然也有編碼審核階段，但大都浮于表面，流于形式，效果不佳。本文結合實踐，介紹筆者對敏捷開發中CodeReview的理解和相關經驗。

文/陳序明黃彥軍

敏捷開發中CodeReview的目的及內容

做任何事情，首先要清晰為什么要做，才能有目標和動力把事情做得更好，CodeReview也是如此。只有清晰明確了敏捷團隊進行CodeReview的動機，才能以此為方向開展后續工作。下面我們推薦的敏捷開發中常見的CodeReview的目的：

設計合理性Review

在筆者的另一篇文章中《敏捷開發中的架構設計》談到，敏捷開發中崇尚Codeisdesign，對開發人員提出了比以往更高的要求，即需要開發人員不斷地重構出合理的設計。所以敏捷開發中的CodeReview也需要承擔一部分“結對設計”和“設計把關”的職責。

這部分的CodeReview包括：設計的合理性（如實現方法，數據結構，設計模式，擴展性考慮等），是否存在大量重復代碼和其他組件是否有重復的代碼，包結構設計是否合理等。

筆者了解的一些項目中，進行敏捷開發后，提高了開發效率，但是設計的質量卻下降了。如RepeatYourself的現象（特別是跨組件之間的RepeatYourself現象）；更有甚者，在筆者看到一個某銀行的應用中（不是國內的），數據庫連接和操作是直接在JSP中寫SQL語句。

像這些BadDesign的例子還是很多的。這些在重構的時候應該由開發人員解決。但考慮到不同開發人員之間技術功底不一，很有必要在CodeReview階段進行Review和討論。

互為Backup

這是很容易被忽略，但是又很重要的一個CodeReview的目的。

我們知道，敏捷開發中強調高質量的代碼勝過詳細的文檔，所以某種程度上來說CodeisDocument。敏捷開發中的代碼承擔了一部分Document的職責，即傳遞技術的作用。

CodeReview中，Review的開發人員了解代碼的設計和實現，傳遞了技術，開發人員互為Backup，方便后期的維護，也減少了項目風險。

分享知識、設計、技術

這也是很容易被忽略的一個很重要的目的。敏捷開發是一個中央集中控制到個體發揮積極性的過程，中央集中控制的優點就是有統一的視圖和控制，經常開大會，開長會，這樣知識和經驗也較容易集中。敏捷開發中，分散在兩個ScrumTeam的開發人員之間，如果沒有好的機制，相互溝通也會相對較少，造成知識和好的經驗無法在整個團隊傳播。

筆者參加的項目中就碰到了類似情況，當時我們整個團隊分成三個ScrumTeam，其中一個ScrumTeam負責一個Eclipse工具的開發，其中用到的一些功能和知識在其他ScrumTeam上以前都有涉及過。當時負責開發的同事非常優秀而且能力突出，但由于不知道其他ScrumTeam同事有這方面的經驗，沒有很好地分享以往好的經驗和知識，以至于最后導致浪費了一些學習的成本。

CodeReview是一個學習和享受的過程，一個開發人員的能力有限，而CodeReview正是這樣的一種機制，讓好的知識、設計在團隊中分享，實現整體團隊的成長和整體的效益最大化。

代碼可讀性

如上所說，敏捷開發中強調高質量的代碼勝過冗余的文檔，所以Code某種程度上是Document。敏捷開發中，代碼的要求不止是能運行功能正確的代碼，而是有了更高的要求，即Codeformaintenance。

可維護的代碼，需要清晰，可讀性強，這里可讀性代碼檢查不是指代碼格式（代碼格式可以通過工具檢查出），而是指代碼語義。在筆者的文章《軟件可消費性設計》中有一些這方面的討論和建議。

Code中的“地雷區”Review

代碼中的邏輯，除了業務邏輯，還應該包括技術邏輯。技術邏輯就是實現邏輯，比如數據庫連接打開是否忘記關閉，是否正確使用線程，Exception處理，密碼是否加密存儲等。

我把這些最常出現錯誤的地方，而且是測試不容易發現的地方，稱為Code中的“地雷區”。這些“地雷區”在CodeReview中是值得花費一些時間進行維護和檢查的。

建議，在整個團隊中維護并共享“地雷區”注意事項列表，以及統一的處理方式和機制。并在編碼和CodeReview過程中都按照團隊的最佳實踐進行。

發現代碼中的業務邏輯錯誤

業務邏輯指的是代碼開發的功能是否符合業務需求，如一個加法函數，檢查其是否真的實現了加法的功能。

筆者了解的一些敏捷團隊中，把發現代碼的業務邏輯錯誤當做目標和內容，但往往效果都不是很好，基本都是從形式上泛泛檢查一番。原因有兩個：

1．業務邏輯的檢查是從需求到代碼的全方位檢查，需要花費大量時間，投入產出比失衡。

2．業務邏輯的檢查和業務需求緊密關聯，已經超出了檢查人員的能力范圍（一般CodeReview是開發人員，不是業務人員）。

筆者認為，發現邏輯錯誤，不應該是CodeReview的目的和內容。應該是UnitTest，功能測試，集成測試的目的。從投入產出比考慮，不應該花費太多時間在CodeReview階段去進行邏輯錯誤檢查。

敏捷開發中不推薦的CodeReview的目的及內容

下面還有一些常見的CodeReview目的和內容被很多團隊廣泛使用，但作者認為這些并不是敏捷開發中的主要目的和內容，團隊應該把時間花費在重要的目的和內容上，而不應該投入精力在下面的這些CodeReview目的和內容上。

發現性能問題

有些團隊把性能問題，也作為CodeReview的目的和內容之一，然后提出一些如String應該使用StringBuilder，而不能使用+，類似這樣的看似有用其實無用建議。

筆者認為，性能問題是需要量化的衡量和精確定位，很難通過CodeReview檢查出來。而一些粗淺的性能問題可以通過一些工具方便地掃描出來，而無須花費時間去進行CodeReview。

如圖1是RADV7.0(IBMRationalApplicationDeveloper)中的SoftwareAnalyzer工具帶有的Performance檢查：

圖1 RAD Software Analyzer中的Performance檢查

所以筆者認為，開發人員提交的代碼，需要是經過工具檢查后的代碼。而代碼審核人員則無須花費時間在性能相關的CodeReview上。具體的性能問題交給性能測試。

發現開源的授權法律問題

開源軟件也可以借助一些檢查工具，統一通過工具掃描，無需在CodeReview階段花費時間。

其他問題，如國際化，J2EEBestPractice等

這些問題開發人員可以在提交代碼之前通過工具發現和解決，不是CodeReview階段的職責和目的，也無須花費時間去處理。

像FindBugs和RAD這樣的工具就具備類似的代碼檢查功能，如RADV7.0中的SoftwareAnalyzer工具帶有如下的檢查功能：

圖2 RAD Software Analyzer中檢查規則列表

1．設計原則（5）：用于面向對象編程的設計原則的規則。

2．全球化（47）：基于全球化編碼最佳實踐的規則，有助于確保代碼在局部環境中正確地運行。

3．J2EE最佳實踐（32）：基于最佳的Java™2PlatformEnterpriseEdition（J2EE）開發實踐的規則，以及支持瞄準IBM?WebSphere?服務的Web項目的規則；

4．J2EE安全性（17）：驗證代碼符合J2EE技術安全性需要的規則；

5．J2SE最佳實踐（71）：基于最佳的Java™2PlatformStandardEdition（J2SE）開發實踐的規則；

6．J2SE安全性（9）：驗證代碼符合J2SE技術安全性需要的規則；

7．命名（2）：關于Java代碼中命名約定的規則；

8．性能（26）：加強在Java應用程序中提高性能和減少存儲器足跡的建議的規則；

9．私有API（3）：定位那些不屬于Java代碼的API的規則。

敏捷開發中如何開展CodeReview

在清晰明確了敏捷團隊進行CodeReview的目的和內容后，下面介紹如何有效地開展CodeReview。

溝通、協作、互助、學習的團隊氛圍

CodeReview中，Review人員和開發人員不是對立的關系，而是互助、溝通、協作和學習的過程。團隊形成互助、互學的氣氛，既能互相增長團隊的知識和經驗，還能把產品做得更好。

CodeReview協作過程：

a）先由代碼的開發人員向檢查人員進行大體的介紹，包括設計思想、數據結構、程序代碼結構介紹等。

b）雙方進行討論、交流。

c）檢查人員單獨進一步進行CodeReview，并記錄Review結果和建議。

d）由檢查人員和開發人員一起，檢查人員反饋CodeReview結果，并和開發人員一起討論改進方法，重構。

e）最后把可重用的CodeReview的經驗總結編碼規范，或者記錄到“地雷區”中。便于整個團隊復用經驗。

圖3 Code Review是溝通、協作、互助和學習的過程

開展以上過程可以以開發人員為主，輔助以工具。但無須規定系列的文檔、流程、CheckList等，這反而會影響開發人員的積極性。

CodeReview是發現問題的過程，同時也是學習和交流過程。需要是靈活、自由、主動的態度，而不是行政上的控制和規章流程。筆者建議：和敏捷開發的核心思想一致，讓團隊明確CodeReview的思想、作用和目的內容后，充分發揮個體的積極性和學習分享的動力。隨時隨地地進行CodeReview，討論，重構，改進。

增量式Review

大家都知道，軟件開發中存在長鞭效應，即一個問題越在后期發現造成的影響會越大，CodeReview也是

如此，如圖4所示：

圖 4 Code Review中的長鞭效應

軟件的開發過程中，應該階段性地進行CodeReview，而不是等到所有代碼都開發完畢后再做一次性的CodeReview。那時如果發現問題，造成的改動成本比增量式的檢查來的大得多。

筆者了解的一些開發團隊，他們在軟件開發完畢，并測試后，才臨時確定CodeReview的人員，然后再安排半天左右的時間進行CodeReview。結果盡管發現一些結構或設計方面問題，但由于修改成本大，也無法進行改進。

正確的方式是，在早期就參與設計開發過程，抱著互助、溝通、協作、學習的思想，階段性的參與討論、學習并貢獻自己的意見。具體Review的頻率、次數則可以由開發人員抱著主動、積極的態度，按照敏捷的思想自己去把握決定。

利用工具進行CodeInspection

有很多的工具可以輔助CodeReview：

1．如代碼格式檢查Checkstyle工具，檢查如過大的類、太長的方法和未使用的變量等這樣違反編程規范的問題。

2．RAD中的SoftwareAnalyzer工具，可以基于規則進行國際化、J2EE最佳實踐、性能、安全等檢查。3．CSAR，用于掃描代碼檢查開源軟件等。

4．JDepend，可以檢查包依賴關系。

5．CPD工具，Eclipse的PMD插件提供了一項叫做CPD（或復制粘貼探測器）的功能，用于尋找重復的代碼。

6．Eclipse的Metrics插件，提供了很多有效地查出代碼復雜度的功能。

輔助以工具和自動化流程，能花很少時間輕松完成很多基本的CodeInspection工作。讓團隊有更多的時間和精力去做更重要的CodeReview。

持續自動化CodeInspection

工具檢查可以由開發人員自行檢查并修正，但一種更可持續的做法是自動化的集成工具進行CodeInspection，可以通過自動化腳本在每日進行Build前進行掃描，并呈現報告給相應人員。

CodeReview協作工具

為了快速有效地進行人工CodeReview協作，可以使用諸如Jupiter這樣的工具輔助進行。可以幫助開發人員有效管理CodeReview任務、問題、建議等。

總結

CodeReview的核心是：互助，溝通，協作，學習的過程，這是一個美妙而享受的過程，是跨越需求分析、架構設計、編碼等各階段的過程。敏捷團隊應該統一達成CodeReview對產品、對團隊、對個人的巨大好處的共識，發揮出個體的積極性，相信會改變“流于形式”的現狀，發揮CodeReview巨大的威力。

總結

以上是生活随笔為你收集整理的敏捷开 发中Code Review的目的及内容的全部內容，希望文章能夠幫你解決所遇到的問題。

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