CodeReview（代碼審查）

這周在公司一直給同事做CodeReview，感覺還是比較痛苦的，因為一些機制并不是很人性化，至少說，流程上有一些不成熟的環節。和大家一起分享，希望有經驗的朋友給我一下批評建議。

代碼審查（Code review）是指對計算機源代碼系統化地審查，常用軟件同行評審的方式進行，其目的是在找出及修正在軟件開發初期未發現的錯誤，提升軟件質量...

方案1：Review Meeting，即Online Review。
基本不可行。很大程度上依賴于主持者的素質，而且如果主持者不積極，就會流于形式。此外時間成本過高，為reviewer+owner的時間總和。倒是可以將其改造為Team內部新技術新觀點的交流Meeting，完全頭腦風暴式的那種。

方案2：Offline Review
我特別想說的就是這種。包括重構、代碼邏輯、代碼規范。

對于變更的代碼，owner應該提供一份ChangeList，基于需求或者功能點，列舉出增刪改動了那些類和方法以及關鍵變量，這就迫使owner首先review一下自己的代碼，從而首先自身發現一些問題。對于代碼重構，更需要這份清單，甚至是一個變更前后的類之間的關系圖（當然可以從之前的LLD中復制過來）。額外的一個好處就是，重構會把很多方法原封不動的從一個類遷移到另一個輔助類，那么，reviewer就不用去care這些代碼，而只是關心整體的結構，從而對癥下藥，對架構而不是代碼，提出新的見解。

Code-review并不應該局限于紙面上，僅僅依賴于一個DB是不夠的。一定要進行face to face的溝通或者by phone。由reviewer來講解自己的心得，可以不受owner的主觀意向影響，從其他角度來思考這個問題，還有就是迅速掌握代碼，可以在owner離開的情況下迅速接手這段code；由owner來講解，可以在介紹過程中，及時發現一些無法自圓其說的地方，然后加以修正。因此code-review從準備到完成的時間，應該大致為coding的50％左右。

最后，非常不贊同連錯別字都寫進code-review報告的行為。一方面要肯定reviewer的勤懇，但是，另一方面，這些與code無關的suggestion，會轉移我們的視線。我們究竟要關注什么？是代碼質量，是架構設計，而不是單詞拼寫錯誤。過多此類的suggestion，會把真正的問題掩藏起來，即使有critical等級的區別，也無濟于事。一種極端的解決方式是禁止提這樣的suggestion，比較緩和的方式是私下交流這些小錯誤。
額外需要指出的是，對代碼規范的審核，盡量不要依賴人力，而是通過先進的工具來處理。人，總是要做一些機器做不了的事情，比如說重構與算法的review。這樣，我們就可以有更多的時間focus在這些高層次的地方了。

補充：版本變更的代碼比較（我們公司使用的是ClearCase）
如果類中原先有兩個方法A和B，A在B的前面。版本變更后將A方法挪到了B方法的后面，那么ClearCase會只認為B方法是不變的，而認為新版本在B方法前刪除了A方法，而在B方法后又添加了這個A方法——這就由ClearCase的逐行比較算法導致的，它畢竟只是一個文件控制工具，而不是for code file的；但是對于人而言，其實是沒有改變的。這就對Code-Review添加了困擾，如果代碼文件2萬行，將一個方法從頭位置挪到了尾部，這無疑就給reviewer造成了麻煩。

解決方案：如果ClearCase比較不同版本的代碼文件的算法，能夠細化為先list出一個類所有的成員（使用反射），按字母順序排列，那么比對兩個版本的類文件時，就可以按照成員的順訊，先比較成員是否有所增刪改變，再深入到方法屬性中，用ClearCase原先的算法，逐行比較代碼變更。
此外，還要注意嵌套類，因此要使用迭代來實現以上新算法。還有就是partial分散類的問題，這應該在代碼規范中，禁止使用這種類的實現（自動生成的winform窗體除外）。

Code Review中文應該譯作“代碼審查”或是“代碼評審”，這是一個流程，當開發人員寫好代碼后，需要讓別人來review一下他的代碼，這是一種有效發現BUG的方法。由此，我們可以審查代碼的風格、邏輯、思路……，找出問題，以及改進代碼。因為這是代碼剛剛出爐的時候，所以，這也是代碼重構，代碼調整，代碼修改的最佳時候。所以，Code Review是編碼實現中最最重要的一個環節。

長時間以來，Code Review需要有一些有效的工具來支持，這樣我們就可以更容易，更有效率地來進行代碼審查工作。下面是5個開源的代碼審查工具，他們可以幫助你更容易地進行這項活動。

1. Review board:
Review board 是一個 基于web 的工具，主要設計給 django 和python的用戶。 Review board 可以幫助我們追蹤待決代碼的改動，并可以讓Code-Review更為容易和簡練。盡管Review board 最初被設計在VMware項目中使用，但現在其足夠地通用。當前，其支持這些代碼版本管理軟件： SVN, CVS, Perforce, Git, Bazaar, 和Mercurial.

Yahoo 是review-board的其中一個用戶。

“Review board 已經改變了代碼評審的方式，其可以強迫高質量的代碼標準和風格，并可以成為程序員編程的指導者。每一次，當你訪問search.yahoo.com 時，其代碼都是使用 Review board工具Review過的。 We’re great fans of your work!” – Yahoo! Web Search

2. Codestriker:
Codestriker 也是一個基于Web的應用，其主要使用 GCI-Perl 腳本支持在線的代碼審查。Codestriker 可以集成于CVS, Subversion, ClearCase, Perforce 和Visual SourceSafe。并有一些插件可以提供支持其它的源碼管理工具。

David Sitsky 是 Codestriker 的作者，并也是最活躍的開發人員之一。 Jason Remillard 是另一個活路的開發者，并給這個項目提供了最深遠最有意義的貢獻。大量的程序員貢獻他們的代碼給 Codestriker 項目，導致了這個項目空前的繁榮。

3. Groogle:
Groogle 是一個基于WEB的代碼評審工具。 Groogle 支持和 Subversion 集成。它主要提供如下的功能：

<!--[if !supportLists]-->· <!--[endif]-->各式各樣語言的語法高亮。

<!--[if !supportLists]-->· <!--[endif]-->支持整個版本樹的比較。

<!--[if !supportLists]-->· <!--[endif]-->支持當個文件不同版本的diff功能，并有一個圖形的版本樹。

<!--[if !supportLists]-->· <!--[endif]-->郵件通知所有的Reivew的人當前的狀態。

<!--[if !supportLists]-->· <!--[endif]-->認證機制。

4. Rietveld:
Rietveld 由Guido van Rossum 開發（他是Python的創造者，現在是Google的員工），這個工具是基于Mondrian 工具，作者一開始是為了Google 開發的，并且，它在很多方面和Review board 很像。它也是一個基于Web的應用，并可以Google App Engine 當主機。它使用了目前最流行的Web開發框架 django 并支持Subversion 。當前，任何一個使用 Google Code 的項目都可以使用 Rietveld 并且使用 python Subversion 服務器。當然，它同樣支持其它的Subversion服務器。

5. JCR
JCR 或者叫做 JCodeReview 也是一個基于WEB界面的最初設計給Reivew Java 語言的一個工具。當然，現在，它可以被用于其它的非Java的代碼。

JCR 主要想協助：

<!--[if !supportLists]-->· <!--[endif]-->審查者。所有的代碼更改都會被高亮，以及大多數語言的語法高亮。Code extracts 可以顯示代碼評審意見。如果你正在Review Java的代碼，你可以點擊代碼中的類名來查看相關的類的聲明。

<!--[if !supportLists]-->· <!--[endif]-->項目所有者。可以 輕松創建并配置需要Review的項目，并不需要集成任何的軟件配置管理系統（SCM）。

<!--[if !supportLists]-->· <!--[endif]-->流程信仰者。 所有的評語都會被記錄在數據庫中，并且會有狀態報告，以及各種各樣的統計。

<!--[if !supportLists]-->· <!--[endif]-->架構師和開發者。 這個系統也可以讓我們查看屬于單個文件的評語，這樣有利于我們重構代碼。

JCR 主要面對的是大型的項目，或是非常正式的代碼評審，從這方面看來，他并不像上面的那些工具。

Jupiter：最后我們要提一下Jupiter，這是另一個代碼review的工具你可以去考慮使用的，它是一個Eclipse IDE 的插件。