本文來源於我在InfoQ中文站原創的文章，原文地址是：http://www.infoq.com/cn/news/2013/11/code-review-why-when-how
對於很多公司來說，代碼審查是開發人員日常工作中的重要環節。通過代碼審查，可以及早發現項目中存在的問題、促進同事之間的溝通與交流，並且可以在討論中迸發出智慧的火花。但要想成功實施代碼審查卻並不是一件輕鬆的事情，爲什麼要進行代碼審查、何時做、如何做，這是擺在我們面前的3個重要問題。針對於這3個問題，開發者Lisa Tjapkes撰文談到了自己的經驗與教訓。
在我最近的項目經歷中，我們進行了廣泛且正式的代碼審查。這個過程極大地改進了項目的代碼質量，降低了項目中新特性開發的等待時間，同時還促進了知識在整個 團隊間的傳播與共享。我還發現代碼審查並不會延誤項目開發的時間，反而會提升開發人員的生產力。
代碼審查的好處
我們發現代碼審查對於項目的各個階段都會帶來很多好處：
- 在項目起始階段進行代碼審查會幫助我們更好地使用已經建立起來的代碼基，因爲如果我們沒有使用過某些現有代碼，那麼可以從當前的開發者中獲得反饋信息。
- 在項目進行過程中，我們會時不時地向團隊增加新的開發人員，代碼審查可以極大地降低這些新加入的人員的熟悉時間。特別地，我們可以讓新加入的開發人員很有信心地開發新特性，因爲我們可以在合併前審查代碼並且對於他們所編寫的任何代碼提供有價值的反饋信息。
- 對於我們這個分佈式團隊來說，代碼審查更加具有實際意義。團隊協同在構建協作環境上會帶來很大的幫助作用，我們可以即時提出想法、然後討論，再進行開發。雖然由於不在同一地點我們會失去一些東西，不過我們卻可以在代碼審查過程中通過深入的討論來獲得好處。
高效代碼審查的技巧
代碼審查的方式如果處理不當可能會導致項目延期。使用正確的工具與技術可以防止在審查上浪費大量的時間，提升代碼的品質。
使用特性分支
這個實踐的好處就不用多說了，不過它對代碼審查提供了更加具體的好處。特性分支意味着你可以將需要審查的代碼隔離到只與某個具體的特性相關。在代碼已經準備好了審查時，特性分支還考慮到了快速的上下文切換。在當前的代碼進行審查時，你可以切換到新的特性上來，如果需要對審查特性的反饋進行討論時還可以快速切換回來。
將審查隔離爲小的修改
相對於大的修改來說，小修改的審查時間會更少。在審查大的修改時，你不僅要看很多行代碼，還要查看大量的依賴代碼才能真正理解，結果就是花在審查代碼上的時間與修改的代碼量之間並不是呈線性關係。將待審查的代碼隔離爲小的修改可以降低審查者的精神負擔並讓審查過程更加順暢。
使用專門爲代碼審查而設計的工具
這看起來似乎很簡單，但卻非常重要。一些重要的特性需要包含差異比較、能夠逐行註釋修改，並且在審查的代碼發生改變時通知大家。我所在的團隊使用GitHub來管理項目代碼，並且使用GitHub的pull request特性來管理代碼審查。
檢查清單
可能沒必要使用非常複雜或是過於結構化的東西，如果突然出現了某些問題，使用檢查清單或許是個不錯的主意。
有建設性的輸入
類似於“多加點註釋”這樣的話顯得太沒意義了，幫助也不大。假如某個接口沒有註釋，但也許有專門的文檔用來說明呢。如果發現了某些不合理的地方，那就要明確指出來，判斷設計上是否能改進或是邏輯上是否存在着錯誤。
要把精力放在真正理解代碼的行爲上，確保當其他人需要維護它時也能夠快速理解代碼。
人人蔘與
即便是最有經驗的架構師或是明星開發者也會犯錯。因此，最好每個人都能參與到代碼審查的過程中來。特別地，對於很多初級開發者或是新加入項目的開發者來說，這也是個很不錯的學習機會。
要有審查流程
一開始，我們的項目並沒有正規的審查流程。我們只是開啓一個pull request，等待有人來審查，最後會有人合併修改。這種工作方式效率非常差，有時好幾天都沒人審查一個pull request，有時一個人給出反饋前其他人卻合併了請求。此外，有些開發者審查的代碼量要比其他人多不少。總而言之，沒有流程導致我們的效率極低。
最後我們認識到了這一點，創建了一個正式的結構來指導該如何進行代碼審查，這加速了審查的效率。一個審查過程至少應該涵蓋如下幾點：
- 如何將審查任務分派給不同的人
- 期待審查者給出反饋的最遲時間
- 如何標識某個審查已經完成
- 誰負責合併已經完成審查的代碼
我在項目中是否應該進行代碼審查？
我認爲代碼審查對於很多項目來說都是一件好事，不過它也並非通用的解決方案。代碼審查適合於如下這些項目：
- 至少有5名開發人員
- 在向團隊增加新的開發人員時
- 團隊是分佈式的
- 項目有各種不同的組件構成，這些組件是由不同團隊開發的
- 當還處在爲代碼基設定約定以及最佳實踐的階段
- 團隊中有些成員對於當前所使用的技術棧還不太熟悉時
相反，代碼審查在如下的情形中並不會爲項目帶來更多的附加值：
- 處理的是維護代碼而不是添加新的特性
- 團隊很小且親密無間