在關於高效程式碼審查的部落格中，我們推薦使用清單（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
來自：部落格園
相關閱讀
評論(3)