Code Review即程式碼審查是軟體開發中常用的手段，它和QA測試相比，更容易發現架構以及時序相關等較難發現的問題，還可以幫助團隊成員統一程式設計風格，提高程式設計技能等。程式碼審查被公認為是一個提高程式碼質量的有效手段。目前很多開發團隊雖然進行了程式碼審查，但是他們可能沒有有效、合理的進行程式碼審查，以致沒有很好達到程式碼審查的目的。近日，BIDS 貿易科技有限公司的CTO Jim Bird 總結了關於程式碼審查的一些建議。現對這些建議進行了一個全面的梳理，具體內容如下：
1、程式碼審查不要太正式
目前，有很多研究表明正式程式碼的評審會議會延誤開發進度和增加開發成本。儘管可能只需要幾周的時間進行程式碼評審，但是隻有4%的缺陷是在會議期間發現的，其餘所有的許可權是靠程式碼審查者自己發現和處理的。只有採用簡短、輕量的程式碼審查才是有效的發現問題在程式碼檢查,這樣的程式碼審查更適合迭代、增量開發，為開發者提供更快的反饋。
2、程式碼審查人員要儘可能少
並不是程式碼審查人員越多就能發現越多Bug，只有合理數量的審查人員才能夠更加有效的地審查程式碼。研究表明，平均來說，一個程式碼審查人員能夠發現Bug的一半, 第二審稿人會發現剩餘新問題的一半。多個人同2個人發現問題的數量沒有太大差異，故兩個人進行程式碼審查是比較合適的。另外，還由於社會惰性的存在，更多程式碼審查人員意味著多人在尋找同樣的問題，使得審查人員積極性、主動性不高，更加不利於程式碼審查工作的有效進行。
3、需要有經驗的開發者進行程式碼審查
研究充分表明，程式碼審查的有效性依賴於審查人的技能和對問題領域以及程式碼的熟悉程度。如果讓新加入團隊的成員進行程式碼審查的話，並不利於他們的成長，且對於程式碼審查來說也是一種非常糟糕的方式。只有擅長閱讀程式碼、程式除錯、非常熟悉語言、框架、對應的問題的人才最適合程式碼審查，才能夠高效發現問題、提供更多有價值的反饋。新的、沒有經驗的開發者只適合檢查程式碼的變化和使用靜態分析工具並和另一位評論人員共同程式碼審查。
4、實質重於方式
完全按照編碼規格標準進行的程式碼審查是一個浪費開發人員寶貴時間的方式。程式碼審查的實質是確認程式碼能夠正確的執行，發現安全漏洞、功能錯誤、程式碼錯誤、設計失誤、安全驗證和防範、惡意程式碼等。而不是單單按照編碼規範完全保證程式碼格式一致，而丟失了程式碼審查的實質。
5、合理安排Bug 和可維護性問題程式碼的審查時間分配
發現程式碼中的Bug是很難的，在別人的程式碼找到的Bug更難。研究表明，程式碼審查人員找到Bug和可維護性、可讀性問題的比例是25:75，故消耗在了程式碼可讀性、可維護性等問題上和Bug上的程式碼審查時間應該合理分配。
6、儘量使用靜態程式碼分析工具以提高審查效率
工欲善其事，必先利其器。靜態程式碼分析工具可以幫助程式開發人員自動執行靜態程式碼分析，快速定位程式碼隱藏錯誤和缺陷；幫助程式碼設計人員更專注於分析和解決程式碼設計缺陷；顯著減少在程式碼逐行檢查上花費的時間，提高了軟體可靠性並節省軟體開發和測試成本。
7、二八定律處理高風險程式碼
審查所有的程式碼並沒有太大的意義，應該把審查的重點放在高風險的程式碼和容易引起高風險的修改或者重構的程式碼上。舊而複雜、處理敏感資料、處理重要業務邏輯和流程、大規模重構以及剛加入團隊的開發者實現的程式碼都是審查的重點。
8、從程式碼審查中儘量獲得最大的收益
雖然程式碼審查是發現Bug、提高開發人員程式碼編寫質量的重要方式，但是它也增加了程式碼開發成本。如果沒有合理、有效的進行程式碼審查，將有可能影響專案進度和破壞團隊文化。故我們要緊抓程式碼審查的實質性問題，儘早和經常性的進行非正式的程式碼審查；選擇精而少的人員並運用二八定律審查高風險的程式碼，同時，還需要合理分配Bug以及可維護性問題的程式碼審查時間，才可以從程式碼審查中獲得最大的收益。
評論(2)