code review的做用

知乎上有個問答：你們的公司的 Code Review 都是怎麼作的？遇到過哪些問題？不少答主都提到Code Review的做用是提早發現bug、提升代碼質量，順帶統一團隊編碼規範等等。

秀一下咱們的幾回CodeReview。

提早發現bug

當了爸媽了以後，人都不免有「不讓孩子再吃本身吃過的苦」這樣的想法。其實reviewer也會有這種「老父親/老母親」的心理：「不讓別人再踩本身踩過的坑」。

好比這段討論。爲了把一個對象中的字段轉爲Map（key爲字段名、value爲字段值），咱們有這樣一段代碼：

圍繞這段代碼，咱們有這樣一段review（聊天）:

首先，有同事L在review時提出能夠用反射來作，並表示在另外的某個地方有現成的代碼可供參考。隨後，另外一位同事S微微一笑：「在你來以前咱們就用過反射了」，並指出了使用反射可能帶來的問題。同事L恍然大悟，在同事S的明教之下，修改了他的代碼，避免了一個因爲對技術理解不夠透徹而致使的bug。

那是否是隻有技術大牛可以在review中提早發現bug呢？顯然不是。除了技術不足的緣由，對業務理解不夠也會致使bug。而這種bug一樣能夠在「老父親/老母親」的目光下被提早發現並解決。

例如，某次需求在系統增長了這樣兩個枚舉：

關於這兩行代碼，有這樣一段review：

這段review與技術無關，它指出的是一個純粹的業務bug：這個枚舉所處理的業務要求它的構造方法中的第一個參數必須是「xxx.SUCCESS」或者"xxx.FAIL"格式。雖然寫代碼的同事並不熟悉這個業務要求，可是好在熟悉業務的同事參與了review，並提早發現了這個bug。

那麼，是否是隻有精通技術、或者熟悉業務，才能參與code review，並發現潛在的bug呢？其實也不是。咱們再看看這段代碼：

• 
  

這裏的review簡單明瞭地指出其中的問題：

這個bug的緣由與業務無關，也不涉及多麼高精尖的技術，純粹就是開發人員粗枝大葉形成的。只要認真參與review，就能發現這種粗枝大葉、一時手誤的問題。

提升代碼質量

提升代碼質量、提高開發技術，應該說是每一個程序員的目標。實現目標的方式有不少，參與code review就是其中一種。不管是看別人寫的代碼、仍是看圍繞代碼展開的討論，都有「他山之石能夠攻玉」的做用。

例如，咱們有這樣一個類：

關於它，咱們有這樣一段review（聊天）：

看完這段review，是否是對SpringMVC和HttpServletRequest有多了一點了解？若是有興趣再去鑽研一下「SpringMVC其實還有其它方法來實現這個功能」，是否是又能百尺竿頭更進一步了呢？

又如，圍繞Controller是直接操做Response、仍是封裝ResponseEntity來返回InputStream，咱們也有這樣的review（聊天）。相信不管對三位直接參與者仍是衆多圍觀者，這段討論都會大有裨益：

統一團隊規範

其實我的以爲……統一團隊規範這個做用在review中算是名列「後」茅的了。可是在實踐中，不少review都是從檢查編碼規範開始的：命名啦，註釋啦，換行啦，空格啦，等等。有時甚至會給人一種「review就只能檢查檢查代碼規範」的感受。

這種感受固然是錯覺，咱們在review中引起的討論、發現的bug就是明證。可是，就如張國榮也要苦熬十年同樣，咱們也在「review就只能檢查代碼規範」的泥潭中跋涉了好久。這實際上是開展code review的必經之路。一方面，從未經歷過review的團隊，其代碼規範確定存在問題——要麼有規範不遵照，要麼壓根沒有規範。另外一方面，對於reviewer來講，規範問題是最容易被發現一類問題。這兩方面湊到一塊兒，規範問題還不一抓一大把麼？

要從這個泥潭中走出來，最根本的法子就是團隊真正的創建規範、遵循規範、重視規範。只有作到了這一點，code review纔能有效地提早發現bug、提升代碼質量。