如何從零開始做代碼評審


以參考我的博客   如何用eclipse做代碼的code review

最近和一個朋友討論如何做公司代碼的review,剛好我前段時間在看“騰訊開放平台”中的一個安全漏洞的check list(地址:http://wiki.open.qq.com/wiki/安全漏洞checklist),於是就極力推薦這種模式。簡單來說,基本分如下幾個步驟:

 

1.制作 code review需要的checklist。
check list簡單說來就是一個檢查清單列表。要做code review,我們第一步是需要清楚我們review到底要做哪些工作,然后我們將他們一條一條的列在紙上,每一項是一個檢查項。(我們這里只簡單的列了個清單,實際操作要復雜的多)。

 
NO 檢查點
1

基本

1.代碼能夠成功構建,並執行

2.代碼規范是否在嚴格執行(命名、縮進、函數長度限制、格式、注釋)

3.項目規范是否在嚴格執行(目錄命名規范、等)

4.是否存在重復的代碼(復制粘貼或者重復開發,有庫函數的地方調用庫函數)

5.是否有需要模塊化的代碼

6.代碼邏輯方面(未關閉的流,未結束的循環)

7.日志是否被正確的使用

8.其他(這只是demo,大家腦補吧)

2 安全
1.是否所有的輸入項都進行了檢查(長度、類型、格式、范圍、防止腳本注入)
2.用戶拼接參數,是否會有漏洞
3.防攻擊的代碼是否被正確的使用(xss,csrf,sql注入,每種語言都有自己的成熟的解決方案)
   
 
3 數據庫
1.事物是否正確使用(隔離級別)
2.是否有正確的做sql優化
3.其他
 
4 其他
1.接口命名規范(比如遵循restful標准)
2.合理的使用注釋中 TODO   REVIEW功能
3.復雜邏輯的代碼是否有注釋
4.性能方面
5.線程安全
6.其他
 

2.組織內部討論

與大家分享並討論我們的 codereview清單是獲取大家支持的最有效的方式。
checklist上的每一項都是將來要執行的工作,在內部討論時,必須要明確我們列表中的哪些項目是切實可行,符合現在公司的現狀的,哪些有些過度為難大家(延期執行還是放棄),還有哪些是被遺漏掉的。
要確保 check list中的每一個檢查項項都切實可行,否則規范就會失去可行性。
此外,我們在內部討論中還應該指定 評審的負責人(指定某個人還是輪崗),評審時間(每周?每月?),評審的覆蓋率(抽查?全檢查?)
 
3.以“sprint回顧會議”為基礎,監督codereview執行
沒有監督就沒有落實,上班這幾年見過太多的半途而廢的制度。
但是管理是有成本的,一般的中小團隊還無法單獨的建立自己的管理和監督的部門,那我們設立的制度如何保障執行呢?
在敏捷開發中有一個會議叫做“  

Sprint回顧會議

 ”,用來回顧總結我們的工作。 將code review的執行情況做為回顧會議中的一項,可以確保我們的正在正確的執行我們的codereview的工作。當前對code review的建設性意見,也應該在這里提出來。
 
4.持續優化
沒有什么是一成不變的,code review也不例外。
我們實行了一段時間的  codereview,會有很多的心得體會。
1.check list中哪些檢查項是不合理的,或者我們從未出現的問題,是否要刪除(有些問題很少出現但是很重,就不能刪了)。
2.我們遺漏了哪些很重要的檢查項?
3.引入新的技術或者是我們團隊素質的提高,是否要加入更多的檢查項?
 
去吧,優化我們的清單,保持為我們的團隊量身打造清單。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM