眾所周知鸥跟，代碼審查是軟件開發(fā)過程中十分重要的環(huán)節(jié)搪锣，樓主結(jié)合自己的實際工作經(jīng)驗秋忙，和大家分享一下在實際工作中代碼審查是如何開展的，

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

代碼審查的阻力

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

國內(nèi)的整體環(huán)境弹澎，國內(nèi)的公司，尤其是互聯(lián)網(wǎng)公司努咐，講究速度致上裁奇，軟件開發(fā)的迭代周期周期短，速度快麦撵，因為競爭太大刽肠，開發(fā)的產(chǎn)品要求快速上線，對代碼審查不是很重視免胃，先上線音五，出了問題再解決。

公司的規(guī)模羔沙，大公司重視流程躺涝，把代碼審查作為軟件開發(fā)中的重要一環(huán)，甚至計入考核扼雏，不管什么一旦成為制度坚嗜，開展起來就相對容易了。小公司則不然诗充，尤其是剛起步的苍蔬，可能覺的代碼審查沒有必要。

和你的領(lǐng)導有關(guān)系蝴蜓，就和上面說的碟绑，代碼審查如果沒有形成制度俺猿，如果你的領(lǐng)導是技術(shù)出身，明白代碼審查的重要性格仲，那么會要求你去做押袍。如果是來自別的領(lǐng)域，可能認識不到它的重要性凯肋，覺的代碼審查是浪費時間（就和代碼重構(gòu)一個道理）谊惭。

個人原因，尤其是剛剛進入公司的員工侮东，大學的軟件工程課里面好像是沒有介紹代碼審查的圈盔，就是有，沒有實際經(jīng)驗苗桂，也體會不到它的重要性药磺，筆者剛?cè)肼殨r就是這么認為的告组。

代碼審查的重要性

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

代碼審查是保證代碼質(zhì)量的重要手段木缝。軟件缺陷可能隱藏在各個地方便锨，測試是發(fā)現(xiàn)缺陷的重要方法，但專業(yè)的測試人員更多的可能是黑盒測試我碟，他們不去關(guān)注代碼內(nèi)部的邏輯放案，只去關(guān)注代碼實現(xiàn)的功能，有人說測試代碼中的邏輯需要開發(fā)人員進行單元測試，一方面，單元測試覆蓋率基本上不可能達到100%崇裁，另一方面灌诅，畢竟是單元測試，測試場景簡單脊髓，有些復雜的場景有可能會測不到。各種測試完成后，如果還有缺陷押赊，那只能讓客戶充當我們的“終極測試”了。抱怨會接踵而來包斑，客戶滿意度會越來越低流礁。所以，我們要想出一切可以使用的方法來進一步提高代碼質(zhì)量的方法罗丰，還有代碼審查么神帅，測試發(fā)現(xiàn)不了的問題，通過代碼審查也許你能夠發(fā)現(xiàn)萌抵。

代碼審查是熟悉軟件架構(gòu)枕稀，了解軟件業(yè)務邏輯的好方法。學習代碼是需要切入點的，一個上百萬行代碼的系統(tǒng)萎坷，從哪里開始著手凹联，只能一個模塊一個模塊，一個組件一個組件的來熟悉哆档，掌握蔽挠。實現(xiàn)一個比較大的功能，你應該不會是唯一的開發(fā)人員瓜浸，從系統(tǒng)架構(gòu)師輸出的系統(tǒng)設計澳淑，然后到各個團隊中技術(shù)Lead輸出的component級別的設計，到開始實現(xiàn)時插佛，應該會把功能分為不同的模塊有不同的開發(fā)人員協(xié)同實現(xiàn)杠巡。這是個學習的機會，不要只局限于自己這部分雇寇，為了了解這個大的功能氢拥，甚至和這個功能相關(guān)的其他已經(jīng)實現(xiàn)的功能，你同樣需要關(guān)注其他人的工作锨侯。有目的的看代碼和漫無目的的瀏覽效果是不一樣的嫩海，你已經(jīng)對新功能有所了解，審查代碼之前囚痴，你認為代碼會怎么寫叁怪，別人哪里和你想的不一樣，舊功能和新功能是如何相互影響的等等深滚，心里懷著問題奕谭，你的學習速度會更快，記得更加深刻痴荐。

代碼審查是你提高自己的好方法血柳。前提是team中有經(jīng)驗豐富的開發(fā)人員的存在。也就是大牛蹬昌，不要錯過讓他看你代碼的機會混驰，不要害怕他會為你寫的代碼挑出一大堆問題，有人說你自己寫的代碼就像自己的孩子皂贩，見不得別人說半點不字栖榨，不要固執(zhí)，要內(nèi)心平靜的明刷，客觀的去看待你所寫的代碼婴栽，發(fā)現(xiàn)并解決問題才能提高你自己。也不要錯過去review大牛代碼的機會辈末，看看大牛寫出來的代碼是怎樣的愚争，你可以取其精華映皆。

代碼審查是需要功力的。網(wǎng)上有帖子說程序員的資深與否和工作年限沒有必然聯(lián)系轰枝，你是5年工作經(jīng)驗還是一個經(jīng)驗用了5年捅彻，這需要你去刻意練習，剛開始review代碼的時候你可能不習慣鞍陨，也可能很痛苦步淹，面對的一屏幕的代碼不知如何下眼。但有一句話诚撵，如果你覺的內(nèi)心很舒服缭裆，你就是在原地踏步。覺的痛苦說明你是在爬坡寿烟，刻意的去聯(lián)系自己的大腦吧澈驼，今天你看一頁代碼可能用了一個小時，沒有發(fā)現(xiàn)問題筛武，但是堅持一個月甚至三個月之后缝其，你看一眼就能夠發(fā)現(xiàn)代碼中的缺陷，恭喜你畅铭，你的功力加深了氏淑。

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

好了勃蜘。羅嗦了半天硕噩。下面開始說一下在樓主參與的項目中是如果開展code review的。

第一家公司缭贡，是一家國內(nèi)的大公司炉擅，就不說名字了，我所在的部門開發(fā)的產(chǎn)品眾多阳惹，換項目很頻繁谍失，我參與的有3,4個吧，開發(fā)流程不規(guī)范莹汤，部門老大沒有對代碼審查有硬性要求快鱼。但帶我的老師，也是項目經(jīng)理（但是主要做技術(shù)纲岭，所以也可以說是技術(shù)經(jīng)理）是一個非常熱衷于技術(shù)的人抹竹，應該說明白代碼review的重要性，我們敏捷團隊有4個開發(fā)止潮，每次寫完代碼后窃判，都會進行team review。把代碼投到大屏幕上喇闸，然后老師帶我們?nèi)eview代碼袄琳。印象深刻的一次是一個同事著急回家過年询件，草草把代碼就提交走人了，被師傅挑出來很多問題唆樊。換了項目和項目經(jīng)理之后宛琅，代碼review就不了了之了。

第二家公司逗旁，是一個外企夯秃，有幾十年的歷史了，開發(fā)流程算是比較規(guī)范了痢艺，而且分工明確仓洼。在這家公司我們的大老板（也就是技術(shù)經(jīng)理的上司）對代碼review是有要求的，下面詳細說明我們的代碼審查是如何一步一步演進的堤舒。

第一階段?? team review + TFVC

先簡單介紹下我們的版本控制工具：微軟的TFVC色建，代碼的branch是按如下圖創(chuàng)建的，有一個main branch每個scrum team一個branch舌缤，出release之前把各個team的branch merge回main,最后出release branch箕戳，release branch上修復的bug也要最終回main。

開始的時候我們是沒有peer review的国撵，每兩周開一次team review陵吸。一個主持人，負責預定會議室介牙，操作visual studio查看最近兩周提交的changeset壮虫，一個記錄員，負責記錄發(fā)現(xiàn)的問題环础，相關(guān)功能的開發(fā)人員負責講解和解答疑問囚似。最后記錄員將review結(jié)果記錄到wiki中并發(fā)送到整個開發(fā)部門。

第二階段 自律TFVC + peer review + team review

記不太清是從哪個visual studio版本開始支持code review了线得，好像是VS2012饶唤。在提交之前每個開發(fā)人員需要將代碼提交給至少一個人進行review，然后生成一個code review的work item贯钩。你需要將這個work item鏈接到你的changeset中才能check in代碼募狂，不然我們公司自定義的policy會發(fā)出警告。這些警告是可以被忽略的角雷，然后也能強制提交祸穷。前面說過部分老大對code review是很重視的，如何才能檢查peer review的結(jié)果呢谓罗？對粱哼，將這些code review的work item數(shù)據(jù)進行查詢，將沒有鏈接work item的changeset過濾出來檩咱，然后將結(jié)果顯示揭措。技術(shù)經(jīng)理和老大一眼就能看到誰沒有遵守這個流程胯舷。盡管這么做了，開始執(zhí)行的時候還是有不少的人出現(xiàn)在查詢結(jié)果中绊含。

說一下自律的問題桑嘶，公司添加這個查詢review結(jié)果的措施是手段，只是在某種程度上保證了流程躬充，但目的是什么逃顶？目的是需要收到review請求的成員認認真真的review代碼，而不是隨便的走一下流程就OK充甚。如果你認識到review的重要性以政，你可能會用心一點吧。

我們的team review 會議依然在進行伴找，和peer review的區(qū)別就是peer review只給一個人或者少數(shù)的人進行review盈蛮，而team review 是在整個scrum team間進行。

第三階段 GIT + peer review + team review

我們的公司雖然歷史悠久技矮，但對一些流程的工具和技術(shù)還是極力推崇的抖誉。大家都知道GIT是非常流行的版本控制工具，visual studio 2012也開始支持GIT衰倦，我們也一步一步的 將source code移到了TFS-GIT中袒炉。

和TFVC相比，GIT的branch是非常輕量級的樊零，你可以很容易并且快速的創(chuàng)建一個branch我磁。所以我們現(xiàn)在可以將branch進行細分了。TFVC和GIT的代碼提交也不一樣淹接，TFVC是集中式的十性，最全的代碼放在server上叛溢，你需要一個branch的code時要將其check out到本地塑悼。每次提交都是把代碼從local一次性merge到server，如果出現(xiàn)conflicts,你需要在本地處理然后check in楷掉。GIT是分布式的厢蒜，每個人clone的時候都會把所有分支download到本地，代碼提交是通過pull request來進行的烹植，也就是通過branch之間的merge來進行斑鸦，這一點剛從TFVC轉(zhuǎn)到GIT的時候很難理解。這樣就得為每個人創(chuàng)建一個臨時branch草雕，注意這個branch在本地和server端同時存在巷屿，我們用這個branch開發(fā)自己的代碼并用這個branch進行merge code。這里的pull request就相當于TFVC中的code review墩虹，TFVC你還可以偷懶忽略code review的work item嘱巾，在這里就是強制性的了憨琳，沒有pull request，別人不會approve你的代碼旬昭，你根本就沒有方法將你的代碼merge到feature branch中篙螟。

還有team review會議也是照常進行的。