如果引用或轉貼,麻煩註明出處與本網誌連結,否則視為侵權。

2017年6月20日

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

作者: 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% 的時間修復錯誤或解決技術債務(以前留下來的問題),與建立新功能所花費的時間不相上下。
 
由上面來看,程式碼審查可以提高修復錯誤的效率,但是不見得可以提高程式碼品質。
 
 


沒有留言:

張貼留言

歡迎提供意見, 謝謝 (註 : 留言經過版主審核通過才會發布)