什麼是Code Review
Code Review 中文的翻譯方式有很多種“代碼審查”，“代碼評審”，“代碼走查”等，個人更喜歡“代碼走查”這種翻譯。代碼走查是一個流程，從開發人員在一個開發階段寫好代碼後開始，之後需要別人以發現bug和技術交流爲目的review一下他的代碼。它是集代碼審查，找出問題，改進代碼和改後督查爲一體的完整的流程。代碼走查一般在代碼剛剛出爐爲最好，因爲在這個時候也是代碼重構和調整的最佳時候。
Code Review的目的及內容
功能性Review:
通過Review檢查當前代碼是否全部實現了需求裏面全部的功能點，且功能正確。找出代碼中的bug，每個人在寫和讀代碼的時候都有固有的習慣，這樣的一些習慣往往會影響代碼的質量。比如：我們在代碼編寫過程中都出現過類似的問題，自己代碼中的問題自己無論看了多少遍都發現不了，但別人一眼就能發現問題。出現這樣的情況並不是說寫代碼的人水平不高而是個人編程中的“無意識”錯誤。當然這也就是結隊編程的妙處。
可讀性Review:
代碼做爲軟件開發過程中最實時的文檔，同時爲了以後維護方便一定要有高度的可讀性。可讀性檢查主要檢查代碼風格是否嚴格按照系統代碼風格規定，代碼中是否經過充分的重構消除了其中冗餘重複的代碼。代碼結構是否合理。
分享技術知識：
“三人行必有我師”每個人的代碼都有值得別人學習的地方，而且團隊中各個成員水平高低不一，通過代碼Review使水平高的人的技術逐漸流向水平低的人培養了新人。同時代碼編寫者向團隊中的其他人介紹自己所用的技術和方法，這樣一方面使各種技術在團隊中得到共享。筆者在當前的公司裏面遇到這樣一個案例：
團隊1在之前的項目開發中用到freetype做中文排版，但是當時沒有做代碼review。之後團隊2也用到了freetype方面的知識但因爲不知道團隊1有freetype方面的知識，結果團隊2又花費了大量的時間和精力去重新研究和學習freetype。這樣大大延緩了項目的時間進度。
互爲backup：
通過代碼Review使更多的人瞭解當前模塊的功能，這樣減少了因人員流失而導致對項目產生的衝擊。
態度決定一切
Code Review 做爲軟件開發中的一個重要環節，也是人蔘與和交互度比較高的一個環節，參與者對Code Review的態度將會很大程度上影響Code Review的效果。而程序員又是一羣不善於同別人交流的一個羣體，這樣在Code Review的過程中可能因爲對這件事的認識程度和態度的不同而會產生很大差距：
對於代碼的講解者來說，一些很有經驗的程序員往往因爲對Code Review的目的等方面認識不足容易犯這樣一種錯誤，認爲自己的代碼不會有問題，這次Code Review就是給別人傳道授業解惑的。這樣會出現整個Code Review的過程基本拋棄了Code完全只講他實現的思路和方法，完全成爲了一個知識講座，但要知道整體設計和具體實現還有很大不同。你的宏觀思路很正確並不代表你的代碼就沒有一點問題。對於一些初來乍到的年輕人則會走向另一個極端，一說Code Review就像讓他去刑場一樣。就是爲了去接受審判而去Code Review,完全依賴於自己的代碼，沒有把自己在這個過程中所學到的東西全部講出來，這樣也不利於整個團隊的相互學習和提高。
Reviewer的態度：它們對Code Review的態度很大程度上決定了Code Review的效果。常見以下幾種情況：
漠不關心：這種態度的來源主要是覺得代碼不是自己寫的，也不用負什麼責任，對代碼走查的實際含義理解不清。想糊弄過去湊個人數結束。
藐視別人的代碼：這種心態長見於團隊中技術水平較高的成員中，在別人講解代碼的時候總覺得這個功能很容易實現，自己知道不用聽別人講了。這種人缺乏對團隊的責任感，和對團隊成員成果的尊重。
批評者：這類人對Code Review的目的是什麼認識不清，總以爲代碼走查就是找別人的錯，吊難別人。這種容易忽視別人代碼設計中的優點。做爲程序員每個人都有自負的一面，這樣在Code Review時常常會出現Code Review就是找別人錯誤的錯誤認識。
Code Review 的實施
一、Code Review 角色分類
1.Author：被Review對象的作者。
2.moderator：一般由團隊中開發經驗豐富的人擔任。
3.Recorder：主要用於記錄在整個代碼Review中情況。
4.Reader (may be the same person as Author or leader)
5.Other reviewers：團隊中的其它成員，但是一般不要人太多，因爲對於一個討論會議一來說一般要將參加會議的人控制在7人以內爲最佳，這樣這個會議纔是可控的。
以上這些角色的職能會在Code Review中的不階段而發生變化。
二、Code Review的流程及其角色在不同階段的任務
上圖顯示了整個Code Review活動流程情況，一般在一個Code Review活動會中Planning,Preparation,Meeting,Rework&Verfication是必須的，而Overview階段會隨着Review對象的不同而不同，對於一些Review工作大量的活動這個階段是必須的，下面將詳細描述每個階段的任務，以及各個角色在相對應階段的責任。
1.Planning:
這個階段主要是對各個角色人員的確定以及確定所Review的對象是否已經達到能夠被Review的階段，這樣以防止代碼在仍有很大 問題的情況下進行Review而導致Review的整體效率太低。還有對整個Review過程所以經歷的時間段有一個大體的劃分。在這一階段首先由Author確定誰來當本次Review的moderator（一般moderator只能從團隊中有限的幾個人內挑選，並不是每個人都可以充當這個角色的。）然後再邀請別人充當本次Review的Recoder，Other reviewers；
這個階段各個角色的主要任務是：
Author：對整個Review過程制定計劃，確定參加這次Rewview人員，爲這些成員分發要Review的材料。
moderator：對整個要Review的對象進行分析查看是否達到能夠開始Code Review的要求。
2.Overview:
對於大量的東西要Review的項目，或者大部分參與Review的人對要Review的東西都不是很熟悉的情況下。由Author開招開一個簡短的站會整體解決一下所要Review的東西。
3.Preparation:
在這個階段，所有參與的reviewers對所以review的東西各自進行走讀，然後記錄並提交發現的問題，然後由Author和moderator共同對reviewers所發現的問題進行彙總，分類，甄別。之後根據彙總上來的問題來進一步判斷是否適合招開Review會議。如果彙總上來的問題比較多，比較嚴重則說明所要Reivew的文件尚未真正達到要求，則取消本次活動。由Author重新開發。如果發現的問題不是很多，則按時招開Review Meeting.
這個階段各個角色的主要任務是：
reviewers:對所要Review的對象各自先進行走讀，然後提交各自發現的問題。
moderator和Author：對reviewers提交上來的問題進行彙總總結查看是否符合Review的條件。
4.meeting:
meeting做爲整個review的核心和關鍵環節其主要任務是首先由Author主持對彙總上來的問題，逐個的分析然後給出自己的判斷，是接受reviewers還是不接受reviewers提出的問題。對於有分歧的問題進行討論，如果還有分歧則由moderator決定這個問題是否要改怎麼改。在將所有彙總上來的問題分析完後，再由Author帶着所有reviewers對代碼進行走讀。然後進一步分析和討論代碼中的問題。
這個階段各個角色的主要任務是：
Author：逐個分析彙總上來的問題，並給出自己的分析。帶領所有reviewers對代碼進行走讀；
moderator：分析判斷Author對問題的分析判斷是否合理，在關鍵時刻給出分歧問題的處理意見；
reviewers：討論分析之前提出的問題，對代碼進行集體的重新走讀，以發現更多的問題；
Recorder：對整個Code Review進行記錄，包括髮現的問題以及問題的整改意見。
5.Rework&Verification:
這個階段主要是Author對整個Review過程提出的問題進行整改，然後提交由moderator對整個整改的情況進行評估。
總結：
通過對Code Review中的成員進行角色分工，從而賦予他們一定的職責，這樣就能很好的提高他們的責任感從而大大提高代碼走查的效率。