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](https://www.techopedia.com/definition/14299/code-review) 這是目前我見過對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》](https://captnotes.com/remove_before_flight)。 提交者在程式碼被Review之前，還應該調整好心態，把別人的詢問、質疑、建議、批評，通通視作可能的提升機會，而不要主觀上認定自己給出的就是最優解，而別人都是“不明真相的圍觀群眾”。也許別人在不瞭解背景資訊或上下文的情況下，給出了錯誤的建議，提交者也應當將此作為鍛鍊思維和口才的友好辯論，而不是玻璃心受到了侵犯似的直接懟回去。 ## 參與者 參與者應該對編碼規範瞭然於心，對於程式碼中每一處不符合團隊現行編碼規範的地方都要不厭其煩地標註出來。很多人認為這個無所謂，反正機器最後讀的都是0和1——對，機器只認識0和1，所以原始碼其實是寫給人看的。不管程式碼由多少人寫就，最終看上去如同出自同一人之手，這種程式碼的閱讀體驗和效率絕對要比那種百家爭鳴式的好得多。 如果是面向物件的程式語言，參與者應當考察提交者對抽象的理解和實踐，是否準確以及是否過淺或過深。抽象過淺，看上去往往是大雜燴；抽象過深，讀起來顯得吃力。對於這兩種情況，參與者都可以提出自己的看法和建議，不要抱著“你這不行，聽我的”的態度，否則很容易形成對立的情緒，進而影響團隊對Code Review的積極性。 對於程式碼實現是否存在改進空間這個問題，參與者應該在閱讀新程式碼時，儘可能全面地去理解問題域、瞭解需求的具體細節，而不是想當然地丟擲質疑和意見，給人以浮躁的印象。如果參與者確定自己清楚地理解了需求和問題，依然對當前的程式碼實現有改進建議，那麼就大膽地提出來，這就是Code Review的核心