11個高效的同行代碼評審最佳實踐

　　SmartBear Software 團隊® 花費了數年時間去搜索已有的代碼評審研究成果，并從來自超過 100 家公司的 6000 多名程序員那里，收集了“實踐經驗”。很顯然，人們在評審代碼時會發現一些錯誤(bug)，但是這種評審工作通常會花費大量的時間，因此變得不太實際。我們通過數十年的經驗使用獲得的信息，來創建輕量級代碼評審的概念。通過使用輕量級代碼評審技術，開發員只需要花費五分之一的時間就可以進行全面且規范的代碼評審工作了。我們還開發了最佳實踐的理論，以便部署實現評審的效率與價值。本文概括了以下的這些實踐。

　　訪問 developerWorks 社區上的 敏捷開發小組，在那里您將有機會與更多的開發人員一起交流敏捷開發最佳實踐。

　　為了測試我們對代碼評審及輕量級評審的結論，我們對代碼評審進行了最大規模的研究工作。它涉及包含了2500 個代碼評審案例，50 個程序員，及 Cisco 系統上320 萬行的代碼。在 10 個月的時間內，研究追蹤了 MeetingPlace 產品團隊，該團隊擁有 Bangalore，Budapest 及 San José 方面的成員。

　　在研究開始時，我們要為這個團隊創建以下的規則：

　　在檢入到團隊的版本控制軟件之前，所有的代碼都必須進行評審。

　　SmartBear 的 CodeCollaborator® 代碼評審軟件工具，應該用于精化，組織和改進所有的代碼評審工作。

　　代碼評審的全體會議是不支持的。

　　評審過程會得到工具的支持。

　　CodeCollaborator 會自動收集工具，提供評審層次和總結層次的報告。

　　根據我們的研究結果，總結了 11 項最佳實踐

　　您應該警惕，平等代碼評審(在該過程中，軟件發布以確保質量之前，軟件開發員會相互評審代碼)會識別代碼中存在的錯誤(bug)，鼓勵協作，并使代碼變得更有維護性。

　　但是很明顯的一點是，有些代碼評審技術是低效低能的。評審過程中的一些會議會占用時間，并抑制活力。嚴格的流程會扼殺創造力，但是松散的流程又意味著沒人知道評審是否有效，甚至是否發生。而個人批評的社會效應，又會損傷士氣。

　　本文描述了考慮效率時的 11 項最佳實踐，科學研究和 SmartBear 領域內的經驗證明輕量級同行評審是高效的。使用這些技術，可以確保代碼評審能夠改進代碼 - 而不用占用開發員的時間。您可以使用最近的技術，來在 IBM® Rational Team Concert® 環境之中評審代碼。

　　1. 一次評審量要低于 200–400 行代碼

　　Cisco 代碼評審研究(見于工具欄)顯示了為了得到優化的效率，開發員的評審量要低于一次 200-400 行代碼(LOC)。超過這個量，搜索缺陷的能力就會降低。以這個速度，您可以找到 70-90% 的缺陷。換句話說，如果存在 10 個缺陷，那么您可以找到其中的 7 到 9 個。

　　關于 Cisco 案例研究

　　在 10 個月的監視工作之后，研究總結出了一個理論：如果適當操作的話，輕量級代碼評審工作與規范的評審工作同樣有效，但是前者的速度會更快(更省時)。與規范評審相比，輕量級代碼評審平均要少花 6.5 個小時，并發現更多的錯誤(bug)。

　　除了確認這些理論，研究中還發現了一些新的規律，本文將這些規律都概括了出來。

　　圖 1 中的圖，描述了缺陷密度與評審代碼行數量之間的關系，支持該規則。缺陷密度 就是每 1000 行代碼之中所發現的錯誤(bug)數。評審代碼行的數量超過 200 時，缺陷密度就會急劇地下降。

　　在這種情況下，缺陷密度就是“評審有效性”的評價手段。如果兩個評審員評審相同的代碼，其中一個發現了更多的錯誤(bug)，那么我們就會認為該評審員更有效率。圖 1 顯示了當我們將更多的代碼放到評審者面前時，她搜索缺陷效率的變化情況。這種結果很合理，因為她可能不會花費大量的時間去評審，這樣就會不可避免的使得效率沒有以前高。

　　圖 1. 當代碼行數量超過 200 時缺陷密度就會急劇下降，400 以后缺陷密度幾乎為 0

　　回頁首

　　2. 每小時低于 300–500 LOC 檢查率的目標

　　定義

　　檢查率： 我們能夠多快地評審代碼呢?通常以每小時 kLOC(千代碼行)來評價。

　　缺陷率： 我們能夠多快地發現缺陷呢?通常以每小時缺陷數來評價。

　　缺陷密度： 給定量的代碼之中我們能夠發現多少的缺陷呢(而不是它們有多少)?通常以每 kLOC 中發現的缺陷數來評價。

　　您要花點時間進行代碼評審?？焖僭u審并不總是好的。我們的研究結果顯示檢查率低于“300-500 LOC/小時”時，可以得到優化的結果。根據所作的決定，評審者的檢查率有很大的變化，就算是相似的代碼開發者、評審者，文件和評審規模，也存在巨大的差異。

　　為了找到優化的檢查率，我們將 缺陷密度 與評審者檢查代碼的 速度 進行了比較。得到的結果再一次落在了我們的預料之中：如果在評審您不花足夠的時間，那么您就不會發現太多的缺陷。如果評審者面臨大量代碼的壓力，那么他就不會每一行代碼投入相同的注意力。他不能研究同一位置處更改的所有版本。

　　所以，多快算是太快呢?圖 2 顯示了答案：服務器端每小時超過 400 LOC 的評審速度會降低效率。而每小時 1000 LOC 的速度，您可能已經推出了，以這樣的速度評審員可能根本都沒有細看代碼。

　　圖 2. 評審量超過 500 行代碼時檢查效率就會下降了

　　回頁首

　　3. 花足夠的時間進行適當緩慢的評審，但是不要超過 60-90 分鐘

原文轉自：http://www.ibm.com/developerworks/cn/rational/11-proven-practices-for-peer-review/