目的

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

所以基于以上目的，代碼走查不是為了找到代碼寫的差的程序員加以批評，不是為了找到差的代碼，而是一起發現問題共同成長，所以對于寫代碼的同學不需要過于緊張，但是在代碼走查前自己可以先看一次優化一遍，不過所有的變更必須有單元測試覆蓋，否則為了優化代碼又會引發新的問題。

什么場景應該做代碼走查？

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

如何進行代碼走查

代碼走查的角色

主持人：負責主持整個走查活動，包括會議邀約和控制時間(一般一小時左右)進度。為了讓代碼走查高效，需要及時阻止不必要的討論，比如講解人講的太發散、或者大家針對一個點討論時間過長。

講解人：負責對代碼進行講解并跟進修改計劃，一般是系統Owner或代碼編寫者。

記錄人：記錄代碼走查記錄，記錄中包括代碼走查中發現的問題點、修復方法和最佳實踐，問題需要指定到對應的人。

評審人：對代碼進行評審發現問題并找出最佳實踐，一般是資深開發和測試同學。

參與人：參加代碼走查，主要以學習為主。

走查前做好充分準備

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

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

走查中控制節奏

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

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

編碼規范： 可以使用IDEA的插件自動掃描有沒有編碼問題。

設計規范

冪等性

邏輯問題：是否滿足需求。

一致性問題

并發和鎖：在并發情況下，代碼執行結果是否有問題。

性能問題：代碼是否存在性能問題，預計峰值流量能到多少。

分支覆蓋率：是否有分支沒有覆蓋

走查后總結

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

參加代碼走查有什么收獲？

對代碼走查有什么建議？

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

時間把控：第一次代碼走查主持人和講解人時間沒控制好，走查了三個多小時，后續主講人講重點，主持人隨時控場，討論超過幾分鐘的就記錄下面，線下討論。

重點優先：大家前面精力比較好后面就分神了，后續主講人優先走查重點代碼。

總結

以上是生活随笔為你收集整理的java 代码走查_代码走查如何保证软件质量的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。