【編者按】本文作者為 Hugo Giraudel沙咏，主要從各個(gè)角度論證了代碼審查的重要性以及實(shí)現(xiàn)方法污筷。文章系國內(nèi) ITOM 管理平臺 OneAPM 編譯呈現(xiàn)帘睦。以下為正文疾党。
最近档泽，筆者在Twitter上看到這樣一句話：
可悲的是俊戳，對于很多學(xué)生、自由職業(yè)者以及機(jī)構(gòu)來說馆匿，代碼審查似乎相當(dāng)陌生抑胎。
很明顯，代碼審查的重要性并不為每個(gè)人所熟知渐北。你可以說我很天真阿逃，但是筆者確實(shí)認(rèn)為所有的IT公司都離不開該過程。顯然實(shí)際并非如此赃蛛，真是讓我大吃一驚恃锉。
在本文中，筆者想給出關(guān)于代碼審查的想法呕臂，以及為什么我認(rèn)為這是代碼遷移過程中非常重要的組成部分破托，怎樣進(jìn)行審查等。如果你目前不進(jìn)行代碼審查歧蒋，或者想要做得更好炼团，希望本文能有助于你！
什么是代碼審查疏尿？
我們生活在維基百科的時(shí)代瘟芝，所以開始之前，先引用一下其中關(guān)于代碼審查的定義：
代碼審查是計(jì)算機(jī)源代碼的系統(tǒng)性檢驗(yàn)（有時(shí)被稱為同行評審）褥琐。其目的在于找到開發(fā)初期所忽略的錯(cuò)誤锌俱，從而提高軟件的整體質(zhì)量。審查的形式多種多樣敌呈，如結(jié)對編程贸宏，非正式走查，正式檢查等磕洪。
顧名思義吭练，代碼審查就是審查一些代碼，以確保其能夠正常工作析显，并盡可能改善其性能鲫咽。
代碼審查的方法
正如維基百科中的定義，代碼審查有多種方法。然而分尸，目前太多的代碼都存在于GitHub上锦聊，代碼審查也就經(jīng)常伴隨著所謂的“pull request”出現(xiàn)。
Pull request是一個(gè)請求箩绍，使用分布式版本控制系統(tǒng)（Git孔庭、SVN、Mercurial等）對代碼庫作出修改材蛛。它通過“牽引”原代碼圆到、寫入更改，然后提交請求以便將更改合并卑吭。
得益于GitHub友好的用戶界面芽淡，這個(gè)過程變得非常簡單高效，GitHub也概括了大部分Git知識需求陨簇。
為什么代碼審查非常重要
那么，既然我們可以不經(jīng)過任何審查與監(jiān)督迹淌，直接進(jìn)行代碼遷移河绽，為什么代碼審查還這么重要呢？畢竟唉窃，我們都能勝任該工作耙饰。
從理論上說是這樣。但在實(shí)踐中纹份，有很多原因可以表明代碼審查的重要性苟跪。讓我們來看看其中的幾個(gè)。
降低風(fēng)險(xiǎn)
這可能是最重要的原因蔓涧。有專人復(fù)核我們的工作并不是無關(guān)痛癢的件已，這能降低被忽視的錯(cuò)誤所帶來的風(fēng)險(xiǎn)。畢竟即使再好的開發(fā)人員也有可能一時(shí)失察元暴。
并且篷扩，確保沒有忘記任何事情總是有必要的。舉例來說茉盏，前端開發(fā)中經(jīng)常會(huì)忽略適當(dāng)?shù)逆I盤導(dǎo)航鉴未，屏幕閱讀器的可用性，適應(yīng)國際化的靈活性鸠姨，以及友好的非JavaScript行為等問題铜秆，在這里僅列出這四項(xiàng)。
顯著提高代碼質(zhì)量
清楚點(diǎn)說讶迁，這不是單純的代碼標(biāo)準(zhǔn)和代碼檢查（至少不全是）连茧，而是使代碼更高效。
在一個(gè)團(tuán)隊(duì)里，每個(gè)人都有自己的背景和特長梅屉，而團(tuán)隊(duì)始終需要進(jìn)步值纱。因此總有人可能提出更聰明的解決方案，更合適的設(shè)計(jì)模式坯汤，或者能降低復(fù)雜性或提高性能的方法虐唠。
使每個(gè)人都得到提高
通過合作，每個(gè)人都可以相互學(xué)習(xí)并取得進(jìn)步惰聂。提交代碼者很有可能從該工作中得到反饋疆偿，并意識到可能存在的問題和需要改進(jìn)的部分；而審查者也可以通過閱讀他人代碼學(xué)到新的東西搓幌，并找出適用于他們自己的工作方案杆故。
有助于熟悉項(xiàng)目
當(dāng)一個(gè)團(tuán)隊(duì)在做一個(gè)項(xiàng)目時(shí)，想要每個(gè)開發(fā)人員致力于應(yīng)用的每個(gè)部分溉愁，這是極不可能的处铛。有時(shí)候，會(huì)出現(xiàn)這種情況：在某一段時(shí)間拐揭，一個(gè)開發(fā)人員正為項(xiàng)目的大部分模塊辛苦地工作撤蟆，而另一個(gè)人則完全在做別的東西。
因此堂污，代碼審查有助于人們了解其他人所寫家肯，但以后可能會(huì)需要自己來維護(hù)的那部分代碼。它促進(jìn)了代碼庫知識在團(tuán)隊(duì)中的傳播盟猖，也有可能加快未來的發(fā)展讨衣。
怎樣適當(dāng)?shù)剡M(jìn)行代碼審查
再次強(qiáng)調(diào)，有固定的代碼審查過程非常有用式镐，非常重要反镇。不管用什么方法，每個(gè)團(tuán)隊(duì)創(chuàng)造的代碼都應(yīng)該進(jìn)行代碼審查娘汞。
話雖這么說愿险，但進(jìn)行有意義的代碼審查并不像看上去那么簡單明了。不過价说，別擔(dān)心辆亏，即使做得不好也不會(huì)有什么壞處，就是浪費(fèi)點(diǎn)時(shí)間鳖目。
最近扮叨，我的團(tuán)隊(duì)回顧了之前進(jìn)行的代碼審查。當(dāng)我們意識到12個(gè)開發(fā)人員中领迈，只有3個(gè)在做代碼審查時(shí)彻磁，我們就明白有些地方出了問題碍沐。
為了改變這種狀況，我們的一位 Scrum 專家組織了一次回顧分析衷蜓，以確定還可能改進(jìn)的空間累提，以及我們將怎樣改變。
提前規(guī)劃
代碼審查做得不夠磁浇，為了自圓其說斋陪，最常用的借口就是，它需要時(shí)間——其他人不能或不愿意在這上面花費(fèi)時(shí)間置吓。
我必須說无虚，筆者并不太理解這種說法，因?yàn)槲业挠^點(diǎn)是：如果一個(gè)同事直接來找我衍锚，讓我?guī)退拿τ烟猓揖筒粫?huì)說“我沒有時(shí)間，也不感興趣”戴质。反而度宦，我會(huì)抽空來幫忙，可能不是現(xiàn)在告匠，是一個(gè)小時(shí)之后——但是顯然戈抄，我會(huì)花時(shí)間幫助他們。為什么呢凫海？ 因?yàn)椋?/p>
這就是團(tuán)隊(duì)的意義呛凶；
他們詢問我男娄，這是因?yàn)樗麄兛粗匚业囊庖娦刑埃@就值得我去幫助他們。
“為什么你不做代碼審查呢模闲？”
“我沒有時(shí)間建瘫。”
對筆者而言尸折，“pull request”和同事向我尋求幫助沒什么不同啰脚。有時(shí)候說你沒時(shí)間是可以接受的，但系統(tǒng)性地拒絕幫助別人实夹，就表明你正在積極地讓自己脫離團(tuán)隊(duì)橄浓。這種行為不友好，也不積極亮航。所以要肯花時(shí)間提供幫助荸实。
為了讓開發(fā)人員抽出時(shí)間，我們就開始考慮讓每個(gè)程序員每天花一點(diǎn)時(shí)間（也許30分鐘）審查代碼缴淋。我們完成每天半小時(shí)的代碼審查時(shí)也不會(huì)發(fā)現(xiàn)什么意外驚喜：這只是一天中的一部分准给。
我們以前還試著大幅度降低 “pull request”包含的代碼量泄朴。因?yàn)樵?jīng)的“pull request”非常多——幾十個(gè)文件中有數(shù)以千計(jì)的改動(dòng)。
我們現(xiàn)在盡量不那么做了露氮。通過創(chuàng)建較小的“pull request”祖灰，審查代碼變得更加容易，反饋也更加中肯畔规，開發(fā)人員也更愿意參與這個(gè)過程局扶。“代碼遷移量更小也更頻繁”油讯。
結(jié)合語境
我們發(fā)現(xiàn)的第二大問題是详民，我們通常缺乏對代碼背景的理解，如果你想要提供有用的反饋陌兑，這就很有必要沈跨。離開了代碼背景，我們通常也只能進(jìn)行語法檢查——這雖然在一定程度上也有用兔综，但遠(yuǎn)遠(yuǎn)不夠饿凛。這時(shí)候你就變成了我們所說的“人工審查器”。
幸好软驰，這個(gè)問題比較好解決：給pull request添加一個(gè)描述以解釋你的目的涧窒，如何達(dá)到目的。這不需要一大段文字锭亏，通常短短幾行足矣纠吴。將鏈接添加到and/or也會(huì)起作用。Liv Madsen是我們的一位開發(fā)者慧瘤，她甚至增加了截屏——或者相關(guān)的截屏視頻——來解釋她做的東西戴已，這令人稱奇。
實(shí)際詢問
第三個(gè)問題就是我們有時(shí)干脆沒有意識到需要審查什么锅减。的確糖儡，我們每天都充斥著無數(shù)的電子郵件和通知 ——郵件太多了，因此很難保存怔匣。畢竟我們只是普通的人握联。
同樣，解決辦法很簡單：直接向別人詢問需要審查的代碼每瞒。這有很多方法金闽，比如在辦公室問一聲，或者直接在Slack上給你團(tuán)隊(duì)的同事發(fā)消息剿骨。
我們基于自己的活動(dòng)在GitHub上創(chuàng)建了群組代芜，當(dāng)提交pull request時(shí)，總是ping一個(gè)群組懦砂。群組的成員都會(huì)收到通知蜒犯，并且只要有時(shí)間就可以自由地選擇如何解決组橄。有時(shí)候，當(dāng)請求特別針對某一個(gè)（或幾個(gè)）人的工作時(shí)罚随，我們就直接ping相應(yīng)的開發(fā)人員玉工。
然后，收到ping消息的人就可以審查代碼并發(fā)表評論淘菩。即使沒有什么具體的事需要報(bào)告遵班，我們也會(huì)留言——表明代碼可以合并了。
因?yàn)槲覀兛赡軙?huì)不考慮已有的評論潮改，盲目合并一些pull request狭郑，所以就建立了嚴(yán)格的“回復(fù)或解決”制度。當(dāng)收到反饋時(shí)汇在，要么你把問題解決翰萨，要么在回復(fù)中解釋為什么不能解決。無論如何都不能留下懸而未決的評論糕殉，也當(dāng)然不能將其與pull request合并亩鬼。
總結(jié)
進(jìn)行定期和高效的代碼審查對于保持高質(zhì)量的代碼標(biāo)準(zhǔn)來說必不可少，還有利于開發(fā)者之間的知識共享阿蝶，以及團(tuán)隊(duì)的發(fā)展雳锋。
要求代碼審查并不意味著能力弱，請求他人的幫助也并不值得尷尬羡洁，代碼審查當(dāng)然也沒什么好羞愧的玷过。另一方面，接受你獲得的反饋筑煮，并給提交pull request的人提供建設(shè)性的（理想情況下辛蚊，積極的）的評論。
找到適合你的工作咆瘟。審查代碼應(yīng)該在代碼遷移過程中占很大比重嚼隘，所以你應(yīng)該在團(tuán)隊(duì)中適時(shí)調(diào)整诽里，以保證對每個(gè)人都有益袒餐。
最后祝各位能夠愉快地審查代碼！
本文系 OneAPM 工程師整理呈現(xiàn)谤狡。OneAPM 能為您提供端到端的應(yīng)用性能解決方案灸眼，我們支持所有常見的框架及應(yīng)用服務(wù)器，助您快速發(fā)現(xiàn)系統(tǒng)瓶頸墓懂，定位異常根本原因焰宣。分鐘級部署，即刻體驗(yàn)捕仔，性能監(jiān)控從來沒有如此簡單匕积。想閱讀更多技術(shù)文章盈罐，請?jiān)L問 OneAPM 官方技術(shù)博客。
本文轉(zhuǎn)自 OneAPM 官方博客
原文鏈接：https://www.sitepoint.com/the-importance-of-code-reviews/
