大家是怎么做Code Review的？

feiyang10086

轉(zhuǎn)：菜阿彬

　　先說說我們公司現(xiàn)在的做法，一個團隊被人為地分為兩個陣營：Senior Developers和Junior Developers，比例差不多是1:1，Senior Developers就擔(dān)負著對Junior Developers的代碼進行Review的職責(zé)，每天Review一次，對有問題的代碼寫上comments，然后也check in到代碼庫中。這種comments有特殊格式（比如//\\CodeReview:blah blah），要求Junior Developers每天下班前一小時去代碼庫中找這種格式的comments，然后修復(fù)自己的有問題的代碼，修復(fù)時刪除Reviewer留下的Comments。把Review的Comments也check in到代碼庫，本意是說讓任何東西都有記錄。

　　我對Code Review的理解是，最好的形式是“結(jié)對編程”，特地查了下Wiki對Code Review的定義，明確講了“Pair Programming”是Code Review的一種形式。我個人非常喜歡pair，甚至到了在寫一些重要代碼時，沒人跟我pair我都不想寫代碼的程度。然而現(xiàn)實中，大部分人對pair是排斥的，尤其是那些對軟件開發(fā)似懂非懂的項目經(jīng)理們——他們直覺上認為那會讓生產(chǎn)力減半。

　　那就回到現(xiàn)實，在一個不允許進行“結(jié)對編程”的團隊里，怎么做Code Review 比較好呢？說說我的想法：

　　1，Code Review在某種意義上是一種“反饋系統(tǒng)”。軟件開發(fā)中存在太多的“反饋系統(tǒng)”。尤其是在“敏捷”中，追求更多的“反饋”，也追求更快的“反饋”，比如Iteration，Daily meeting，TDD，face-to-face communication……不一而足�！胺答佒芷凇笨偸窃蕉淘胶�，“結(jié)對編程”的反饋周期為0，它是“即時”的反饋系統(tǒng)，這也是我認為它是最好的Code Review的原因之一。那么除開“結(jié)對編程”，怎么讓Code Review的“反饋周期”變短呢？像我們公司一天一次Review的做法，也許已經(jīng)很短了，但顯然還有更快的，比如每次Check in時Review。

　　2，check in前review本身也不一定就更快，如果有人2天才check in一次代碼，那還不如daily的review呢。所以就需要結(jié)合另外一個理念：check in as often as possible。以我自己的經(jīng)驗，在有活干的時候，check in頻率在30分鐘到2小時是正常的。有時會超過2小時，但那要么是有特殊原因，要么我就感覺自己寫代碼的方式出了問題。

　　3，順便說句題外話：看到不少程序員的一個“通病”是，完全沒法在短時間內(nèi)check in，他們一旦開工（尤其是做一個比較大的模塊時），一發(fā)不可收拾，這邊寫一個類，還沒寫完，突然又想到要寫另一個類，這樣寫了很多代碼，你過去讓他check in，他會告訴你再等等，因為他的代碼現(xiàn)在還沒法通過編譯（這跟把沒通過編譯的代碼check in的人比，還是很有人性的）。事實上，一個高手的必備技能之一就是讓自己的代碼處于不安全狀態(tài)的時間越短越好。這種不安全包括不能通過編譯，不能通過現(xiàn)有的單元測試，不能通過整個應(yīng)用程序的smoke test……。對有這種“通病”的程序員來說，TDD是劑良藥，我個人也認為他是一個分水嶺：這世界上有兩種程序員，一種會TDD，另一種不會TDD。個人意見，就不展開敘述了。

　　4，我們公司的做法還有哪些問題？作為Reviewer，我要去找哪些代碼在今天被修改過，這很費時間，如果有個工具幫忙會好點，比如有些系統(tǒng)可以把每次check in產(chǎn)生的diff發(fā)送mail給reviewer。但是，很多時候，事情的本質(zhì)不會通過一個工具得到改變。本質(zhì)是什么？是這種Code Review的做法是基于“push”的一個做法——Reviewer被push去review代碼，然后把Review的Comments提交到代碼庫，Junior Devs被push每天去搜索那些comments，然后修復(fù)它們。

　　5，有沒有一種基于“pull”的做法？我以前一家公司，有設(shè)置一個簡單的check in policy：每次check in時，必須在note里填上reviewer的名字。這樣，每個人check in前就會主動找人給他Review，我感覺這有點“pull”的意思。

　　6，另外一個問題是：比如某人寫了一天的代碼，Reviewer在第二天Review后發(fā)現(xiàn)他的代碼設(shè)計有比較大的問題（但是能work），那么在第三天，這個人會去重構(gòu)他的代碼以達到更好的設(shè)計嗎？基本上是不會的。那這樣的review有何意義呢？

　　7，這里牽涉到Code Review到底要Review什么的問題，我覺得至少可以分三種：一是小的issue（比如命名規(guī)范，代碼標準）；二是大的issue（比如內(nèi)存泄露）；最后是那種非“issue”，而是設(shè)計是否優(yōu)雅簡單，代碼是否干凈可讀的問題，這種問題不會導(dǎo)致程序出錯，在短期內(nèi)甚至沒有任何問題，只會在一段時間之后引起維護成本，可擴展性之類的問題。我覺得越是一個成熟的團隊，Review時花在最后一種情況的時間會越多�？墒沁@種東西，有時沒有一個標準，更多的是一種程序員之間的交流和互相學(xué)習(xí)。而把Reviewer的comments冷冰冰地記錄在“不良代碼”的上方，然后被Review的人每天默默地修復(fù)那些“不良代碼”的行為，是不是完全忽視了這一點呢？

　　8，總之，code review要注意達到一些目標：快速反饋，簡單有效，知識傳播……

　　一些零散想法，不成體系。不知道大家在公司有沒有做Code Review？是怎么做的呢？