首先，我們先來看看Code Reivew的用處：
　　Code reviews 中，可以通過大家的建議增進代碼的質量。
　　Code reviews 是一個傳遞知識的手段，可以讓其它并不熟悉代碼的人知道作者的意圖和想法，從而可以在以后輕松維護代碼。
　　Code reviews 也鼓勵程序員們相互學習對方的長處和優點。
　　Code reviews 也可以被用來確認自己的設計和實現是一個清楚和簡單的。
　　你也許注意到了在上面的Code Reivew中的諸多用處中，我們沒有提到可以幫助找到程序的bug和保證代碼風格和編碼標準。這是因為我們認為：

　　Code reviews 不應該承擔發現代碼錯誤的職責。Code Review主要是審核代碼的質量，如可讀性，可維護性，以及程序的邏輯和對需求和設計的實現。代碼中的bug和錯誤應該由單元測試，功能測試，性能測試，回歸測試來保證的（其中主要是單元測試，因為那是最接近Bug，也是Bug沒有擴散的地方）
　　Code reviews 不應該成為保證代碼風格和編碼標準的手段。編碼風格和代碼規范都屬于死的東西，每個程序員在把自己的代碼提交團隊Review的時候，代碼就應該是符合規范的，這是默認值，屬于每個人自己的事情，不應該交由團隊來完成，否則只會浪費大家本來就不夠的時間。我個人認為“meeting”是奢侈的，因為那需要大家在同一時刻都擠出時間，所以應該用在最需要的地方。代碼規范比起程序的邏輯和對需求設計的實現來說，太不值得讓大家都來了。
　　10年前，上面這兩件事會是理所當然的（10年前的中國的軟件開發還沒有Code Reivew呢），今天，在中國的很多公司上面這兩件事依然被認為是Code Reivew最重要的事，所以，我能夠看到很多開發Team抱怨Code Review就是一個形式，費時費力不說，發現的問題還不如測試，而評審者們除了在代碼風格上有些見術，別的也就沒什么用了，長而久之，大家都會開始厭煩這個事了。
　　所以，在今天，請不要把上面的那兩件事分散了Code Review的注意力，取而代之的是，對于Bug，程序的作者要在Review前提交自己的單元測試報告（如：XUnit的測試結果），對于代碼規范，這是程序作者自己需要保證的，而且，有一些工具是可以幫你來檢查代碼規范的。