原文鏈接：http://blog.jobbole.com/83595/
項目Code?Review箕憾，自己一頭霧水福扬，以前的自己偷懶脯倒，根本沒有養(yǎng)成Code Review的好習慣愿吹，相信任何知識學了就不晚，學了就有用浊洞，多多學習牵敷，感謝作者的辛苦付出，致敬法希。
在我們關于高效代碼審查的博文中枷餐，我們建議使用一個檢查清單。在代碼審查中苫亦，檢查清單是一個非常好的工具——它們保證了審查可以在你的團隊中始終如一的進行毛肋。它們也是一種保證常見問題能夠被發(fā)現(xiàn)并被解決的便利方式。
軟件工程學院的研究表明屋剑，程序員們會犯15-20種常見的錯誤润匙。所以，通過把這些錯誤加入到檢查清單當中唉匾，你可以確保不論什么時候孕讳，只要這些錯誤發(fā)生了，你就能發(fā)現(xiàn)它們肄鸽，并且可以幫助你杜絕這些錯誤卫病。
為了幫助你開始創(chuàng)建一個清單，這里列出了一些典型的內容：
常規(guī)項
- 代碼能夠工作么典徘？它有沒有實現(xiàn)預期的功能，邏輯是否正確等益咬。
- 所有的代碼是否簡單易懂逮诲？
-?代碼符合你所遵循的編程規(guī)范么帜平？這通常包括大括號的位置，變量名和函數(shù)名梅鹦，行的長度裆甩，縮進，格式和注釋齐唆。
-?是否存在多余的或是重復的代碼嗤栓？
-?代碼是否盡可能的模塊化了？
-?是否有可以被替換的全局變量箍邮？
-?是否有被注釋掉的代碼茉帅？
-?循環(huán)是否設置了長度和正確的終止條件？
-?是否有可以被庫函數(shù)替代的代碼锭弊？
-?是否有可以刪除的日志或調試代碼堪澎？
安全
-?所有的數(shù)據(jù)輸入是否都進行了檢查（檢測正確的類型，長度味滞，格式和范圍）并且進行了編碼樱蛤？
-?在哪里使用了第三方工具，返回的錯誤是否被捕獲剑鞍？
-?輸出的值是否進行了檢查并且編碼昨凡？
-?無效的參數(shù)值是否能夠處理？
文檔
-?是否有注釋蚁署，并且描述了代碼的意圖便脊？
-?所有的函數(shù)都有注釋嗎？
-?對非常規(guī)行為和邊界情況處理是否有描述形用？
-?第三方庫的使用和函數(shù)是否有文檔就轧？
-?數(shù)據(jù)結構和計量單位是否進行了解釋？
-?是否有未完成的代碼田度？如果是的話妒御，是不是應該移除，或者用合適的標記進行標記比如‘TODO’镇饺？
測試
-?代碼是否可以測試乎莉？比如，不要添加太多的或是隱藏的依賴關系奸笤，不能夠初始化對象惋啃，測試框架可以使用方法等。
-?是否存在測試监右，它們是否可以被理解边灭？比如，至少達到你滿意的代碼覆蓋(code coverage)健盒。
-?單元測試是否真正的測試了代碼是否可以完成預期的功能绒瘦？
-?是否檢查了數(shù)組的“越界“錯誤称簿？
-?是否有可以被已經(jīng)存在的API所替代的測試代碼？
-?你同樣需要把特定語言中有可能引起錯誤的問題添加到清單中惰帽。
-?這個清單故意沒有詳盡的列出所有可能會發(fā)生的錯誤憨降。你不希望你的清單是這樣的，太長了以至于從來沒人會去用它该酗。僅僅包含常見的問題會比較好授药。
優(yōu)化你的清單
把使用清單作為你的起點，針對特定的使用案例呜魄，你需要對其進行優(yōu)化悔叽。一個比較棒的方式就是讓你的團隊記錄下那些在代碼審查過程中臨時發(fā)現(xiàn)的問題，有了這些數(shù)據(jù)耕赘，你就能夠確定你的團隊常犯的錯誤骄蝇，然后你就可以量身定制一個審查清單。確保你刪除了那些沒有出現(xiàn)過的錯誤操骡。（你也可以保留那些出現(xiàn)概率很小九火，但是非常關鍵的項目，比如安全相關的問題）册招。
得到認可并且保持更新
基本規(guī)則是岔激，清單上的任何條目都必須明確，而且是掰，如果可能的話虑鼎，對于一些條目你可以對其進行二元判定。這樣可以防止判斷的不一致键痛。和你的團隊分享這份清單并且讓他們認同你清單的內容是個好主意炫彩。同樣的，要定期檢查你的清單絮短，以確保各條目仍然是有意義的江兢。
有了一個好的清單，可以提高你在代碼審查過程中發(fā)現(xiàn)的缺陷個數(shù)丁频。這可以幫助你提高代碼標準杉允，避免質量參差不齊的代碼審查。
