知乎上有個問答：大家的公司的 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、提高代碼質量。