先說說我們公司現在的做法，一個團隊被人為地分為兩個陣營：Senior Developers和Junior Developers，比例差不多是1:1，Senior Developers就擔負着對Junior Developers的代碼進行Review的職責，每天Review一次，對有問題的代碼寫上comments，然后也check in到代碼庫中。這種comments有特殊格式（比如//\\CodeReview:blah blah），要求Junior Developers每天下班前一小時去代碼庫中找這種格式的comments，然后修復自己的有問題的代碼，修復時刪除Reviewer留下的Comments。把Review的Comments也check in到代碼庫，本意是說讓任何東西都有記錄。
我對Code Review的理解是，最好的形式是“結對編程”，特地查了下Wiki對Code Review的定義，明確講了“Pair Programming”是Code Review的一種形式。我個人非常喜歡pair，甚至到了在寫一些重要代碼時，沒人跟我pair我都不想寫代碼的程度。然而現實中，大部分人對pair是排斥的，尤其是那些對軟件開發似懂非懂的項目經理們——他們直覺上認為那會讓生產力減半。
那就回到現實，在一個不允許進行“結對編程”的團隊里，怎么做Code Review 比較好呢？說說我的想法：
1，Code Review在某種意義上是一種“反饋系統”。軟件開發中存在太多的“反饋系統”。尤其是在“敏捷”中，追求更多的“反饋”，也追求更快的“反饋”，比如Iteration，Daily meeting，TDD，face-to-face communication……不一而足。“反饋周期”總是越短越好，“結對編程”的反饋周期為0，它是“即時”的反饋系統，這也是我認為它是最好的Code Review的原因之一。那么除開“結對編程”，怎么讓Code Review的“反饋周期”變短呢？像我們公司一天一次Review的做法，也許已經很短了，但顯然還有更快的，比如每次Check in時Review。
2，check in前review本身也不一定就更快，如果有人2天才check in一次代碼，那還不如daily的review呢。所以就需要結合另外一個理念：check in as often as possible。以我自己的經驗，在有活干的時候，check in頻率在30分鍾到2小時是正常的。有時會超過2小時，但那要么是有特殊原因，要么我就感覺自己寫代碼的方式出了問題。
3，順便說句題外話：看到不少程序員的一個“通病”是，完全沒法在短時間內check in，他們一旦開工（尤其是做一個比較大的模塊時），一發不可收拾，這邊寫一個類，還沒寫完，突然又想到要寫另一個類，這樣寫了很多代碼，你過去讓他check in，他會告訴你再等等，因為他的代碼現在還沒法通過編譯（這跟把沒通過編譯的代碼check in的人比，還是很有人性的）。事實上，一個高手的必備技能之一就是讓自己的代碼處於不安全狀態的時間越短越好。這種不安全包括不能通過編譯，不能通過現有的單元測試，不能通過整個應用程序的smoke test……。對有這種“通病”的程序員來說，TDD是劑良葯，我個人也認為他是一個分水嶺：這世界上有兩種程序員，一種會TDD，另一種不會TDD。個人意見，就不展開敘述了。
4，我們公司的做法還有哪些問題？作為Reviewer，我要去找哪些代碼在今天被修改過，這很費時間，如果有個工具幫忙會好點，比如有些系統可以把每次check in產生的diff發送mail給reviewer。但是，很多時候，事情的本質不會通過一個工具得到改變。本質是什么？是這種Code Review的做法是基於“push”的一個做法——Reviewer被push去review代碼，然后把Review的Comments提交到代碼庫，Junior Devs被push每天去搜索那些comments，然后修復它們。
5，有沒有一種基於“pull”的做法？我以前一家公司，有設置一個簡單的check in policy：每次check in時，必須在note里填上reviewer的名字。這樣，每個人check in前就會主動找人給他Review，我感覺這有點“pull”的意思。
6，另外一個問題是：比如某人寫了一天的代碼，Reviewer在第二天Review后發現他的代碼設計有比較大的問題（但是能work），那么在第三天，這個人會去重構他的代碼以達到更好的設計嗎？基本上是不會的。那這樣的review有何意義呢？
7，這里牽涉到Code Review到底要Review什么的問題，我覺得至少可以分三種：一是小的issue（比如命名規范，代碼標准）；二是大的issue（比如內存泄露）；最后是那種非“issue”，而是設計是否優雅簡單，代碼是否干凈可讀的問題，這種問題不會導致程序出錯，在短期內甚至沒有任何問題，只會在一段時間之后引起維護成本，可擴展性之類的問題。我覺得越是一個成熟的團隊，Review時花在最后一種情況的時間會越多。可是這種東西，有時沒有一個標准，更多的是一種程序員之間的交流和互相學習。而把Reviewer的comments冷冰冰地記錄在“不良代碼”的上方，然后被Review的人每天默默地修復那些“不良代碼”的行為，是不是完全忽視了這一點呢？
8，總之，code review要注意達到一些目標：快速反饋，簡單有效，知識傳播……
一些零散想法，不成體系。不知道大家在公司有沒有做Code Review？是怎么做的呢？
原文http://www.cnblogs.com/CaiAbin/archive/2011/04/09/2010706.html