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

英文原文：Stop More Bugs with our Code Review Checklist

在關于高效代碼審查的博客中，我們推薦使用清單（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

— END —

譯文： 《代碼審查清單可消除更多的 bug 》 臘八粥