關于代碼審查的幾點建議

jopen 10年前發布 | 5K 次閱讀 代碼審查

  Code Review 即代碼審查是軟件開發中常用的手段,它和 QA 測試相比,更容易發現架構以及時序相關等較難發現的問題,還可以幫助團隊成員統一編程風格,提高編程技能等。代碼審查被公認為是一個提高代碼質量的有效手 段。目前很多開發團隊雖然進行了代碼審查,但是他們可能沒有有效、合理的進行代碼審查,以致沒有很好達到代碼審查的目的。近日,BIDS 貿易科技有限公司的 CTOJim Bird 總結了關于代碼審查的一些建議。現對這些建議進行了一個全面的梳理,具體內容如下:

  1、代碼審查不要太正式

  目前,有很多研究表明正式代碼的評審會議會延誤開發進度和增加開發成本。盡管可能只需要幾周的時間進行代碼評審,但是只有4% 的缺陷是在會議期間發現的,其余所有的權限是靠代碼審查者自己發現和處理的。只有采用簡短、輕量的代碼審查才是有效的發現問題在代碼檢查,這樣的代碼審查 更適合迭代、增量開發,為開發者提供更快的反饋。

  2、代碼審查人員要盡可能少

  并不是代碼審查人員越多就能發現越多 Bug,只有合理數量的審查人員才能夠更加有效的地審查代碼。研究表明,平均來說,一個代碼審查人員能夠發現 Bug 的一半, 第二審稿人會發現剩余新問題的一半。多個人同 2 個人發現問題的數量沒有太大差異,故兩個人進行代碼審查是比較合適的。另外,還由于社會惰性的存在,更多代碼審查人員意味著多人在尋找同樣的問題,使得審 查人員積極性、主動性不高,更加不利于代碼審查工作的有效進行。

  3、需要有經驗的開發者進行代碼審查

  研究充分表明,代碼審查的有效性依賴于審查人的技能和對問題領域以及代碼的熟悉程度。如果讓新加入團隊的成員進行代碼審查的話,并不利于他們的 成長,且對于代碼審查來說也是一種非常糟糕的方式。只有擅長閱讀代碼、程序調試、非常熟悉語言、框架、對應的問題的人才最適合代碼審查,才能夠高效發現問 題、提供更多有價值的反饋。新的、沒有經驗的開發者只適合檢查代碼的變化和使用靜態分析工具并和另一位評論人員共同代碼審查。

  4、實質重于方式

  完全按照編碼規格標準進行的代碼審查是一個浪費開發人員寶貴時間的方式。代碼審查的實質是確認代碼能夠正確的運行,發現安全漏洞、功能錯誤、代碼錯誤、設計失誤、安全驗證和防范、惡意代碼等。而不是單單按照編碼規范完全保證代碼格式一致,而丟失了代碼審查的實質。

  5、合理安排Bug 和可維護性問題代碼的審查時間分配

  發現代碼中的 Bug 是很難的,在別人的代碼找到的 Bug 更難。研究表明,代碼審查人員找到 Bug 和可維護性、可讀性問題的比例是 25:75,故消耗在了代碼可讀性、可維護性等問題上和 Bug 上的代碼審查時間應該合理分配。

  6、盡量使用靜態代碼分析工具以提高審查效率

  工欲善其事,必先利其器。靜態代碼分析工具可以幫助程序開發人員自動執行靜態代碼分析,快速定位代碼隱藏錯誤和缺陷;幫助代碼設計人員更專注于分析和解決代碼設計缺陷;顯著減少在代碼逐行檢查上花費的時間,提高了軟件可靠性并節省軟件開發和測試成本。

  7二八定律處理高風險代碼

  審查所有的代碼并沒有太大的意義,應該把審查的重點放在高風險的代碼和容易引起高風險的修改或者重構的代碼上。舊而復雜、處理敏感數據、處理重要業務邏輯和流程、大規模重構以及剛加入團隊的開發者實現的代碼都是審查的重點。

  8、從代碼審查中盡量獲得最大的收益

  雖然代碼審查是發現 Bug、提高開發人員代碼編寫質量的重要方式,但是它也增加了代碼開發成本。如果沒有合理、有效的進行代碼審查,將有可能影響項目進度和破壞團隊文化。故 我們要緊抓代碼審查的實質性問題,盡早和經常性的進行非正式的代碼審查;選擇精而少的人員并運用二八定律審查高風險的代碼,同時,還需要合理分配 Bug 以及可維護性問題的代碼審查時間,才可以從代碼審查中獲得最大的收益。

來自: InfoQ
                    <span id="shareA4" class="fl">                            
                        </span>
 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!