談一下我們是如何開展code review的

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

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

代碼審查的阻力

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

• 國内的整體環境，國内的公司，尤其是網際網路公司，講究速度緻上，軟體開發的疊代周期周期短，速度快，因為競争太大，開發的産品要求快速上線，對代碼審查不是很重視，先上線，出了問題再解決。
• 公司的規模，大公司重視流程，把代碼審查作為軟體開發中的重要一環，甚至計入考核，不管什麼一旦成為制度，開展起來就相對容易了。小公司則不然，尤其是剛起步的，可能覺的代碼審查沒有必要。
• 和你的上司有關系，就和上面說的，代碼審查如果沒有形成制度，如果你的上司是技術出身，明白代碼審查的重要性，那麼會要求你去做。如果是來自别的領域，可能認識不到它的重要性，覺的代碼審查是浪費時間（就和代碼重構一個道理）。
• 個人原因，尤其是剛剛進入公司的員工，大學的軟體工程課裡面好像是沒有介紹代碼審查的，就是有，沒有實際經驗，也體會不到它的重要性，筆者剛入職時就是這麼認為的。

代碼審查的重要性

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

• 代碼審查是保證代碼品質的重要手段。軟體缺陷可能隐藏在各個地方，測試是發現缺陷的重要方法，但專業的測試人員更多的可能是黑盒測試，他們不去關注代碼内部的邏輯，隻去關注代碼實作的功能，有人說測試代碼中的邏輯需要開發人員進行單元測試，一方面，單元測試覆寫率基本上不可能達到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會議也是照常進行的。 

作者：

HarlanC

部落格位址：

http://www.cnblogs.com/harlanc/

個人部落格：

http://www.harlancn.me/

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出,

原文連結

如果覺的部落客寫的可以，收到您的贊會是很大的動力，如果您覺的不好，您可以投反對票，但麻煩您留言寫下問題在哪裡，這樣才能共同進步。謝謝！