這是一篇關於程式碼質量和程式碼評審重要事實的簡短文章。問及了 680 家公司的程式碼質量和程式碼審查實踐。
蘇聯檢查員在檢查一顆 BGM-109G “戰斧”地面發射巡航導彈。
事實一：
我們花了大量的時間審查程式碼。但事實上，我們每週平均花費 5 個小時來審查程式碼，或者本週 12.5％ 的時間來檢視程式碼。
事實二：
作為開發人員，每週花費超過一天的時間來審查程式碼與提高程式碼質量不相關，會用更多時間釋出新功能（而不是修復 bug 或償還技術債務）。
每週花費在程式碼審查上的時間（收益遞減：每週花費超過一天的時間審查程式碼與更好的程式碼質量不相關）
事實三：
45％ 的開發人員說，“缺少時間”是審查程式碼的真正障礙，而 34％ 的開發人員則認為是迫於“釋出新功能的壓力”
事實四：
72％ 的開發人員表示他們的程式碼審查被阻止（沒有經過稽核不釋出一行程式碼）
事實五：
66％ 的開發人員需要 1 人批准他們的 pull requests，25％ 需要 2 人，小於 5％ 需要超過 2 人。
事實六：
53％ 的人監控程式碼覆蓋率，但 65％ 沒有程式碼覆蓋率的最小閾值，用於批准 pull requests
事實七：
29％ 的開發人員說他們的專案中最大的問題是“工作量”，而 Eng 和 Director 的副總裁認為是“交付速度”。開發人員的第三大問題是“管理”。
事實八：
關於誰來審查程式碼，讓團隊中的每個人都參與是最常見的做法。其他替代方法是專案負責人或模組的擁有者來參與，或讓更高階的開發人員審查大多數程式碼。
誰來審查程式碼？三分之二的公司傾向於所有開發者都能參與程式碼審查
事實九：
更嚴格的程式碼審查會讓我們用更少的時間修復錯誤，也就有更多的時間來提供新功能。不太嚴格的程式碼審查者會花費 31％ 的時間修復錯誤，而嚴格的審查者則只花費 24％ 的時間。關於關注新功能的時間：和上面對應的分別是 43％ 和 54％。
事實十：
開發人員花費 45% 的時間修復錯誤或解決技術問題，與構建新功能所花費的時間不相上下。
開發期間每個環節平均花費的時間
編者注：文章提到的資料和情況都是國外的環境，不知國內的又是如何？