Code Review好處

• 確保程式碼的品質不會下降：很多時候開發者可能為了趕時間，或者因為過去沒有養成良好的洗寫程式習慣，所以會寫出品質不佳的程式碼。Code Review 可以作為一個關卡，確保品質不佳的程式碼不會被合入
• 除了確保當前的程式碼庫品質不會下降外，透過 Code Review 也能確保程式碼未來的可維護性是足夠好的。很多時候自己寫程式會有盲點，可以透過其他人的角度來看程式是否好維護
• Code Review 是團隊資深工程師，來協助初階工程師成長的好時機。從對程式語言的理解，到框架的使用，再到各種設計模式，都可以透過 Code Review 傳承
• 更進一步來說，Code Review 是團隊文化的塑造。如果做得好，能協助發展出好的團隊文化，例如正向的團隊交流氛圍；反之，如果做不好，可能讓團隊充斥有毒的文化。
• 反過來說，對於剛加入團隊的人，參與 Code Review 是個學習機會，在 Review 的過程中，能學習系統中不同部分的，也可以去看別人怎麼寫，贈加對於寫程式的理解

Code Review 不該包含什麼?

上面談了 Code Review 可以帶來幫助，但與此同時，有些事情不該是由 Code Review 來達成，在這邊展開來討論。

• 如果是能自動化處理的東西，不該由 Code Review 來做。

  舉例來說，縮排要多少個空格、要不要加 ; 到每行程式的尾端、要用單駝峰還是雙駝峰格式。這些東西都可以透過 Linting 工具來達成。工程師的時間寶貴，不該花在這些事上面。如果你發現 Code Review 出現這類討論，那推薦可以主動去設置 Linting 來一勞永逸解決。

• Code Review 的核心目的不是幫忙看有沒有 bug。

  前面有談到，Code Review 作用之一是確保程式碼庫的品質，但這不代表幫忙看有沒有 bug。事實上，先前微軟有發表一篇研究，發現 Code Review 對於找到 bug 的功用來說不大。要確認沒有 bug，還是需要透過測試來做到，包含自動化測試與人工手動測試。

Code Review切入面向

程式設計面向

• 沒有會影響到不該影響的副作用 (side effects)?
• 可能有錯誤的地方，都有做錯誤處理 (error handing) 嗎?
• 有考量兼容性 (backward compatability)? 新的改動會不會導致其他功能出問題? 例如：如果 API 加上新的輸入參數，就要思考會不會讓線上已經在呼叫該 API 的客戶端呼叫失敗。
• 確認是否複雜度沒有過高、沒有過度工程 (over engineering)? 換個角度想，可以思考是否有更簡單的寫法? 如果有的話，可以在 Code Review 提出