程序員必備的代碼審查（Code Review）清單

本文由  伯樂在線 -  Lingfeng Ai 翻譯， 進林 校稿。未經許可，禁止轉載！
英文出處： fogcreek。歡迎加入 翻譯小組。

在咱們關於高效代碼審查的博文中，咱們建議使用一個檢查清單。在代碼審查中，檢查清單是一個很是好的工具——它們保證了審查能夠在你的團隊中始終如一的進行。它們也是一種保證常見問題可以被發現並被解決的便利方式。

軟件工程學院的研究代表，程序員們會犯15-20種常見的錯誤。因此，經過把這些錯誤加入到檢查清單當中，你能夠確保不論何時，只要這些錯誤發生了，你就能發現它們，而且能夠幫助你杜絕這些錯誤。

爲了幫助你開始建立一個清單，這裏列出了一些典型的內容：

代碼審查清單

常規項

• 代碼可以工做麼？它有沒有實現預期的功能，邏輯是否正確等。
• 全部的代碼是否簡單易懂？
• 代碼符合你所遵循的編程規範麼？這一般包括大括號的位置，變量名和函數名，行的長度，縮進，格式和註釋。
• 是否存在多餘的或是重複的代碼？
• 代碼是否儘量的模塊化了？
• 是否有能夠被替換的全局變量？
• 是否有被註釋掉的代碼？
• 循環是否設置了長度和正確的終止條件？
• 是否有能夠被庫函數替代的代碼？
• 是否有能夠刪除的日誌或調試代碼？

安全

• 全部的數據輸入是否都進行了檢查（檢測正確的類型，長度，格式和範圍）而且進行了編碼？
• 在哪裏使用了第三方工具，返回的錯誤是否被捕獲？
• 輸出的值是否進行了檢查而且編碼？
• 無效的參數值是否可以處理？

文檔

• 是否有註釋，而且描述了代碼的意圖？
• 全部的函數都有註釋嗎？
• 對很是規行爲和邊界狀況處理是否有描述？
• 第三方庫的使用和函數是否有文檔？
• 數據結構和計量單位是否進行了解釋？
• 是否有未完成的代碼？若是是的話，是否是應該移除，或者用合適的標記進行標記好比‘TODO’？

測試

• 代碼是否能夠測試？好比，不要添加太多的或是隱藏的依賴關係，不可以初始化對象，測試框架可使用方法等。
• 是否存在測試，它們是否能夠被理解？好比，至少達到你滿意的代碼覆蓋(code coverage)。
• 單元測試是否真正的測試了代碼是否能夠完成預期的功能？
• 是否檢查了數組的「越界「錯誤？
• 是否有能夠被已經存在的API所替代的測試代碼？

你一樣須要把特定語言中有可能引發錯誤的問題添加到清單中。

這個清單故意沒有詳盡的列出全部可能會發生的錯誤。你不但願你的清單是這樣的，太長了以致於歷來沒人會去用它。僅僅包含常見的問題會比較好。

優化你的清單

把使用清單做爲你的起點，針對特定的使用案例，你須要對其進行優化。一個比較棒的方式就是讓你的團隊記錄下那些在代碼審查過程當中臨時發現的問題，有了這些數據，你就可以肯定你的團隊常犯的錯誤，而後你就能夠量身定製一個審查清單。確保你刪除了那些沒有出現過的錯誤。（你也能夠保留那些出現機率很小，可是很是關鍵的項目，好比安全相關的問題）。

獲得承認而且保持更新

基本規則是，清單上的任何條目都必須明確，並且，若是可能的話，對於一些條目你能夠對其進行二元斷定。這樣能夠防止判斷的不一致。和你的團隊分享這份清單而且讓他們認同你清單的內容是個好主意。一樣的，要按期檢查你的清單，以確保各條目仍然是有意義的。

有了一個好的清單，能夠提升你在代碼審查過程當中發現的缺陷個數。這能夠幫助你提升代碼標準，避免質量良莠不齊的代碼審查。

關於做者： Lingfeng Ai