Peer Review 淺析

Peer Review

(070620 [email protected] 李甯)

PR的概念和目的

    Peer Review又名同級評審或一對一評審，同級評審的目的是為了要檢查工作的内容，盡早的找到和修正問題。 PR的流程是可以根據條件和時間靈活的制定。

    假設小組不隻是您一個人組成，那麼您應該與組員一起評審工作當中各個方面如功能和事務。花一些時間對作些評審對工作的品質會有很大的改善，同級評審通常是由作者在小組面前檢查他自己的工作。-- Rex。

    目的：

l        同行評審不僅是為了找出缺陷，也是為了正确性驗證。

l        同行評審不同于正式的技術評審，評審人一般是指擔負同一層面任務的人。 比如都在執行程式設計或單元測試或詳細設計或總體設計或需求分析等工作。

l        在軟體開發過程中，凡是可以分為并行的若幹單個個體并且這些個體的缺陷影響不會擴充給其它個體的結果（或者說有但較易控制），均可以考慮進行同行評審。對于需求分析，除非能按幾大類分得很隔離，否則由于我們要驗證需求的一緻性（即不沖突）、不重複性（這些需要進行全盤考慮）時，就不能進行所謂的同行評審來驗證這些特性。對于概要設計也是如此。

對于詳細設計、編碼、單元測試這些開發活動就完全可以在項目經理或小組負責人的安排下進行同行評審就很有意義。

l        P2P開發流程是一種交流形的開發方式， 使開發人員之間增加了交流，同時也是彼此之間有了共同學習與進步，進而達到了代碼規範及風格趨向一緻。

PR的應用條件

l        同行評審一般是在比較成熟的而且參與者已對評審的尺度達成了共識（比如需求分析說明書中需求要細到什麼程度，對用語有什麼限制等等）的時候才考慮應用，也就是說此時參與者對任務及成果本身有着清晰而共則的了解和認識。（對于未達成評審共識以及涉及影響系統結構的争論不應當放到PR上，而應當例會使内部達成共識）

正式的技術評審不管參與者是否對任務有清晰的認識，做為階段性成果的驗收機制，也肯定是要進行的。

l        正式的技術評審可以邀請項目外的權威或高手參加，對于較重要的任務和成果，同行評審可作為初步的評審。然後再考慮進行正式的技術評審。正式的技術評審可作為産品或任務完成的認可機制。而同行評審隻有在項目團隊有清晰而成熟的認識時才可作為一個認可機制，如對詳細設計書和源程式的同行評審。

l        有效的P2P開發的前提是開發子產品和内容要足夠細化和明确化，換言之，是需要開發前的程式設計及架構分析透明化或局部透明化。是以在一些重構項目中或在一些新的項目中去應用P2P的開發模式比較适合。（如果長時間未進行PR過程，積累了大量的代碼和文檔，此時要注入PR評審流程的話前期工作的困難會非常大）。

l        評審的代碼量一次不能過大，否則會給評審者帶來很大的了解和時間上的負擔。

PR的實施

基本的同級評審過程如下所述：

1.    提前幾天散發草案文檔，然後安排一間會議室。

2.    邀請組内幾個能夠參與的人，盡力将每個人都引入到讨論中。

3.    逐一創造一種暢所欲言的評審氣氛。

4.    浏覽文檔和代碼，應在重要細節上花費大量時間，但要防止在次要問題上浪費時間。

5.    在任何一部分中都要避免花費2小時以上時間。很難在高技術資料上長時間保持效率。

6.    評審完成後，重新修訂該文檔和代碼，并将它通知給與會者，確定正确了解了評審的結論和思想。

7.    參與人數一般根據被評審對象的重要性來定，越重要參加的人就越多。

8.    同行評審的人數不是越多越好的，一般不能超過8個，評審的時間（包括會前準備）的時間也不能太長，一般不超過2個小時；開發過程所有的産品都可以被評審，評審的目的還是為了尋找Defect。一般評審前，應該有統一的，供參考的标準，對照标準進行評審，包括技術上是否正确，寫法是否符合标準，和其他産品是否一緻等等，都是同行評審關心的。最後，同意樓上的，能夠在實踐中使用，就會明白最适合自己項目的是什麼，方法也是活的，可以不斷調整的。

公司内部的評審的嘗試：

在公司内部我們也有很多小組嘗試了PR的評審機制,但是大都遇到了不小的障礙，但是歸結一下問題的表現共有三個：

1、 不同人員之間對與子產品的了解上的差異導緻在疏導基本知識的溝通時間很長；

2、 對評審人的工作有打斷；

3、 代碼和工作量過大導緻評審無法進行。

實施圖：