關於code reiview

先談談三個code review的關鍵因素：

1、建立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），至關方便、快捷。

2、作review要方便

review的過程，是一個就代碼相互交流的過程，爲了使這個交流更加高效，咱們須要明確知道在討論的是哪一行代碼 - 顯然，用郵件是一件至關愚蠢的事情，就像有些人吹噓用notepad寫代碼同樣。如今市面上這樣的系統很是多了：我用過的就有code collaborator, crucible。能夠直接就某一行代碼開展討論，並及時郵件通知。

3、被review的change要靠譜

你必須在發出review以前，先review本身的代碼 - 編譯過了嗎，迴歸測試過了嗎? 新feature功能實現了嗎？bug真的fix掉了嗎？ 本身啥都不作，寫完代碼就發review，而後指望別人可以幫你發現問題（把別人當你的編譯器，測試工具？）是很是不負責任的作法，尤爲是對本身的不負責，長此以往，你在team中名氣大臭，終將失去全部人的信任。

 

再談談四個code review的重要做用：

1、威懾

這是我感觸最深的一點：知道本身的change會被review，那麼在作這個change的過程中，你就會比較負責任的往代碼全局最優的方向去修改，而不是爲了臨時解決本身當前的問題選擇一個比較醜陋的方案 - 由於你知道，即便你選了這個醜陋的方案，而後作了編譯測試，發出review以後仍是會被人以正當的理由退回來，與其浪費那麼些時間作無用功，還被人很沒面子的退回來，還不如一開始就作的漂漂亮亮的，長此以往，這種追求最優的習慣就會養成。

2、把關

別人能幫你發現你視覺盲點中，或者視野範圍外的一些問題。畢竟，多我的多雙眼睛，尤爲對於比較senior，或者該領域的專家來講，總能對你有所裨益！

3、學習

別人能從你的代碼中學習你優秀的解決問題的思路，寫代碼的技巧，這是team總體提高的一條很是好的道路。事實上，培養新人的一個方法，除了讓他fix bug以外，就是讓他review代碼，固然，通常是做爲副手。

4、通知

讓整個team的人知道將有這麼個change，咱們的作法是建立一個mailgroup：team-cr，把team中每一個人都加進來，而後每一個review都cc這個組 - 而後對於那些有時間、有須要的同窗，就能夠監控這個組的郵件。