先談談三個code review的關鍵因素：
一、建立review要簡單
code reivew是一個程式設計師日常工作中經常做的一件事，理論上來講，任何一個將要submit到SCM的change，都必須經過peer review。如果建立一個review要傻了吧唧的打包程式碼，傳送郵件，或者shelve一個changelist，再發信告知changelist number，或者進入某個比較先進的code review系統（比如crucible）手工建立一個review，這些步驟都太過繁瑣，任何一個懶惰的程式設計師都不會有耐心來做這種事，更別說日復一日的做這種愚蠢的事了。
我們需要的是一鍵式建立review - 一個按鈕，搞定！ 比如我以前公司用一個p4外掛，直接右鍵一個pending changelist，就可以建立一個code review(code collaborator)；我現在公司則更加全面，更加徹底，提供了一個命令，可以cover不同的scm，不同的code review系統（支援crucible，gerrit），相當方便、快捷。
二、做review要方便
review的過程，是一個就程式碼相互交流的過程，為了使這個交流更加高效，我們需要明確知道在討論的是哪一行程式碼 - 顯然，用郵件是一件相當愚蠢的事情，就像有些人吹噓用notepad寫程式碼一樣。現在市面上這樣的系統非常多了：我用過的就有code collaborator, crucible。可以直接就某一行程式碼開展討論，並及時郵件通知。
三、被review的change要靠譜
你必須在發出review之前，先review自己的程式碼 - 編譯過了嗎，迴歸測試過了嗎? 新feature功能實現了嗎？bug真的fix掉了嗎？ 自己啥都不做，寫完程式碼就發review，然後期望別人能夠幫你發現問題（把別人當你的編譯器，測試工具？）是非常不負責任的做法，尤其是對自己的不負責，久而久之，你在team中名氣大臭，終將失去所有人的信任。
再談談四個code review的重要作用：
一、威懾
這是我感觸最深的一點：知道自己的change會被review，那麼在做這個change的過程當中，你就會比較負責任的往程式碼全域性最優的方向去修改，而不是為了臨時解決自己當前的問題選擇一個比較醜陋的方案 - 因為你知道，即使你選了這個醜陋的方案，然後做了編譯測試，發出review之後還是會被人以正當的理由退回來，與其浪費那麼些時間做無用功，還被人很沒面子的退回來，還不如一開始就做的漂漂亮亮的，久而久之，這種追求最優的習慣就會養成。
二、把關
別人能幫你發現你視覺盲點中，或者視野範圍外的一些問題。畢竟，多個人多雙眼睛，尤其對於比較senior，或者該領域的專家來說，總能對你有所裨益！
三、學習
別人能從你的程式碼中學習你優秀的解決問題的思路，寫程式碼的技巧，這是team整體提升的一條非常好的道路。事實上，培養新人的一個方法，除了讓他fix bug之外，就是讓他review程式碼，當然，一般是作為副手。
四、通知
讓整個team的人知道將有這麼個change，我們的做法是建立一個mailgroup：team-cr，把team中每個人都加進來，然後每個review都cc這個組 - 然後對於那些有時間、有需要的同學，就可以監控這個組的郵件。