代碼審查清單可消除更多的bug

在關於高效代碼審查的博客中，咱們推薦使用清單(checklist)。清單是代碼審查中的偉大工具——他們確保審查在團隊裏持續高效。它們也是確保常見問題被識別、解決的方便途徑。

   軟件工程協會的研究代表，程序員常犯的錯誤有15-20種。所以把這種錯誤增長到清單裏，你就能確保在它們出現時指出來，幫助消除這種隱患。

   

   爲了讓你開始創建清單，下面是經典的條目列表：

代碼審查清單

整體

• 代碼能運行嗎？代碼實現了想要實現的功能了嗎，邏輯是正確的嗎，等等。

• 全部代碼都很容易理解嗎？

• 它遵循了大家都贊成的代碼規範嗎？規範一般包括花括號的位置、變量和函數的命名、行長度、縮進、格式和註釋。

• 有多餘的或重複的代碼？

• 代碼儘量模塊化了？

• 全局變量能被替換？

• 有任何被註釋掉的代碼？

• 循環結構裏有固定的長度值和正確的結束條件？

• 有代碼能夠被類庫函數取代？

• 日誌和調試代碼能夠被移除？

安全

• 全部數據輸入都被校驗(爲了正確的類型、長度、格式和範圍)和轉碼了？

• 第三方工具集在哪裏用到了，可以返回被捕捉到的錯誤嗎？

• 輸出值通過校驗和轉碼了？

• 不合法的參數值獲得處理了？

文檔

• 有文檔嗎，文檔描述了代碼意圖嗎？

• 全部的函數都加註釋了？

• 任何不尋常的行爲和邊界處理都作說明了？

• 就第三方類庫的使用和功能寫文檔了？

• 全部的數據結構和測試單元都作解釋了？

• 有不完整的代碼？若是有，它應該被移除仍是打上’TODO‘之類的適當標記？

測試

• 代碼可測試嗎？好比，不要增長太多的或隱藏的依賴，不可以實例化對象，測試框架可以使用方法等。

• 有測試嗎，它們全面嗎？好比，至少包含了大家承認的代碼覆蓋率嗎？

• 單元測試實際地測試了代碼正在實現的目標功能了？

• 數組檢查’越界‘錯誤了？

• 測試代碼可被已有API的應用取代嗎？

   你還能夠爲清單增長一些語言相關的問題。

   該清單故意沒有包含全部的問題，你並不想一個長長的清單，以至於沒人去使用。只需覆蓋常見問題便可。

優化你的清單

   把該清單作爲一個起點，你應該針對具體用例進行優化。有個不錯的辦法，那就是讓你的團隊在代碼審覈時，花一點時間提出所產生的問題。有了這些數據，你就可以甄別出團隊的常見錯誤，而後就被改形成常見清單。要確保刪除那些不會發生的條目(你或許但願保持較少地發生，還有諸如安全相關的重要條目)。

集思廣益，及時更新

   作爲通用法則，清單上的條目應該是具體的，若是有可能，你能夠就此作一份二元決策【注1】。這有助於避免判斷上的矛盾，與團隊分享清單，並獲得他們對於內容的認同也是不錯的主意。確保按期審查清單，檢查每一項以確保仍然相關。

   有了優秀的清單武裝，你就能夠增長代碼審覈中的瑕疵數量。這有助於你提高代碼質量、避免不穩定的代碼審覈質量。

   爲了更多地瞭解Fog Creek上的代碼審覈，請觀看下面的視頻：http://fast.wistia.net/embed/iframe/vigy79tuhq

• 注1：A binary decision is one that can have only two outcomes. Binary decisions are basic to many fields. http://en.wikipedia.org/wiki/Binary_decision 。關於二元決策圖，請參考：http://zh.wikipedia.org/wiki/%E4%BA%8C%E5%85%83%E5%86%B3%E7%AD%96%E5%9B%BE

   原文地址(source)：http://blog.fogcreek.com/increase-defect-detection-with-our-code-review-checklist-example/