眾所周知，程式碼審查是軟體開發過程中十分重要的環節，樓主結合自己的實際工作經驗，和大家分享一下在實際工作中程式碼審查是如何開展的。
筆者水平有限，若有錯誤和紕漏，還請大家指正。
程式碼審查的阻力
我想不通公司不同部門對程式碼審查這項工作的重視程度還是不一樣的，對於程式碼審查的阻力總結了以下幾點：
- 國內的整體環境，國內的公司，尤其是網際網路公司，講究速度致上，軟體開發的迭代週期週期短，速度快，因為競爭太大，開發的產品要求快速上線，對程式碼審查不是很重視，先上線，出了問題再解決。
- 公司的規模，大公司重視流程，把程式碼審查作為軟體開發中的重要一環，甚至計入考核，不管什麼一旦成為制度，開展起來就相對容易了。小公司則不然，尤其是剛起步的，可能覺的程式碼審查沒有必要。
- 和你的領導有關係，就和上面說的，程式碼審查如果沒有形成制度，如果你的領導是技術出身，明白程式碼審查的重要性，那麼會要求你去做。如果是來自別的領域，可能認識不到它的重要性，覺的程式碼審查是浪費時間（就和程式碼重構一個道理）。
- 個人原因，尤其是剛剛進入公司的員工，大學的軟體工程課裡面好像是沒有介紹程式碼審查的，就是有，沒有實際經驗，也體會不到它的重要性，筆者剛入職時就是這麼認為的。
程式碼審查的重要性
說了程式碼審查工作的開展遇到的阻力，下面說一下為什麼程式碼審查是重要的。
- 程式碼審查是保證程式碼質量的重要手段。軟體缺陷可能隱藏在各個地方，測試是發現缺陷的重要方法，但專業的測試人員更多的可能是黑盒測試，他們不去關注程式碼內部的邏輯，只去關注程式碼實現的功能，有人說測試程式碼中的邏輯需要開發人員進行單元測試，一方面，單元測試覆蓋率基本上不可能達到100%，另一方面，畢竟是單元測試，測試場景簡單，有些複雜的場景有可能會測不到。各種測試完成後，如果還有缺陷，那隻能讓客戶充當我們的“終極測試”了。抱怨會接踵而來，客戶滿意度會越來越低。所以，我們要想出一切可以使用的方法來進一步提高程式碼質量的方法，還有程式碼審查麼，測試發現不了的問題，通過程式碼審查也許你能夠發現。
- 程式碼審查是熟悉軟體架構，瞭解軟體業務邏輯的好方法。學習程式碼是需要切入點的，一個上百萬行程式碼的系統，從哪裡開始著手，只能一個模組一個模組，一個元件一個元件的來熟悉，掌握。實現一個比較大的功能，你應該不會是唯一的開發人員，從系統架構師輸出的系統設計，然後到各個團隊中技術Lead輸出的component級別的設計，到開始實現時，應該會把功能分為不同的模組有不同的開發人員協同實現。這是個學習的機會，不要只侷限於自己這部分，為了瞭解這個大的功能，甚至和這個功能相關的其他已經實現的功能，你同樣需要關注其他人的工作。有目的的看程式碼和漫無目的的瀏覽效果是不一樣的，你已經對新功能有所瞭解，審查程式碼之前，你認為程式碼會怎麼寫，別人哪裡和你想的不一樣，舊功能和新功能是如何相互影響的等等，心裡懷著問題，你的學習速度會更快，記得更加深刻。
- 程式碼審查是你提高自己的好方法。前提是team中有經驗豐富的開發人員的存在。也就是大牛，不要錯過讓他看你程式碼的機會，不要害怕他會為你寫的程式碼挑出一大堆問題，有人說你自己寫的程式碼就像自己的孩子，見不得別人說半點不字，不要固執，要內心平靜的，客觀的去看待你所寫的程式碼，發現並解決問題才能提高你自己。也不要錯過去review大牛程式碼的機會，看看大牛寫出來的程式碼是怎樣的，你可以取其精華。
- 程式碼審查是需要功力的。網上有帖子說程式設計師的資深與否和工作年限沒有必然聯絡，你是5年工作經驗還是一個經驗用了5年，這需要你去刻意練習，剛開始reveiew程式碼的時候你可能不習慣，也可能很痛苦，面對的一螢幕的程式碼不知如何下眼。但有一句話，如果你覺的內心很舒服，你就是在原地踏步。覺的痛苦說明你是在爬坡，刻意的去聯絡自己的大腦吧，今天你看一頁程式碼可能用了一個小時，沒有發現問題，但是堅持一個月甚至三個月之後，你看一眼就能夠發現程式碼中的缺陷，恭喜你，你的功力加深了。
我們是如何開展程式碼審查的
好了。羅嗦了半天。下面開始說一下在樓主參與的專案中是如果開展code review的。
第一家公司，是一家國內的大公司，就不說名字了，我所在的部門開發的產品眾多，換專案很頻繁，我參與的有3,4個吧，開發流程不規範，部門老大沒有對程式碼審查有硬性要求。但帶我的老師，也是專案經理（但是主要做技術，所以也可以說是技術經理）是一個非常熱衷於技術的人，應該說明白程式碼review的重要性，我們敏捷團隊有4個開發，每次寫完程式碼後，都會進行team review。把程式碼投到大螢幕上，然後老師帶我們去review程式碼。印象深刻的一次是一個同事著急回家過年，草草把程式碼就提交走人了，被師傅挑出來很多問題。換了專案和專案經理之後，程式碼review就不了了之了。
第二家公司，是一個外企，有幾十年的歷史了，開發流程算是比較規範了，而且分工明確。在這家公司我們的大老闆（也就是技術經理的上司）對程式碼review是有要求的，下面詳細說明我們的程式碼審查是如何一步一步演進的。
- 第一階段 team review + TFVC
先簡單介紹下我們的版本控制工具：微軟的TFVC，程式碼的branch是按如下圖建立的，有一個main branch每個scrum team一個branch，出release之前把各個team的branch merge回main,最後出release branch，release branch上修復的bug也要最終回main。
開始的時候我們是沒有peer review的，每兩週開一次team review。一個主持人，負責預定會議室，操作visual studio檢視最近兩週提交的changeset，一個記錄員，負責記錄發現的問題，相關功能的開發人員負責講解和解答疑問。最後記錄員將review結果記錄到wiki中併傳送到整個開發部門。
- 第二階段 自律TFVC + peer review + team review
記不太清是從哪個visual studio版本開始支援code review了，好像是VS2012。在提交之前每個開發人員需要將程式碼提交給至少一個人進行review，然後生成一個code review的work item。你需要將這個work item連結到你的changeset中才能check in程式碼，不然我們公司自定義的policy會發出警告。這些警告是可以被忽略的，然後也能強制提交。前面說過部分老大對code review是很重視的，如何才能檢查peer review的結果呢？對，將這些code review的work item資料進行查詢，將沒有連結work item的changeset過濾出來，然後將結果顯示。技術經理和老大一眼就能看到誰沒有遵守這個流程。儘管這麼做了，開始執行的時候還是有不少的人出現在查詢結果中。
說一下自律的問題，公司新增這個查詢review結果的措施是手段，只是在某種程度上保證了流程，但目的是什麼？目的是需要收到review請求的成員認認真真的review程式碼，而不是隨便的走一下流程就OK。如果你認識到review的重要性，你可能會用心一點吧。
我們的team review 會議依然在進行，和peer review的區別就是peer review只給一個人或者少數的人進行review，而team review 是在整個scrum team間進行。
- 第三階段 GIT + peer review + team review
我們的公司雖然歷史悠久，但對一些流程的工具和技術還是極力推崇的。大家都知道GIT是非常流行的版本控制工具，visual studio 2012也開始支援GIT，我們也一步一步的 將source code移到了TFS-GIT中。
和TFVC相比，GIT的branch是非常輕量級的，你可以很容易並且快速的建立一個branch。所以我們現在可以將branch進行細分了。TFVC和GIT的程式碼提交也不一樣，TFVC是集中式的，最全的程式碼放在server上，你需要一個branch的code時要將其check out到本地。每次提交都是把程式碼從local一次性merge到server，如果出現conflicts,你需要在本地處理然後check in。GIT是分散式的，每個人clone的時候都會把所有分支download到本地，程式碼提交是通過pull request來進行的，也就是通過branch之間的merge來進行，這一點剛從TFVC轉到GIT的時候很難理解。這樣就得為每個人建立一個臨時branch，注意這個branch在本地和server端同時存在，我們用這個branch開發自己的程式碼並用這個branch進行merge code。這裡的pull request就相當於TFVC中的code review，TFVC你還可以偷懶忽略code review的work item，在這裡就是強制性的了，沒有pull request，別人不會approve你的程式碼，你根本就沒有方法將你的程式碼merge到feature branch中。
還有team review會議也是照常進行的。