程式碼審查有助於提升程式品質嗎? 有關程式審查的十個事實

作者: Fred F.M. Wang (FW知識瑣記) 日期:20170620

英文原文：10 facts about code reviews and quality 

摘要翻譯

        以下是從 680家公司訪談有關程式品質與程式碼審查的案例，得到下面結果

　　事實一：我們花大量的時間在審查程式碼 。事實是，我們每週平均花費 5 個小時來審查程式碼 ，或者每週 12.5％ 的時間來查看程式碼 。

 

　　事實二：作為開發人員，每週花費超過一天的時間來審查程式碼與提高程式碼品質並不相關，反而是用更多時間在發佈新功能（而不是修復bug 或償還技術債務）。  

 

　　事實三：45％ 的開發人員說，「缺少時間」是審查程式碼的真正障礙，34％ 的開發人員則認為是迫於「發佈新功能的壓力」

　　事實四：72％ 的開發人員表示他們被阻止花時間審查程式碼。

　　事實五： 66％ 的開發人員表示需要 1 人批准他們的 pull requests，25％ 需要 2 人，小於 5％ 需要超過 2 人。(註 : Pull Requests : 開發人員可以透過Github發出Pull Requests要求請求他人將程式拉下來看，也就是由開發人員主動要求他人幫忙做Code Review的意味。)

　　事實六：53％ 的人表示有監控程式碼覆蓋率，但 65％ 表示沒有程式碼覆蓋率的最小門檻值(標準)，來批准 pull requests  (註 : 代碼覆蓋（英語：Code coverage）是軟體測試中的一種度量，描述程式中源代碼被測試的比例和程度，所得比例稱為代碼覆蓋率。有多種不同的覆蓋率準則， 如函式覆蓋率，敘述覆蓋率，判斷覆蓋率， 條件覆蓋率等 )

　　事實七：29％ 的開發人員表示 他們的專案中最大的問題是「工作量」，而工程副總和處長的則認為是「交付速度」。開發人員的第三大問題則是「管理」。

　　事實八：關於誰來審查程式碼 ，讓團隊中的每個人都參與是最常見的做法。其他方法則是由專案負責人或模組的負責人來參與，或讓資深的開發人員來審查多數的程式碼 。

 

　　事實九：較嚴格的程式碼 審查會讓我們用更少的時間修復錯誤，也就有更多的時間來提供新功能。較不嚴格的程式碼審查者會花費 31％ 的時間修復錯誤，而嚴格的審查者則只花費 24％ 的時間。關於專注新功能的時間：和上面對應的分別是 43％ 和 54％。(嚴格的審查者有更多的時間專注於新功能)

　　事實十：開發人員花費 45% 的時間修復錯誤或解決技術債務(以前留下來的問題)，與建立新功能所花費的時間不相上下。

 

由上面來看，程式碼審查可以提高修復錯誤的效率，但是不見得可以提高程式碼品質。