Code Review 的重點是改善及控制 code quality，確保不會有糞 code 進到 master branch。
因為專案時程有時候非常緊急，review 的時候並沒辦法盡善盡美，因此需要將各個項目，依據重要程度還有急迫性來分級，藉此來達到有效的 code review。
以下是我自己在使用的優先順序分級：
如果時間非常趕，那我 review 的時候，就只會看「必須」，如果還有空間，我就會做「必須」及「基本」，如果專案急迫性不高，那就把「提升」的部分也加進來。
以下大致說明一下各個分級的項目：
必須：最低限度
最低限度，developer 一定要做到的，過了這個門檻才可以 commit 或 merge 進入主 branch，基本上有點像是能動就好。
程式是否符合需求
程式是否按造需求來實作。雖然有點像廢話XD，但真的有可能做出來的東西跟需求不符合，而這通常是溝通問題。
程式不會執行錯誤或造成意外終止
這不是開玩笑的，有些人寫出來的程式碼，真的一呼叫就壞了，而且除了自己的程式寫壞了，還可能搞壞別人的程式。
沒有改到不該改的 code
有些人會不小心動到別人的程式碼，或是修改的範圍不是本次需求的範圍，這是要特別注意的。
無明顯副作用
這次修改的程式雖然執行正確，但有可能會做出其他意料之外的行為。比如說 SQL 條件沒下對，會更新到其他資料。
基本：合格
合格的程式碼，除了會動，也要確保基本的品質，過了這個門檻，才算是合格的程式碼。時程很趕的話，不得已可以捨棄的部分，但建議安排時間回來改善。
符合 coding style、團隊規範
是否符合團隊制定或公認的 coding style，例如縮排要用 tab 還是空白字元。
命名
命名是否合理，確保高可讀性。不可以偷懶而使用沒有意義的變數或方法名稱。命名方式參考。
註解
註解是否有意義，不必要的註解不要多寫，會造成後續維護的困擾；過去的註解有沒有伴隨著程式碼的更改而妥善的更新。
符合語言特性
配合語言的特性撰寫，寫什麼語言就用該語言的邏輯去思考，例如，在 C/C++ 中處理字串可能很麻煩，但在 PHP 處理字串其實很容易，因此不要重複造輪子，要多使用 PHP 的 native 或 build-in function 來處理字串。
程式效能符合預期
需要檢查 Developer 選擇的做法，效能是否符合預期，只求不將複雜度為 O(1) 的程式寫成 O(n)，並不要求將 O(n) 的寫法改善為 O(1)。
提升：可以的話很好(Nice to have)
這邊的話，比較像是「建議」了，會需要更多討論，也比較多模稜兩可的空間。通常是在專案時程還有餘裕，或是比較重要的核心功能，需要多費點心力。
更好的寫法
語言一直在演進，舊的壞寫法會被淘汰，如果同一個行為有已知的更好寫法，可以建議使用。
提升可維護性、擴充性
跟前面一項有點相似，但這部分涵蓋的範圍會比較大。基本上就是可以採用一些 deisgn pattern 來增加程式未來的擴充性，可能會牽扯到結構上的改變，是風險比較大的改動，若無法掌握的話不建議提出這樣的 feedback。
程式效能優化
程式效能是否還有優化的空間，如果有的話，要怎麼做。比如說，要如何將一個複雜度為 O(n) 的寫法改善為 O(1)。
使用的函示庫、套件是否可靠
有些人非常仰賴第三方工具，但必須要確認這些工具是否有在維護，或者是否為成熟的套件。
小結
要達到有效的 code review 需要依據現實的狀況做調整，時間上有餘裕，才能更進一步往下做。工程師當然希望擁有足夠的時間來把事情做到最好，但是現實總不允許，會有各種奇怪的理由來打斷你，因此不應該為了追求完美而花了過多的時間，導致程式碼遲遲無法 merge，這樣對於 reviewer 及 developer 還有專案本身，都是一個很大的負擔，所以只好做出適當的取捨。
另外之前有提到，適當的 code review，除了是教育新進同仁的好方式以外，也是同事間互相提升能力的好方式，而且，人總是有機會犯錯，多一次 review，也多一點保險。