論代碼審查的重要性

【編者按】本文作者為 Hugo Giraudel，主要從各個角度論證了代碼審查的重要性以及實現方法。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。以下為正文。

最近，筆者在Twitter上看到這樣一句話：

可悲的是，對于很多學生、自由職業者以及機構來說，代碼審查似乎相當陌生。

很明顯，代碼審查的重要性并不為每個人所熟知。你可以說我很天真，但是筆者確實認為所有的IT公司都離不開該過程。顯然實際并非如此，真是讓我大吃一驚。

在本文中，筆者想給出關于代碼審查的想法，以及為什么我認為這是代碼遷移過程中非常重要的組成部分，怎樣進行審查等。如果你目前不進行代碼審查，或者想要做得更好，希望本文能有助于你！

什么是代碼審查？

我們生活在維基百科的時代，所以開始之前，先引用一下其中關于代碼審查的定義：

代碼審查是計算機源代碼的系統性檢驗（有時被稱為同行評審）。其目的在于找到開發初期所忽略的錯誤，從而提高軟件的整體質量。審查的形式多種多樣，如結對編程，非正式走查，正式檢查等。

顧名思義，代碼審查就是審查一些代碼，以確保其能夠正常工作，并盡可能改善其性能。

代碼審查的方法

正如維基百科中的定義，代碼審查有多種方法。然而，目前太多的代碼都存在于GitHub上，代碼審查也就經常伴隨著所謂的“pull request”出現。

Pull request是一個請求，使用分布式版本控制系統（Git、SVN、Mercurial等）對代碼庫作出修改。它通過“牽引”原代碼、寫入更改，然后提交請求以便將更改合并。

得益于GitHub友好的用戶界面，這個過程變得非常簡單高效，GitHub也概括了大部分Git知識需求。

為什么代碼審查非常重要

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

從理論上說是這樣。但在實踐中，有很多原因可以表明代碼審查的重要性。讓我們來看看其中的幾個。

降低風險

這可能是最重要的原因。有專人復核我們的工作并不是無關痛癢的，這能降低被忽視的錯誤所帶來的風險。畢竟即使再好的開發人員也有可能一時失察。

并且，確保沒有忘記任何事情總是有必要的。舉例來說，前端開發中經常會忽略適當的鍵盤導航，屏幕閱讀器的可用性，適應國際化的靈活性，以及友好的非JavaScript行為等問題，在這里僅列出這四項。

顯著提高代碼質量

清楚點說，這不是單純的代碼標準和代碼檢查（至少不全是），而是使代碼更高效。

在一個團隊里，每個人都有自己的背景和特長，而團隊始終需要進步。因此總有人可能提出更聰明的解決方案，更合適的設計模式，或者能降低復雜性或提高性能的方法。

使每個人都得到提高

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

有助于熟悉項目

當一個團隊在做一個項目時，想要每個開發人員致力于應用的每個部分，這是極不可能的。有時候，會出現這種情況：在某一段時間，一個開發人員正為項目的大部分模塊辛苦地工作，而另一個人則完全在做別的東西。

因此，代碼審查有助于人們了解其他人所寫，但以后可能會需要自己來維護的那部分代碼。它促進了代碼庫知識在團隊中的傳播，也有可能加快未來的發展。

怎樣適當地進行代碼審查

再次強調，有固定的代碼審查過程非常有用，非常重要。不管用什么方法，每個團隊創造的代碼都應該進行代碼審查。

話雖這么說，但進行有意義的代碼審查并不像看上去那么簡單明了。不過，別擔心，即使做得不好也不會有什么壞處，就是浪費點時間。

最近，我的團隊回顧了之前進行的代碼審查。當我們意識到12個開發人員中，只有3個在做代碼審查時，我們就明白有些地方出了問題。

為了改變這種狀況，我們的一位 Scrum 專家組織了一次回顧分析，以確定還可能改進的空間，以及我們將怎樣改變。

提前規劃

代碼審查做得不夠，為了自圓其說，最常用的借口就是，它需要時間——其他人不能或不愿意在這上面花費時間。

我必須說，筆者并不太理解這種說法，因為我的觀點是：如果一個同事直接來找我，讓我幫他的忙，我就不會說“我沒有時間，也不感興趣”。反而，我會抽空來幫忙，可能不是現在，是一個小時之后——但是顯然，我會花時間幫助他們。為什么呢？ 因為：

• 這就是團隊的意義；

• 他們詢問我，這是因為他們看重我的意見，這就值得我去幫助他們。

“為什么你不做代碼審查呢？” 
“我沒有時間。”

對筆者而言，“pull request”和同事向我尋求幫助沒什么不同。有時候說你沒時間是可以接受的，但系統性地拒絕幫助別人，就表明你正在積極地讓自己脫離團隊。這種行為不友好，也不積極。所以要肯花時間提供幫助。

為了讓開發人員抽出時間，我們就開始考慮讓每個程序員每天花一點時間（也許30分鐘）審查代碼。我們完成每天半小時的代碼審查時也不會發現什么意外驚喜：這只是一天中的一部分。

我們以前還試著大幅度降低 “pull request”包含的代碼量。因為曾經的“pull request”非常多——幾十個文件中有數以千計的改動。

我們現在盡量不那么做了。通過創建較小的“pull request”，審查代碼變得更加容易，反饋也更加中肯，開發人員也更愿意參與這個過程。“代碼遷移量更小也更頻繁”。

結合語境

我們發現的第二大問題是，我們通常缺乏對代碼背景的理解，如果你想要提供有用的反饋，這就很有必要。離開了代碼背景，我們通常也只能進行語法檢查——這雖然在一定程度上也有用，但遠遠不夠。這時候你就變成了我們所說的“人工審查器”。

幸好，這個問題比較好解決：給pull request添加一個描述以解釋你的目的，如何達到目的。這不需要一大段文字，通常短短幾行足矣。將鏈接添加到and/or也會起作用。Liv Madsen是我們的一位開發者，她甚至增加了截屏——或者相關的截屏視頻——來解釋她做的東西，這令人稱奇。

實際詢問

第三個問題就是我們有時干脆沒有意識到需要審查什么。的確，我們每天都充斥著無數的電子郵件和通知 ——郵件太多了，因此很難保存。畢竟我們只是普通的人。

同樣，解決辦法很簡單：直接向別人詢問需要審查的代碼。這有很多方法，比如在辦公室問一聲，或者直接在Slack上給你團隊的同事發消息。

我們基于自己的活動在GitHub上創建了群組，當提交pull request時，總是ping一個群組。群組的成員都會收到通知，并且只要有時間就可以自由地選擇如何解決。有時候，當請求特別針對某一個（或幾個）人的工作時，我們就直接ping相應的開發人員。

然后，收到ping消息的人就可以審查代碼并發表評論。即使沒有什么具體的事需要報告，我們也會留言——表明代碼可以合并了。

因為我們可能會不考慮已有的評論，盲目合并一些pull request，所以就建立了嚴格的“回復或解決”制度。當收到反饋時，要么你把問題解決，要么在回復中解釋為什么不能解決。無論如何都不能留下懸而未決的評論，也當然不能將其與pull request合并。

總結

進行定期和高效的代碼審查對于保持高質量的代碼標準來說必不可少，還有利于開發者之間的知識共享，以及團隊的發展。

要求代碼審查并不意味著能力弱，請求他人的幫助也并不值得尷尬，代碼審查當然也沒什么好羞愧的。另一方面，接受你獲得的反饋，并給提交pull request的人提供建設性的（理想情況下，積極的）的評論。

找到適合你的工作。審查代碼應該在代碼遷移過程中占很大比重，所以你應該在團隊中適時調整，以保證對每個人都有益。

最后祝各位能夠愉快地審查代碼！

本文系 OneAPM 工程師整理呈現。OneAPM 能為您提供端到端的應用性能解決方案，我們支持所有常見的框架及應用服務器，助您快速發現系統瓶頸，定位異常根本原因。分鐘級部署，即刻體驗，性能監控從來沒有如此簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客

原文鏈接：https://www.sitepoint.com/the-importance-of-code-reviews/