【轉】程式設計師必備的程式碼審查（Code Review）清單

敏捷中高效開發的一個方法“結對開發”，目前沒有看到哪個開發團隊有這樣實行。不嚴謹的開發思維會造成後續出現很多缺陷，補救方法：程式碼審查 尤其重要。但卻苦惱如何在開發人員中進行推進。

以下僅供本人學習使用，文章來源：https://blog.csdn.net/wongdei123321/article/details/79012466?utm_source=blogxgwz1，侵刪。原文連結：http://blog.jobbole.com/83595/

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

軟體工程學院的研究表明，程式設計師們會犯15-20種常見的錯誤。所以，通過把這些錯誤加入到檢查清單當中，你可以確保不論什麼時候，只要這些錯誤發生了，你就能發現它們，並且可以幫助你杜絕這些錯誤。

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

程式碼審查清單

常規項

程式碼能夠工作麼？它有沒有實現預期的功能，邏輯是否正確等。

所有的程式碼是否簡單易懂？

程式碼符合你所遵循的程式設計規範麼？這通常包括大括號的位置，變數名和函式名，行的長度，縮排，格式和註釋。

是否存在多餘的或是重複的程式碼？

程式碼是否儘可能的模組化了？

是否有可以被替換的全域性變數？

是否有被註釋掉的程式碼？

迴圈是否設定了長度和正確的終止條件？

是否有可以被庫函式替代的程式碼？

是否有可以刪除的日誌或除錯程式碼？

安全

所有的資料輸入是否都進行了檢查（檢測正確的型別，長度，格式和範圍）並且進行了編碼？

在哪裡使用了第三方工具，返回的錯誤是否被捕獲？

輸出的值是否進行了檢查並且編碼？

無效的引數值是否能夠處理？

文件

是否有註釋，並且描述了程式碼的意圖？

所有的函式都有註釋嗎？

對非常規行為和邊界情況處理是否有描述？

第三方庫的使用和函式是否有文件？

資料結構和計量單位是否進行了解釋？

是否有未完成的程式碼？如果是的話，是不是應該移除，或者用合適的標記進行標記比如‘TODO’？

測試

程式碼是否可以測試？比如，不要新增太多的或是隱藏的依賴關係，不能夠初始化物件，測試框架可以使用方法等。

是否存在測試，它們是否可以被理解？比如，至少達到你滿意的程式碼覆蓋(code coverage)。

單元測試是否真正的測試了程式碼是否可以完成預期的功能？

是否檢查了陣列的“越界“錯誤？

是否有可以被已經存在的API所替代的測試程式碼？

你同樣需要把特定語言中有可能引起錯誤的問題新增到清單中。

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

優化你的清單

把使用清單作為你的起點，針對特定的使用案例，你需要對其進行優化。一個比較棒的方式就是讓你的團隊記錄下那些在程式碼審查過程中臨時發現的問題，有了這些資料，你就能夠確定你的團隊常犯的錯誤，然後你就可以量身定製一個審查清單。確保你刪除了那些沒有出現過的錯誤。（你也可以保留那些出現概率很小，但是非常關鍵的專案，比如安全相關的問題）。

得到認可並且保持更新

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

有了一個好的清單，可以提高你在程式碼審查過程中發現的缺陷個數。這可以幫助你提高程式碼標準，避免質量參差不齊的程式碼審查。