代碼審查的重要性
- 代碼審查是熟悉軟件架構，了解軟件業務邏輯的好方法。學習代碼是需要切入點的，一個上百萬行代碼的系統，從哪里開始着手？只能一個模塊一個模塊，一個組件一個組件的來熟悉，掌握。實現一個比較大的功能，你應該不會是唯一的開發人員，從系統架構師輸出的系統設計，然后到各個團隊中技術 Leader 輸出的 component 級別的設計，到開始實現時，應該會把功能分為不同的模塊有不同的開發人員協同實現。這是個學習的機會，不要只局限於自己這部分，為了了解這個大的功能，甚至和這個功能相關的其他已經實現的功能，你同樣需要關注其他人的工作。有目的的看代碼和漫無目的的瀏覽效果是不一樣的，你已經對新功能有所了解，審查代碼之前，你認為代碼會怎么寫，別人哪里和你想的不一樣，舊功能和新功能是如何相互影響的等等，心里懷着問題，你的學習速度會更快，記得更加深刻。
- 代碼審查是你提高自己的好方法。前提是 team 中有經驗豐富的開發人員的存在。也就是大牛，不要錯過讓他看你代碼的機會，不要害怕他會為你寫的代碼挑出一大堆問題，有人說你自己寫的代碼就像自己的孩子，見不得別人說半點不字，不要固執，要內心平靜的，客觀的去看待你所寫的代碼，發現並解決問題才能提高你自己。也不要錯過去review大牛代碼的機會，看看大牛寫出來的代碼是怎樣的，你可以取其精華。
- 代碼審查是需要功力的。網上有帖子說程序員的資深與否和工作年限沒有必然聯系，你是5年工作經驗還是一個經驗用了5年，這需要你去刻意練習，剛開始 reveiew 代碼的時候你可能不習慣，也可能很痛苦，面對的一屏幕的代碼不知如何下眼。但有一句話，如果你覺的內心很舒服，你就是在原地踏步。覺的痛苦說明你是在爬坡，刻意的去聯系自己的大腦吧，今天你看一頁代碼可能用了一個小時，沒有發現問題，但是堅持一個月甚至三個月之后，你看一眼就能夠發現代碼中的缺陷，恭喜你，你的功力加深了。
代碼審查清單
常規項
- 代碼能夠工作么？它有沒有實現預期的功能，邏輯是否正確等。
- 所有的代碼是否簡單易懂？
- 代碼符合你所遵循的編程規范么？這通常包括大括號的位置，變量名和函數名，行的長度，縮進，格式和注釋。
- 是否存在多余的或是重復的代碼？
- 代碼是否盡可能的模塊化了？
- 是否有可以被替換的全局變量？
- 是否有被注釋掉的代碼？
- 循環是否設置了長度和正確的終止條件？
- 是否有可以被庫函數替代的代碼？
- 是否有可以刪除的日志或調試代碼？
安全
- 所有的數據輸入是否都進行了檢查（檢測正確的類型，長度，格式和范圍）並且進行了編碼？
- 在哪里使用了第三方工具，返回的錯誤是否被捕獲？
- 輸出的值是否進行了檢查並且編碼？
- 無效的參數值是否能夠處理？
文檔
- 是否有注釋，並且描述了代碼的意圖？
- 所有的函數都有注釋嗎？
- 對非常規行為和邊界情況處理是否有描述？
- 第三方庫的使用和函數是否有文檔？
- 數據結構和計量單位是否進行了解釋？
- 是否有未完成的代碼？如果是的話，是不是應該移除，或者用合適的標記進行標記比如‘TODO’？
測試
- 代碼是否可以測試？比如，不要添加太多的或是隱藏的依賴關系，不能夠初始化對象，測試框架可以使用方法等。
- 是否存在測試，它們是否可以被理解？比如，至少達到你滿意的代碼覆蓋(code coverage)。
- 單元測試是否真正的測試了代碼是否可以完成預期的功能？
- 是否檢查了數組的“越界“錯誤？
- 是否有可以被已經存在的API所替代的測試代碼？
你同樣需要把特定語言中有可能引起錯誤的問題添加到清單中。
優化你的清單
把使用清單作為你的起點，針對特定的使用案例，你需要對其進行優化。一個比較棒的方式就是讓你的團隊記錄下那些在代碼審查過程中臨時發現的問題，有了這些數據，你就能夠確定你的團隊常犯的錯誤，然后你就可以量身定制一個審查清單。確保你刪除了那些沒有出現過的錯誤。（你也可以保留那些出現概率很小，但是非常關鍵的項目，比如安全相關的問題）。
得到認可並且保持更新
和你的團隊分享這份清單並且讓他們認同你清單的內容是個好主意。同樣的，要定期檢查你的清單，以確保各條目仍然是有意義的。
有了一個好的清單，除了可以提高你在代碼審查過程中發現的缺陷個數，還可以幫助團隊成員更好更快的進行代碼審查。