代碼審查(code review)的意義

個人理解，code review有兩個作用：

1. 兩個人總比一個人想的周全，看問題的角度不一樣更容易發現BUG或找到更簡單有效解決方案。所謂旁觀者清就是這個道理。

2. 理想狀態下團隊的每個人都要對項目的每個部分都很熟悉，但當項目很大時這不大現實，通過代碼審查至少可以讓每個人瞭解更多的業務模組，同時也能達到人員互備的目的。

同時代碼審查要注意如下問題：

1. 審核者與被審核者的不存在能力高低問題。代碼審查是為了提高整個團隊的能力，而不是針對個體設定的檢查“關卡”。“A的代碼有個bug被B發現，所以A能力不行，B能力更好”，這是一個誤區。

2. 代碼審查本身可以提高開發人員的能力：被審查者從自身犯過的錯誤中學習，從他人的思路中學習；審查者從審查的思考過程中學習，從被審查者好的設計中學習。

3. 代碼審查不涉及獎懲機制，即便有也是對審查者和被審查者同時的獎勵或處罰，也就是說兩者要同時對交付負責。

code review採取的方式：

實踐中，我們團隊成員建議的閉環式審查很適用。如4個人的子團隊，審查關係為A --> B --> C --> D --> A（B審查A，C審查B，D審查C，A審查D）。當然，要適成員能力做到高低的有效穿插。那麼讓初級工程師審查進階工程師的代碼是否有問題呢，能發現BUG麼。首先，肯定能發現BUG，只是多少和頻率的問題；其次，即便初級工程師發現不了進階工程師的BUG，在審查進階工程師的代碼時也能學習到好的思路和業務知識，這也是很有意義的，間接起到培訓的作用了。

code review的單元粒度及時間問題：

以future和task任務為單元做review較容易實施，大規模review可以在重大改進時單獨發起。同時，把review結合到任務工作流程裡也是不錯的實踐。如：start --> 設計 --> 開發 --> code review --> 測試 --> 產品確認 --> end。

一個review單元的時間應控制在10~20分鐘。如果超出這個時間，可能是如下幾個原因：

1. 如果20分鐘一個reviewer還看不懂一個任務的代碼，那麼這個代碼本身就存在問題，太複雜了；

2. reviewer不懂業務，那麼開發人員就需要向reviewer講解下了，當然不需講解就能看懂的代碼自然是更好了；

3. 任務太大，代碼太多，那麼這個任務應該拆分，分階段交付產出。

參考資源：

http://www.infoq.com/cn/news/2014/02/code-review-best-practice?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=%E7%BC%96%E7%A8%8B-news