讓你提前認識軟體開發(47)：同行評審

標籤：style   blog   http   color   使用   io   strong   資料   

第3部分 軟體研發工作總結

同行評審

 

         在《浪潮之巔》這本書中，吳軍老師描述了在Google早期的工作方式，其中有一段是這麼寫的：我一般會在吃完晚飯後把代碼修改的清單發給克雷格做代碼審核，他一般晚上10點左右會回複我，給我修改意見，詳細到某一行多了一個空格。

        吳軍老師所描述的內容，其實就是軟體開發中的同行評審流程。

        幾乎在所有的軟體項目中，都需要同行評審。一個人不管能力多強，看問題的角度總會受到限制，寫出來的程式和文檔等定不會是十全十美的。如果能夠讓懂行的同事給參閱一下，並提出他們認為正確的意見，那麼勢必會減少軟體產品中的缺陷，取得個人難以達到的效果。因此，同行評審流程對於廣大的軟體工程師來說，是十分重要的，也是不可或缺的。

        1. 什麼是同行評審？

        同行評審(Peer Review)是一種結構化的正式評審，由生產者(作者)的同行為識別異常和需要修改的部分而對工作產品進行的有組織、有計劃的檢查。

        同行評審並不是對個人的工作不信任，其目的是儘早有效地消除軟體工作產品中的異常。

 

         2. 為什麼要做同行評審？

        在學校的時候，老師教導我們要獨立完成作業，因此，如果你在那個時候對別人的作業或在考試過程中進行“同行評審”，那就是違規的。但軟體開發是一項團隊性的工作，需要大家協作來完成，所以，那種不願意公開自己工作成果的做法是行不通的。

        為什麼要做同行評審呢？

        第一，凡是人皆有出錯的時候，要保證你做出的東西裡面的錯誤盡量少，就需要他人對其進行評審。

        第二，對於軟體產品來說，缺陷發現得越早，糾正缺陷所需的費用就越少。因此，在軟體的開發階段，如果嚴格進行同行評審，那麼後續流程中出現的錯誤就會越少，這也可以為公司節約錯誤修正的成本。

        第三，同行評審過程中發現的錯誤可作為案例傳承下去，避免開發人員再次掉進同一個陷阱。“前事不忘，後事之師”，別人所犯的錯誤對自己有警示的作用。特別是對於新員工來說，經常參與同行評審，可減少試錯的次數，也能夠達到對新工作及早上手的目的。

 

        3. 同行評審有哪幾種類型？

        同行評審的類型包括：審查、走查、單人複審和多人複審等。

 

        4. 同行評審的對象是什嗎？

       在產品開發的各階段中，需要參與同行評審的對象包括：

       (1) 概念階段：產品需求說明書等。

       (2) 計劃階段：系統方案、專案計劃等。

       (3) 開發階段：詳細設計、單元測試規程(方案)、整合測試規程(方案)、代碼、資料庫指令碼等。一般而言，在開始編碼之前，先要進行詳細設計評審，以確保程式的正確性，減少後續修改帶來的不良影響。

       (4) 驗證階段：系統測試計劃、系統測試規程(方案)等。

 

        5. 什麼是審查？審查的角色都有哪些？審查的步驟有哪些？有效評審的原則有哪些？

        審查是同行評審的一種，在軟體項目中佔有重要地位。

        (1) 審查定義：審查(Inspection)是一種正規的同行評審，適用於重要性和重複性較高的軟體工作產品。

        (2) 審查(評審)角色：包括主持人、講解員、記錄員、作者和審查員。一般說來，參與審查的人有3到7人。各角色的分工如下：

        1) 主持人：需要具備領導技巧，負責管理審查過程，是審查流程的關鍵角色。

        2) 作者：提供審查材料，並提供概要介紹；此外，作者也可以充當評審員。

        3) 記錄員：按照主持人的示意記錄產品和程式等的異常，在記錄的同時要記錄異常分類，並大聲朗讀記錄下來的缺陷。

        4) 講解員：充分理解審查材料，並在講解的同時加以解釋。該角色不能由作者擔當。

        5) 審查員：所有參與審查的人員都可以是評審員；主要負責理解被審材料、進行個人檢查、做好準備並參加審查會議。

        (3) 審查活動的步驟有7個，如所示：

        (4) 有效評審的原則包括：

        1) 在預審期間要使用檢查單，以避免發現缺陷不知道記錄在哪裡的情況發生。

        2) 避免過度依賴檢查單。

        3) 審查會議要限制在2小時之內，以避免長時間討論而偏離了審查會議的主題。

        4) 審查的對象是產品而非生產者(作者)，因此要避免對作者本人進行人身攻擊。

        5) “磨刀不誤砍柴工”，要給評審員提供足夠的預審時間，一般以提前兩天為佳。

        6) 如果有與會人員未準備好，則將會議延期；如果有人確實抽不出時間，則取消評審。

 

        6. 什麼是程式碼檢閱？其目的是什嗎？

        對於軟體開發工程師來說，程式碼檢閱是不可缺少的一個環節，也是提高代碼品質的一種有效手段。

        (1) 程式碼檢閱的定義：程式碼檢閱是一種正式的針對程式發起的一項同行評審活動，它由一組職責明確的主持人、作者、記錄員、審查員等人員通過一系列明確已定義流程對代碼進行靜態檢查來發現代碼中的異常。

        (2) 程式碼檢閱的目的：提早發現代碼缺陷、去除缺陷，以降低開發成本並提高產品品質。

 

         如前所述，同行評審流程固然重要，但要徹底地執行下去，需要做到以下幾點：

        第一，作者本人要持有開放心態，願意分享自己的工作成果，並勇於承認自身的不足而加以改進。人都不大樂意被別人指出自身的問題，而同行評審的目的就是要發現問題，因此，這在一定程度上是對作者心態的考驗，要明白是產品有缺陷，對產品中的問題進行完善。

        第二，評審人員要對事不對人，要懂得同行評審是為了發現產品的缺陷，而非人自身的問題。不要將同行評審活動變性為針對作者本人的人身攻擊，這就有傷整個團隊的凝聚力。同行評審的一個宗旨就是大家在一起學習，取長補短，共同提高。

        第三，很重要的一點，公司要對同行評審的結果進行總結，並以文檔的形式儲存起來，方便後期查閱。很多軟體產品出現的問題都是相似的，在著手開發產品之前，如果能夠瞭解前期類似產品中出現的問題，那麼可以少走很多彎路，節約了工作時間，提高了工作效率。

 

       為了確保產品的品質，產品的所有工作成果(包括程式、文檔、圖形等)都應該接受同行評審。“三人行，則必有我師”，不管是老員工，還是新員工，都能夠從同行評審中受益。

 

 

(本人微博：http://weibo.com/zhouzxi?topnav=1&wvr=5，號：245924426，歡迎關注！)