怎麼進行代碼審查（Code Review）

代碼審查的重要性

• 代碼審查是熟悉軟件架構，瞭解軟件業務邏輯的好方法。學習代碼是須要切入點的，一個上百萬行代碼的系統，從哪裏開始着手？只能一個模塊一個模塊，一個組件一個組件的來熟悉，掌握。實現一個比較大的功能，你應該不會是惟一的開發人員，從系統架構師輸出的系統設計，而後到各個團隊中技術 Leader 輸出的 component 級別的設計，到開始實現時，應該會把功能分爲不一樣的模塊有不一樣的開發人員協同實現。這是個學習的機會，不要只侷限於本身這部分，爲了瞭解這個大的功能，甚至和這個功能相關的其餘已經實現的功能，你一樣須要關注其餘人的工做。有目的的看代碼和漫無目的的瀏覽效果是不同的，你已經對新功能有所瞭解，審查代碼以前，你認爲代碼會怎麼寫，別人哪裏和你想的不同，舊功能和新功能是如何相互影響的等等，內心懷着問題，你的學習速度會更快，記得更加深入。
• 代碼審查是你提升本身的好方法。前提是 team 中有經驗豐富的開發人員的存在。也就是大牛，不要錯過讓他看你代碼的機會，不要懼怕他會爲你寫的代碼挑出一大堆問題，有人說你本身寫的代碼就像本身的孩子，見不得別人說半點不字，不要執拗，要心裏平靜的，客觀的去看待你所寫的代碼，發現並解決問題才能提升你本身。也不要錯過去review大牛代碼的機會，看看大牛寫出來的代碼是怎樣的，你能夠取其精華。
• 代碼審查是須要功力的。網上有帖子說程序員的資深與否和工做年限沒有必然聯繫，你是5年工做經驗仍是一個經驗用了5年，這須要你去刻意練習，剛開始 reveiew 代碼的時候你可能不習慣，也可能很痛苦，面對的一屏幕的代碼不知如何下眼。但有一句話，若是你覺的心裏很舒服，你就是在原地踏步。覺的痛苦說明你是在爬坡，刻意的去聯繫本身的大腦吧，今天你看一頁代碼可能用了一個小時，沒有發現問題，可是堅持一個月甚至三個月以後，你看一眼就可以發現代碼中的缺陷，恭喜你，你的功力加深了。

代碼審查清單

常規項

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

安全

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

文檔

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

測試

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

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

優化你的清單

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

獲得承認而且保持更新

和你的團隊分享這份清單而且讓他們認同你清單的內容是個好主意。一樣的，要按期檢查你的清單，以確保各條目仍然是有意義的。

有了一個好的清單，除了能夠提升你在代碼審查過程當中發現的缺陷個數，還能夠幫助團隊成員更好更快的進行代碼審查。