大家是怎么做Code Review的？

feiyang10086

轉(zhuǎn)：菜阿彬

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

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

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

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

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

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

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

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

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

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

　　8，總之，code review要注意達(dá)到一些目標(biāo)：快速反饋，簡(jiǎn)單有效，知識(shí)傳播……

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