1988 年，惠普公司(HP)對其軟件開發流程進行了一次內部審查，并為自己設定了將代碼質量提高十倍的目標。為了實現這一宏偉目標，公司嘗試了多種方法。最后，惠普發現，將代碼修訂納入開發周期，比客戶發現漏洞后再進行修復，能節省更多資金。

可以說，惠普在這樣做的時候，軟件開發實踐還不像今天這樣明確和成熟。不過，各組織早已明白，將代碼審查納入軟件開發生命周期可以產生積極的效果。本文就講述了CS專業留學生審查代碼的一些技巧。

1.創建代碼審查清單

代碼審查核對表是一套預先定義的問題和規則，團隊在代碼審查過程中將遵循這些問題和規則，從而為代碼庫批準代碼前所需的質量控制提供結構化方法的優勢。檢查表可包括;

可讀性：代碼是否包含不必要的注釋?

安全性：代碼是否會使系統受到網絡攻擊?

測試覆蓋率：是否有多個測試用例需要測試?

架構：代碼是否使用封裝和模塊化來實現關注點分離?

重復使用：代碼是否使用了可重復使用的組件、函數和服務?

2.引入代碼審查指標

不衡量代碼質量，就無法解決代碼質量問題。客觀的衡量標準有助于確定審查的有效性、分析流程變更的影響以及預測完成項目所需的小時數。

一些最常用的評審指標包括;

檢查率：團隊審查特定數量代碼的比率，計算方法是用代碼行(LoC)除以檢查小時數。如果審查代碼的時間過長，則可能存在需要解決的可讀性問題。

缺陷率： 發現缺陷的頻率，計算方法是用缺陷計數除以檢查時間。這一指標有助于確定測試程序的有效性;例如，如果程序員發現缺陷的速度很慢，你可能需要更好的測試工具。

缺陷密度： 你在特定數量的代碼中發現的缺陷數量，計算方法是將缺陷數量除以數千行代碼(kLOC)。缺陷密度可幫助你確定哪些組件比其他組件更容易出現缺陷，從而為易出現缺陷的組件分配更多資源。例如，如果你的一個網絡應用程序比同一項目中的其他程序有更多缺陷，你可能需要為其分配更有經驗的程序員。

3.確保你的反饋證明你的立場合理

審核代碼時，不要只建議需要修復或改進的地方，還要解釋開發人員為什么要進行修改。

在開發過程中，你經常會遇到有多種解決方案的問題。你對代碼的評論是你的知識和經驗的結晶;你可能更喜歡用一種特定的方法來解決問題，而這種方法可能與代碼編寫者的方法不同。因此，你應該明確說明你的編碼選擇，以解釋你的理由。

例如，假設你正在考慮一段代碼，你認為沒有必要使用多線程。與其簡單地勸阻開發人員不要使用線程，不如解釋說并行模型在他們的方案中并不能提供性能優勢，因此他們應該將代碼改為單線程。

這種方法有兩個優點。首先，代碼的作者會知道為什么需要進行特定的修改，這將有助于他今后解決類似的問題。其次，由于他已經說明了他的注釋的合理性，他就不必再要求說明他的注釋的合理性，從而節省了你們雙方的時間。

4.每次審查不要超過 200-400 行代碼

檢查超過 400 行代碼會對你發現錯誤的能力產生負面影響，事實上，大多數錯誤都會在前 200 行中發現。思科(Cisco)在其代碼審查綜合研究中發現了這一限制，并對行業實踐產生了影響。研究發現，當開發人員審查的代碼超過 200 行時，發現錯誤的能力就會下降。

5.通過應用程序保持最佳實踐

如果你使用 Bitbucket 作為 Git 解決方案，那么請使用 Workzone 這樣的應用程序來簡化你的源代碼管理 (SCM) 工作流程，它可以幫助你計劃如何以及何時推送變更，如何在新的拉取請求中添加審核員和組。你還可以在池請求的源代碼和分支中設置預定義的組和審閱者，這樣它們就會默認包含在新的池請求中。這樣，人們就能以簡單方便的方式實施 SCM 流程。

另一個能幫助實現代碼審查自動化的 Bitbucket 應用程序是 Bitbucket 的 Code Owners。該工具允許你使用代碼所有者的概念來確定哪些用戶應審查拉取請求。代碼所有者是指在特定編碼領域(如在 Spring Boot 中開發應用程序)擁有知識和經驗的人。使用代碼所有者可確保由正確的開發人員審查代碼并進行合并驗證。

海馬課堂留學生作業輔導，根據學生的輔導需求匹配背景相符的專業老師，承諾導師真實教育背景。1V1個性化備課，雙語教學，實時輔導，講解相關知識點和解題思路，提供大型作業任務的解決方案，輔導計算機編程語言操作，教授學生高效完成PPT和演講稿，針對性解決留學生各類作業中遇到的困擾，提高作業成績!輔導不滿意隨心退!