【編者按】本文作者為 Hugo Giraudel，主要從各個(gè)角度論證了代碼審查的重要性以及實(shí)現(xiàn)方法。文章系國(guó)內(nèi) ITOM 管理平臺(tái) OneAPM 編譯呈現(xiàn)。以下為正文。
最近，筆者在Twitter上看到這樣一句話：
可悲的是，對(duì)于很多學(xué)生、自由職業(yè)者以及機(jī)構(gòu)來(lái)說(shuō)，代碼審查似乎相當(dāng)陌生。
很明顯，代碼審查的重要性并不為每個(gè)人所熟知。你可以說(shuō)我很天真，但是筆者確實(shí)認(rèn)為所有的IT公司都離不開(kāi)該過(guò)程。顯然實(shí)際并非如此，真是讓我大吃一驚。
在本文中，筆者想給出關(guān)于代碼審查的想法，以及為什么我認(rèn)為這是代碼遷移過(guò)程中非常重要的組成部分，怎樣進(jìn)行審查等。如果你目前不進(jìn)行代碼審查，或者想要做得更好，希望本文能有助于你！
我們生活在維基百科的時(shí)代，所以開(kāi)始之前，先引用一下其中關(guān)于代碼審查的定義：
代碼審查是計(jì)算機(jī)源代碼的系統(tǒng)性檢驗(yàn)（有時(shí)被稱為同行評(píng)審）。其目的在于找到開(kāi)發(fā)初期所忽略的錯(cuò)誤，從而提高軟件的整體質(zhì)量。審查的形式多種多樣，如結(jié)對(duì)編程，非正式走查，正式檢查等。
顧名思義，代碼審查就是審查一些代碼，以確保其能夠正常工作，并盡可能改善其性能。
正如維基百科中的定義，代碼審查有多種方法。然而，目前太多的代碼都存在于GitHub上，代碼審查也就經(jīng)常伴隨著所謂的“pull request”出現(xiàn)。
Pull request是一個(gè)請(qǐng)求，使用分布式版本控制系統(tǒng)（Git、SVN、Mercurial等）對(duì)代碼庫(kù)作出修改。它通過(guò)“牽引”原代碼、寫入更改，然后提交請(qǐng)求以便將更改合并。
得益于GitHub友好的用戶界面，這個(gè)過(guò)程變得非常簡(jiǎn)單高效，GitHub也概括了大部分Git知識(shí)需求。
那么，既然我們可以不經(jīng)過(guò)任何審查與監(jiān)督，直接進(jìn)行代碼遷移，為什么代碼審查還這么重要呢？畢竟，我們都能勝任該工作。
從理論上說(shuō)是這樣。但在實(shí)踐中，有很多原因可以表明代碼審查的重要性。讓我們來(lái)看看其中的幾個(gè)。
這可能是最重要的原因。有專人復(fù)核我們的工作并不是無(wú)關(guān)痛癢的，這能降低被忽視的錯(cuò)誤所帶來(lái)的風(fēng)險(xiǎn)。畢竟即使再好的開(kāi)發(fā)人員也有可能一時(shí)失察。
并且，確保沒(méi)有忘記任何事情總是有必要的。舉例來(lái)說(shuō)，前端開(kāi)發(fā)中經(jīng)常會(huì)忽略適當(dāng)?shù)逆I盤導(dǎo)航，屏幕閱讀器的可用性，適應(yīng)國(guó)際化的靈活性，以及友好的非JavaScript行為等問(wèn)題，在這里僅列出這四項(xiàng)。
清楚點(diǎn)說(shuō)，這不是單純的代碼標(biāo)準(zhǔn)和代碼檢查（至少不全是），而是使代碼更高效。
在一個(gè)團(tuán)隊(duì)里，每個(gè)人都有自己的背景和特長(zhǎng)，而團(tuán)隊(duì)始終需要進(jìn)步。因此總有人可能提出更聰明的解決方案，更合適的設(shè)計(jì)模式，或者能降低復(fù)雜性或提高性能的方法。
通過(guò)合作，每個(gè)人都可以相互學(xué)習(xí)并取得進(jìn)步。提交代碼者很有可能從該工作中得到反饋，并意識(shí)到可能存在的問(wèn)題和需要改進(jìn)的部分；而審查者也可以通過(guò)閱讀他人代碼學(xué)到新的東西，并找出適用于他們自己的工作方案。
當(dāng)一個(gè)團(tuán)隊(duì)在做一個(gè)項(xiàng)目時(shí)，想要每個(gè)開(kāi)發(fā)人員致力于應(yīng)用的每個(gè)部分，這是極不可能的。有時(shí)候，會(huì)出現(xiàn)這種情況：在某一段時(shí)間，一個(gè)開(kāi)發(fā)人員正為項(xiàng)目的大部分模塊辛苦地工作，而另一個(gè)人則完全在做別的東西。
因此，代碼審查有助于人們了解其他人所寫，但以后可能會(huì)需要自己來(lái)維護(hù)的那部分代碼。它促進(jìn)了代碼庫(kù)知識(shí)在團(tuán)隊(duì)中的傳播，也有可能加快未來(lái)的發(fā)展。
再次強(qiáng)調(diào)，有固定的代碼審查過(guò)程非常有用，非常重要。不管用什么方法，每個(gè)團(tuán)隊(duì)創(chuàng)造的代碼都應(yīng)該進(jìn)行代碼審查。
話雖這么說(shuō)，但進(jìn)行有意義的代碼審查并不像看上去那么簡(jiǎn)單明了。不過(guò)，別擔(dān)心，即使做得不好也不會(huì)有什么壞處，就是浪費(fèi)點(diǎn)時(shí)間。
最近，我的團(tuán)隊(duì)回顧了之前進(jìn)行的代碼審查。當(dāng)我們意識(shí)到12個(gè)開(kāi)發(fā)人員中，只有3個(gè)在做代碼審查時(shí)，我們就明白有些地方出了問(wèn)題。
為了改變這種狀況，我們的一位 Scrum 專家組織了一次回顧分析，以確定還可能改進(jìn)的空間，以及我們將怎樣改變。
代碼審查做得不夠，為了自圓其說(shuō)，最常用的借口就是，它需要時(shí)間——其他人不能或不愿意在這上面花費(fèi)時(shí)間。
我必須說(shuō)，筆者并不太理解這種說(shuō)法，因?yàn)槲业挠^點(diǎn)是：如果一個(gè)同事直接來(lái)找我，讓我?guī)退拿Γ揖筒粫?huì)說(shuō)“我沒(méi)有時(shí)間，也不感興趣”。反而，我會(huì)抽空來(lái)幫忙，可能不是現(xiàn)在，是一個(gè)小時(shí)之后——但是顯然，我會(huì)花時(shí)間幫助他們。為什么呢？ 因?yàn)椋?/p>
這就是團(tuán)隊(duì)的意義；
他們?cè)儐?wèn)我，這是因?yàn)樗麄兛粗匚业囊庖?jiàn)，這就值得我去幫助他們。
“為什么你不做代碼審查呢？”
“我沒(méi)有時(shí)間?！?/em>
對(duì)筆者而言，“pull request”和同事向我尋求幫助沒(méi)什么不同。有時(shí)候說(shuō)你沒(méi)時(shí)間是可以接受的，但系統(tǒng)性地拒絕幫助別人，就表明你正在積極地讓自己脫離團(tuán)隊(duì)。這種行為不友好，也不積極。所以要肯花時(shí)間提供幫助。
為了讓開(kāi)發(fā)人員抽出時(shí)間，我們就開(kāi)始考慮讓每個(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)在盡量不那么做了。通過(guò)創(chuàng)建較小的“pull request”，審查代碼變得更加容易，反饋也更加中肯，開(kāi)發(fā)人員也更愿意參與這個(gè)過(guò)程。“代碼遷移量更小也更頻繁”。
我們發(fā)現(xiàn)的第二大問(wèn)題是，我們通常缺乏對(duì)代碼背景的理解，如果你想要提供有用的反饋，這就很有必要。離開(kāi)了代碼背景，我們通常也只能進(jìn)行語(yǔ)法檢查——這雖然在一定程度上也有用，但遠(yuǎn)遠(yuǎn)不夠。這時(shí)候你就變成了我們所說(shuō)的“人工審查器”。
幸好，這個(gè)問(wèn)題比較好解決：給pull request添加一個(gè)描述以解釋你的目的，如何達(dá)到目的。這不需要一大段文字，通常短短幾行足矣。將鏈接添加到and/or也會(huì)起作用。Liv Madsen是我們的一位開(kāi)發(fā)者，她甚至增加了截屏——或者相關(guān)的截屏視頻——來(lái)解釋她做的東西，這令人稱奇。
第三個(gè)問(wèn)題就是我們有時(shí)干脆沒(méi)有意識(shí)到需要審查什么。的確，我們每天都充斥著無(wú)數(shù)的電子郵件和通知 ——郵件太多了，因此很難保存。畢竟我們只是普通的人。
同樣，解決辦法很簡(jiǎn)單：直接向別人詢問(wèn)需要審查的代碼。這有很多方法，比如在辦公室問(wèn)一聲，或者直接在Slack上給你團(tuán)隊(duì)的同事發(fā)消息。
我們基于自己的活動(dòng)在GitHub上創(chuàng)建了群組，當(dāng)提交pull request時(shí)，總是ping一個(gè)群組。群組的成員都會(huì)收到通知，并且只要有時(shí)間就可以自由地選擇如何解決。有時(shí)候，當(dāng)請(qǐng)求特別針對(duì)某一個(gè)（或幾個(gè)）人的工作時(shí)，我們就直接ping相應(yīng)的開(kāi)發(fā)人員。
然后，收到ping消息的人就可以審查代碼并發(fā)表評(píng)論。即使沒(méi)有什么具體的事需要報(bào)告，我們也會(huì)留言——表明代碼可以合并了。
因?yàn)槲覀兛赡軙?huì)不考慮已有的評(píng)論，盲目合并一些pull request，所以就建立了嚴(yán)格的“回復(fù)或解決”制度。當(dāng)收到反饋時(shí)，要么你把問(wèn)題解決，要么在回復(fù)中解釋為什么不能解決。無(wú)論如何都不能留下懸而未決的評(píng)論，也當(dāng)然不能將其與pull request合并。
進(jìn)行定期和高效的代碼審查對(duì)于保持高質(zhì)量的代碼標(biāo)準(zhǔn)來(lái)說(shuō)必不可少，還有利于開(kāi)發(fā)者之間的知識(shí)共享，以及團(tuán)隊(duì)的發(fā)展。
要求代碼審查并不意味著能力弱，請(qǐng)求他人的幫助也并不值得尷尬，代碼審查當(dāng)然也沒(méi)什么好羞愧的。另一方面，接受你獲得的反饋，并給提交pull request的人提供建設(shè)性的（理想情況下，積極的）的評(píng)論。
找到適合你的工作。審查代碼應(yīng)該在代碼遷移過(guò)程中占很大比重，所以你應(yīng)該在團(tuán)隊(duì)中適時(shí)調(diào)整，以保證對(duì)每個(gè)人都有益。
最后祝各位能夠愉快地審查代碼！
本文系 OneAPM 工程師整理呈現(xiàn)。OneAPM 能為您提供端到端的應(yīng)用性能解決方案，我們支持所有常見(jiàn)的框架及應(yīng)用服務(wù)器，助您快速發(fā)現(xiàn)系統(tǒng)瓶頸，定位異常根本原因。分鐘級(jí)部署，即刻體驗(yàn)，性能監(jiān)控從來(lái)沒(méi)有如此簡(jiǎn)單。想閱讀更多技術(shù)文章，請(qǐng)?jiān)L問(wèn) OneAPM 官方技術(shù)博客。
本文轉(zhuǎn)自 OneAPM 官方博客
原文鏈接：https://www.sitepoint.com/the-importance-of-code-reviews/
創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國(guó)云服務(wù)器，動(dòng)態(tài)BGP最優(yōu)骨干路由自動(dòng)選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機(jī)房獨(dú)有T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確進(jìn)行流量調(diào)度，確保服務(wù)器高可用性。佳節(jié)活動(dòng)現(xiàn)已開(kāi)啟，新人活動(dòng)云服務(wù)器買多久送多久。
重慶分公司
重慶分公司
