軟件質量保障之代碼走查

目的

代碼走查有幾個目的，第一個是讓新同學快速熟悉代碼并了解系統。第二個是做咨詢防控的事前檢查，避免引發線上故障。第三個是通過一起討論和審查，加強團隊代碼閱讀和編寫能力，讓大家編寫出優秀的代碼。代碼走查的優點非常多，但是最核心的還是提前發現問題并解決問題。

所以基于以上目的，代碼走查不是批評而是發現問題共同成長，所以對于寫代碼的同學不需要過于緊張，但是在代碼走查前可以自己看優化一遍，但是變更必須有單元測試覆蓋。

什么場景應該做代碼走查？我認為有幾個時機點是需要做代碼走查的，第一個是定期，每幾個月定期做一次代碼走查。第二個是有重大變更時做代碼走查，如代碼第一次上線或增加了比較多的代碼。

如何進行代碼走查

代碼走查的角色

• 主持人：負責主持整個走查活動，包括會議邀約和控制時間（一般一小時左右）進度。為了讓代碼走查高效，需要及時阻止不必要的討論，比如講解人講的太發散、或者大家針對一個點討論時間過長。
• 講解人：負責對代碼進行講解并跟進修改計劃，一般是系統Owner或代碼編寫者。
• 記錄人：記錄代碼走查記錄，記錄中包括代碼走查中發現的問題點、修復方法和最佳實踐，問題需要指定到對應的人。
• 評審人：對代碼進行評審發現問題并找出最佳實踐，一般是資深開發和測試同學。
• 參與人：參加代碼走查，主要以學習為主。

走查前做好充分準備

講解人整理本次要走讀的代碼分支、系分設計和代碼入口，然后發郵件通知大家，參加代碼走查的人提前閱讀系分和代碼，針對看不懂的代碼、有問題的代碼和設計復雜的代碼全部提交Review記錄。

講解人必須想好走查哪些代碼，一般是主流程或有問題的點，控制整個代碼走查的時間，我們第一次代碼走查花了三個多小時，由于時間太長，走查的過程中開發都走了幾個。

走查中控制節奏

直接講代碼很多沒參與的同學會很暈，所以先大致講下系分設計，不需要全部講完設計再講代碼，而是講一部分設計，再講一部分代碼。講解人帶著大家一行一行讀代碼，講解代碼的含義和思考，記錄人負責記錄Review出的問題和最佳實踐。

代碼走查的評判標準，主要關注幾個點

• 編碼規范： 可以使用IDEA的插件自動掃描有沒有編碼問題。
• 設計規范
• 冪等性
• 邏輯問題：是否滿足需求。
• 一致性問題
• 并發和鎖：在并發情況下，代碼執行結果是否有問題。
• 性能問題：代碼是否存在性能問題，預計峰值流量能到多少。
• 分支覆蓋率：是否有分支沒有覆蓋

走查后總結

在代碼走查之后，要優化代碼走查，所以會發一個調查問卷給大家

1. 參加代碼走查有什么收獲？
2. 對代碼走查有什么建議？

我們走查完之后有幾個改進點

1. 時間把控：第一次代碼走查主持人和講解人時間沒控制好，走查了三個多小時，后續主講人講重點，主持人隨時控場，討論超過幾分鐘的就記錄下面，線下討論。
2. 重點優先：大家前面精力比較好后面就分神了，后續主講人優先走查重點代碼。

原文轉自：http://ifeve.com/code-review/