代碼審查清單可消除更多的bug
在關于高效代碼審查的博客中，我們推薦使用清單(checklist)。清單是代碼審查中的偉大工具——他們確保審查在團隊里持續高效。它們也是確保常見問題被識別、解決的方便途徑。
軟件工程協會的研究表明，程序員常犯的錯誤有15-20種。因此把這種錯誤增加到清單里，你就能確保在它們出現時指出來，幫助消除這種隱患。
為了讓你開始建立清單，下面是經典的條目列表：
代碼審查清單
總體
-
代碼能運行嗎？代碼實現了想要實現的功能了嗎，邏輯是正確的嗎，等等。
-
所有代碼都很容易理解嗎？
-
它遵循了你們都同意的代碼規范嗎？規范通常包括花括號的位置、變量和函數的命名、行長度、縮進、格式和注釋。
-
有多余的或重復的代碼？
-
代碼盡可能模塊化了？
-
全局變量能被替換？
-
有任何被注釋掉的代碼？
-
循環結構里有固定的長度值和正確的結束條件？
-
有代碼可以被類庫函數取代？
-
日志和調試代碼可以被移除？
-
所有數據輸入都被校驗(為了正確的類型、長度、格式和范圍)和轉碼了？
-
第三方工具集在哪里用到了，能夠返回被捕捉到的錯誤嗎？
-
輸出值經過校驗和轉碼了？
-
不合法的參數值得到處理了？
-
有文檔嗎，文檔描述了代碼意圖嗎？
-
所有的函數都加注釋了？
-
任何不尋常的行為和邊界處理都做說明了？
-
就第三方類庫的使用和功能寫文檔了？
-
所有的數據結構和測試單元都做解釋了？
-
有不完整的代碼？如果有，它應該被移除還是打上’TODO‘之類的適當標記？
-
代碼可測試嗎？比如，不要增加太多的或隱藏的依賴，不能夠實例化對象，測試框架能夠使用方法等。
-
有測試嗎，它們全面嗎？比如，至少包含了你們認可的代碼覆蓋率嗎？
-
單元測試實際地測試了代碼正在實現的目標功能了？
-
數組檢查’越界‘錯誤了？
-
測試代碼可被已有API的應用取代嗎？
-
注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
安全
文檔
測試
你還可以為清單增加一些語言相關的問題。
該清單故意沒有包含所有的問題，你并不想一個長長的清單，以致于沒人去使用。只需覆蓋常見問題即可。
優化你的清單
把該清單做為一個起點，你應該針對具體用例進行優化。有個不錯的辦法，那就是讓你的團隊在代碼審核時，花一點時間提出所產生的問題。有了這些數據，你就能夠甄別出團隊的常見錯誤，然后就被改造成常見清單。要確保刪除那些不會發生的條目(你或許希望保持較少地發生，還有諸如安全相關的重要條目)。
集思廣益，及時更新
做為通用法則，清單上的條目應該是具體的，如果有可能，你可以就此做一份二元決策【注1】。這有助于避免判斷上的矛盾，與團隊分享清單，并得到他們對于內容的認同也是不錯的主意。確保定期審查清單，檢查每一項以確保仍然相關。
有了優秀的清單武裝，你就可以增加代碼審核中的瑕疵數量。這有助于你提升代碼質量、避免不穩定的代碼審核質量。
為了更多地了解Fog Creek上的代碼審核，請觀看下面的視頻：http://fast.wistia.net/embed/iframe/vigy79tuhq
原文地址(source)：http://blog.fogcreek.com/increase-defect-detection-with-our-code-review-checklist-example/