【編者按】本文作者為 Hugo Giraudel，主要從各個(gè)角度論證了代碼審查的重要性以及實(shí)現(xiàn)方法。文章系國(guó)內(nèi) ITOM 管理平臺(tái) OneAPM 編譯呈現(xiàn)。以下為正文。

創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括米脂網(wǎng)站建設(shè)、米脂網(wǎng)站制作、米脂網(wǎng)頁(yè)制作以及米脂網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，米脂網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到米脂省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

最近，筆者在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ò)“牽引”原代碼、寫(xiě)入更改，然后提交請(qǐng)求以便將更改合并。

得益于GitHub友好的用戶界面，這個(gè)過(guò)程變得非常簡(jiǎn)單高效，GitHub也概括了大部分Git知識(shí)需求。

為什么代碼審查非常重要

那么，既然我們可以不經(jīng)過(guò)任何審查與監(jiān)督，直接進(jìn)行代碼遷移，為什么代碼審查還這么重要呢？畢竟，我們都能勝任該工作。

從理論上說(shuō)是這樣。但在實(shí)踐中，有很多原因可以表明代碼審查的重要性。讓我們來(lái)看看其中的幾個(gè)。

降低風(fēng)險(xiǎn)

這可能是最重要的原因。有專人復(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盤(pán)導(dǎo)航，屏幕閱讀器的可用性，適應(yīng)國(guó)際化的靈活性，以及友好的非JavaScript行為等問(wèn)題，在這里僅列出這四項(xiàng)。

顯著提高代碼質(zhì)量

清楚點(diǎn)說(shuō)，這不是單純的代碼標(biāo)準(zhǔn)和代碼檢查（至少不全是），而是使代碼更高效。

在一個(gè)團(tuán)隊(duì)里，每個(gè)人都有自己的背景和特長(zhǎng)，而團(tuán)隊(duì)始終需要進(jìn)步。因此總有人可能提出更聰明的解決方案，更合適的設(shè)計(jì)模式，或者能降低復(fù)雜性或提高性能的方法。

使每個(gè)人都得到提高

通過(guò)合作，每個(gè)人都可以相互學(xué)習(xí)并取得進(jìn)步。提交代碼者很有可能從該工作中得到反饋，并意識(shí)到可能存在的問(wèn)題和需要改進(jìn)的部分；而審查者也可以通過(guò)閱讀他人代碼學(xué)到新的東西，并找出適用于他們自己的工作方案。

有助于熟悉項(xiàng)目

當(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è)人則完全在做別的東西。

因此，代碼審查有助于人們了解其他人所寫(xiě)，但以后可能會(huì)需要自己來(lái)維護(hù)的那部分代碼。它促進(jìn)了代碼庫(kù)知識(shí)在團(tuán)隊(duì)中的傳播，也有可能加快未來(lái)的發(fā)展。

怎樣適當(dāng)?shù)剡M(jìn)行代碼審查

再次強(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)的空間，以及我們將怎樣改變。

提前規(guī)劃

代碼審查做得不夠，為了自圓其說(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í)間。”

對(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ò)程。“代碼遷移量更小也更頻繁”。

結(jié)合語(yǔ)境

我們發(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)解釋她做的東西，這令人稱奇。

實(shí)際詢問(wèn)

第三個(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合并。

總結(jié)

進(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/

網(wǎng)頁(yè)題目：論代碼審查的重要性
轉(zhuǎn)載來(lái)源：http://aaarwkj.com/article32/ijpjpc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、定制開(kāi)發(fā)、全網(wǎng)營(yíng)銷推廣、微信小程序、搜索引擎優(yōu)化、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)