如何從零開始作代碼評審

以參考個人博客   如何用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.引入新的技術或者是咱們團隊素質的提升，是否要加入更多的檢查項？

 

去吧，優化咱們的清單，保持爲咱們的團隊量身打造清單。