以參考我的博客 如何用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.引入新的技術或者是我們團隊素質的提高,是否要加入更多的檢查項?
去吧,優化我們的清單,保持為我們的團隊量身打造清單。