如何作好Code Review

Code Review（代碼審查）不少團隊都會作，效果如何很差說。若是你能輕易地從一堆出自正經團隊之手的代碼裏找出幾個低級錯誤，每每意味着團隊管理者長期忽視了Code Review的重要性。

根據經驗，匆匆應付功能實現和漏洞修復而將Code Review流於形式的團隊不在少數。固然，每一個人都能列舉一大堆「客觀緣由」，並且每一條理由聽起來都是那麼的有說服力。然而，沒作好就是沒作好，狡辯只會讓場面變得更加噁心。

What（什麼是Code Review）

A code review is the process of examining written code with the purpose of highlighting mistakes in order to learn from them.

-- Techopedia

這是目前我見過對Code Review最言簡意賅的定義。其實怎麼描述並不重要，重要的是咱們要達到什麼樣的目的。

Why（爲何要作Code Review）

提升代碼質量是程序員端穩飯碗、少挨點兒罵的最有效途徑。其實Code Review就是很好的相互切磋、共同進步的機會，效果要比獨自埋頭幹啃《21天精通×××》之類的「寶典」好得多。固然，前提是目的明確、態度端正。

Code Review主要目的就兩個：

查錯

Code Review不是用來查找低級錯誤的，而是參與者以提交者之外的視角閱讀和審視代碼，儘量地找到邏輯上的問題。

學習

與其說Code Review重在找到問題，不如說其核心目的在於營造團隊學習氛圍、提高成員對軟件品質的追求。我經歷過很多團隊，爲了營造學習氛圍，生拉硬拽地要求成員按期舉行技術分享會，結果每每敷衍了事、不了了之。

How（怎樣作Code Review）

下面根據Code Review中涉及的主要人物角色來說講我推薦的方式。注意，這不是標準答案。

具體劃分角色責任以前，我建議每一個技術團隊都要找到並嚴格執行適合本團隊技術棧的編碼規範，甚至包括IDE配置和開發環境參數設定等，以確保每位成員都「說着一樣的語言」，並減小在命名規則、排版樣式等方面的爭論，將時間和精力聚焦到對功能實現和業務優化這些實質性的問題上來。

開發小組技術負責人

每一位開發小組技術負責人都應該積極實施並維護Code Review機制，要求每位成員在提交代碼的時候，都必須通過交叉Review，也就是每一次代碼提交到主幹時，都必須通過另外一位相同技術領域同事的Review，不然將被視爲提交了與存在編譯時錯誤的代碼同等的嚴重過失。

每次代碼提交的交叉Review，開發小組技術負責人應當隨機抽取包括本身在內的任何一位技術人員進行，不要讓提交者可以很輕易地預知將會是誰來作本身這一次的Reviewer，不然很容易變成形式主義。

而且，對於Feature實現的Code Review，開發小組技術負責人應該較爲頻繁但不按期地進行公開Review。組織一場會議，召集整個開發小組的成員一塊兒對這次提交的代碼進行審查。

提交者

不論Code Review是私下的仍是公開的，提交者都不能提交任何存在編譯時錯誤的代碼，這是很是低級的錯誤。首先在提交代碼以前再次進行編譯，是確保即將提交的代碼不存在編譯時錯誤的必要步驟。其次，也是不少人容易疏忽的，確保本次新增的本地資源文件都被加入了源代碼管理，不然即便本地能編譯經過，別人拿到你的代碼也依然存在編譯時問題。

提交代碼以前，本身先diff一下，首先確保代碼不存在前面提到的諸如命名、格式等方面的低級錯誤；而後肯定本身對每一處代碼變更的理解都很是明確，而且本身已經找不出改進方案；最後確保全部Hard Code都已經被移除，這一點能夠參考我以前寫的《沒什麼技術含量的Remove Before Flight》。

提交者在代碼被Review以前，還應該調整好心態，把別人的詢問、質疑、建議、批評，統統視做可能的提高機會，而不要主觀上認定本身給出的就是最優解，而別人都是「不明真相的圍觀羣衆」。也許別人在不瞭解背景信息或上下文的狀況下，給出了錯誤的建議，提交者也應當將此做爲鍛鍊思惟和口才的友好辯論，而不是玻璃心受到了侵犯似的直接懟回去。

參與者

參與者應該對編碼規範瞭然於心，對於代碼中每一處不符合團隊現行編碼規範的地方都要不厭其煩地標註出來。不少人認爲這個無所謂，反正機器最後讀的都是0和1——對，機器只認識0和1，因此源代碼實際上是寫給人看的。無論代碼由多少人寫就，最終看上去如同出自同一人之手，這種代碼的閱讀體驗和效率絕對要比那種百家爭鳴式的好得多。

若是是面向對象的編程語言，參與者應當考察提交者對抽象的理解和實踐，是否準確以及是否過淺或過深。抽象過淺，看上去每每是大雜燴；抽象過深，讀起來顯得吃力。對於這兩種狀況，參與者均可以提出本身的見解和建議，不要抱着「你這不行，聽個人」的態度，不然很容易造成對立的情緒，進而影響團隊對Code Review的積極性。

對於代碼實現是否存在改進空間這個問題，參與者應該在閱讀新代碼時，儘量全面地去理解問題域、瞭解需求的具體細節，而不是想固然地拋出質疑和意見，給人以浮躁的印象。若是參與者肯定本身清楚地理解了需求和問題，依然對當前的代碼實現有改進建議，那麼就大膽地提出來，這就是Code Review的核心目的！