眾所周知，代碼審查是軟件開發過程中十分重要的環節，樓主結合自己的實際工作經驗，和大家分享一下在實際工作中代碼審查是如何開展的，

筆者水平有限，若有錯誤和紕漏，還請大家指正。

代碼審查的阻力

我想不通公司不同部門對代碼審查這項工作的重視程度還是不一樣的，對于代碼審查的阻力總結了以下幾點：

國內的整體環境，國內的公司，尤其是互聯網公司，講究速度致上，軟件開發的迭代周期周期短，速度快，因為競爭太大，開發的產品要求快速上線，對代碼審查不是很重視，先上線，出了問題再解決。

公司的規模，大公司重視流程，把代碼審查作為軟件開發中的重要一環，甚至計入考核，不管什么一旦成為制度，開展起來就相對容易了。小公司則不然，尤其是剛起步的，可能覺的代碼審查沒有必要。

和你的領導有關系，就和上面說的，代碼審查如果沒有形成制度，如果你的領導是技術出身，明白代碼審查的重要性，那么會要求你去做。如果是來自別的領域，可能認識不到它的重要性，覺的代碼審查是浪費時間（就和代碼重構一個道理）。

個人原因，尤其是剛剛進入公司的員工，大學的軟件工程課里面好像是沒有介紹代碼審查的，就是有，沒有實際經驗，也體會不到它的重要性，筆者剛入職時就是這么認為的。

代碼審查的重要性

說了代碼審查工作的開展遇到的阻力，下面說一下為什么代碼審查是重要的。

代碼審查是保證代碼質量的重要手段。軟件缺陷可能隱藏在各個地方，測試是發現缺陷的重要方法，但專業的測試人員更多的可能是黑盒測試，他們不去關注代碼內部的邏輯，只去關注代碼實現的功能，有人說測試代碼中的邏輯需要開發人員進行單元測試，一方面，單元測試覆蓋率基本上不可能達到100%，另一方面，畢竟是單元測試，測試場景簡單，有些復雜的場景有可能會測不到。各種測試完成后，如果還有缺陷，那只能讓客戶充當我們的“終極測試”了。抱怨會接踵而來，客戶滿意度會越來越低。所以，我們要想出一切可以使用的方法來進一步提高代碼質量的方法，還有代碼審查么，測試發現不了的問題，通過代碼審查也許你能夠發現。

代碼審查是熟悉軟件架構，了解軟件業務邏輯的好方法。學習代碼是需要切入點的，一個上百萬行代碼的系統，從哪里開始著手，只能一個模塊一個模塊，一個組件一個組件的來熟悉，掌握。實現一個比較大的功能，你應該不會是唯一的開發人員，從系統架構師輸出的系統設計，然后到各個團隊中技術Lead輸出的component級別的設計，到開始實現時，應該會把功能分為不同的模塊有不同的開發人員協同實現。這是個學習的機會，不要只局限于自己這部分，為了了解這個大的功能，甚至和這個功能相關的其他已經實現的功能，你同樣需要關注其他人的工作。有目的的看代碼和漫無目的的瀏覽效果是不一樣的，你已經對新功能有所了解，審查代碼之前，你認為代碼會怎么寫，別人哪里和你想的不一樣，舊功能和新功能是如何相互影響的等等，心里懷著問題，你的學習速度會更快，記得更加深刻。

代碼審查是你提高自己的好方法。前提是team中有經驗豐富的開發人員的存在。也就是大牛，不要錯過讓他看你代碼的機會，不要害怕他會為你寫的代碼挑出一大堆問題，有人說你自己寫的代碼就像自己的孩子，見不得別人說半點不字，不要固執，要內心平靜的，客觀的去看待你所寫的代碼，發現并解決問題才能提高你自己。也不要錯過去review大牛代碼的機會，看看大牛寫出來的代碼是怎樣的，你可以取其精華。

代碼審查是需要功力的。網上有帖子說程序員的資深與否和工作年限沒有必然聯系，你是5年工作經驗還是一個經驗用了5年，這需要你去刻意練習，剛開始review代碼的時候你可能不習慣，也可能很痛苦，面對的一屏幕的代碼不知如何下眼。但有一句話，如果你覺的內心很舒服，你就是在原地踏步。覺的痛苦說明你是在爬坡，刻意的去聯系自己的大腦吧，今天你看一頁代碼可能用了一個小時，沒有發現問題，但是堅持一個月甚至三個月之后，你看一眼就能夠發現代碼中的缺陷，恭喜你，你的功力加深了。

我們是如何開展代碼審查的

好了。羅嗦了半天。下面開始說一下在樓主參與的項目中是如果開展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會議也是照常進行的。