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

　　我們應該討論，為了得到更好的結果，不應該過快地評價。但是您也不應該在一個位置花太多的時間。大約 60 分鐘后，評審者就會感到疲勞，于是就不會找到額外的缺陷了。這個結論得到了許多其他研究的支持。實際上，根據我們的常識，當人們從事注意力高度集中的活動時，性能狀態在 60-90 分鐘之后就會降低了?？紤]到人體方面的限制，評審者在性能降低之前，不能評審超過 300–600 行的代碼。

　　但反過來說，評審代碼所花的時間不得低于五分鐘，就算代碼只有一行也是如此。通常來說，單行的代碼也會影響到整個的系統，所以花上五分鐘時間去檢查更改可能造成的結果是值得的。

　　回頁首

　　4. 確定在評審開始之前代碼開發者已經注釋源代碼了

　　在評審開始之前代碼開發者可能就消除大多數的缺陷，這一點我們將會看到。如果我們需要開發員雙倍地檢查他們的工作，那么評審可能更快地完成，而不用再去折中考慮代碼質量的問題。就我們所知，這種特定的想法尚未得到研究，所以我們在 Cisco 研究期間對其進行了測試。

　　圖 3. 代碼開發者準備對缺陷密度的震撼性效果

　　代碼開發者準備 說的是代碼開發者在評審之前要先注釋他們的源代碼。我們發明了這個術語，以描述研究中所評價的特定行為模式，大約 15% 的評審會阻止代碼開發者這樣做。注釋會指導評審者進行變更，顯示首先必須要查看的文件，并找到每一次代碼更改的原因。這些注釋不是代碼之中的評論，而只是給其他評審者看的評論。

　　我們的理論就是，因為代碼開發者需要重新考慮，并解釋注釋過程中所發生的更改，所以代碼開發者需要在評審開始之前就找出許多缺陷，以讓評審變得更加有效。如此，評審過程將會產生低密度的缺陷，因為更少的錯誤(bug)剩余了。很明顯，與沒有代碼開發者準備的評審相比，代碼開發者準備之后的評審有更少的缺陷存在。

　　我們還考慮過一個悲觀的理論，以解釋錯誤(bug)的低發現率。是不是當代碼開發者在作出一項評論時，評審者會有偏見，或者自鳴得意，這樣就不能盡可能多地發現錯誤(bug)了呢?我們隨機抽查了 300 個評審者進行研究，結果證實評審者在評審代碼時確實非常小心，更少的錯誤(bug)被發現了。

　　回頁首

　　5. 為代碼評審創建可定量化的目標，并獲取制度，這樣您就可以改進流程了

　　有了項目，您就該決定代碼評審過程的目標，以及怎樣評價效率問題了。當您在定義特定的目標時，您就能夠決定同行評審是否真的達到了您所需要的結果。

　　最好從外部性的制度開始，例如“將支持訪問降低 20%”或者“使開發引入的缺陷百分比減半”。這些信息使您能夠更好地看清，從外部視角來看，代碼能夠做些什么，您還需要一個可定量化的評價手段，而不是“修復更多錯誤(bug)”的模糊目標。

　　但是，在外部制度顯示結果之前需要花上一段時間。例如，支持性訪問將不會得到影響，直到新的版本得到發布并交到客戶手中為止。所以查看內部性流程工具，以得到發現多少缺陷，缺陷就是問題所在，以及開發員在評審上所花時間的清晰結果。代碼評審的最常見內部性制度是 檢查率 ，缺陷率，以及 缺陷密度。

　　考慮一下只有自動化或者緊密控制的流程，才能給您帶來可重復的代碼;人類并不擅長記住啟動或者終止計時器。為了得到最好的結果，您要使用能夠 自動 收集代碼的代碼評審工具，這樣用于流程改進的關鍵代碼就是精確的了。

　　為了改進和提高您的流程，您可以收集代碼并組合流程，以查看更改是如何影響結果的。很快，您就將會知道什么工作最適合您的團隊了。

　　回頁首

　　6. 使用檢查表，因為它能極大地影響代碼開發者和評審者的結果

　　我們極力推薦您使用檢查表，來確定您可能會忘記的事情，它對代碼開發者和評審者都有用。忽略是最難發現的缺陷;畢竟，評審不在那里的東西是很困難的一件事。檢查表是解決這個問題的最好方式，因為它會提醒評審者和代碼開發者花點時間去考慮一下可能被遺忘的事情。檢查表還會提醒代碼開發者和評審者確定所有的錯誤(bug)都得到了處理，軟件功能已經通過了無效值測驗，而且已經創建了單元測試。

　　另外一個有用的概念就是 個人檢查表 。每個人一般都會犯 15-20 個錯誤(bug)。如果您注意到了一些典型的錯誤(bug)，那么您就可以開發自己的個人檢查表(Personal Software Process，Software Engineering Institute，以及 Capability Maturity Model Integrated 也都推薦該實踐方式)。評審者將會完成決定一般性錯誤(bug)的工作。您所應該做的，就是擁有一個簡短的檢查列表，一般都是您容易遺忘的事情。

　　一旦您開始在檢查列表中記錄自己的缺陷，那么您就會少犯錯了。規則將不斷出現在您的腦海中，然后您的錯誤(bug)率就會下降了。這種情況我們將會發現它反復出現。

　　提示：

　　如果您想要得到關于檢查列表的更多具體信息，那么您可以得到本文代碼開發者所寫書籍的免費拷貝，這本書為 Best Kept Secrets of Peer Code Review，網址為 www.CodeReviewBook.com。

　　回頁首

　　7. 確認缺陷得到了修復

　　是的，這種“最佳實踐”看起來好像是沒有腦子的。如果您遇到了評審代碼以找到缺陷的所有問題，那么修復它們就變得順理成章了!現在許多評審代碼的團隊沒有一種好的辦法，去追蹤評審期間找到的缺陷，并確保評審完成之前錯誤(bug)確實得到了修復。確認電子郵件之中的結果，或者實時評審是非常困難的。

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