論代碼審查的重要性

【編者按】本文做者爲 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/