你太菜了，竟然不知道Code Review？

我一直認為Code Review(代碼審查)是軟件開發中的優秀實踐之一，可以有效提高整體代碼質量，及時發現代碼中可能存在的問題。

包括像 Google、微軟這些公司，Code Review 都是基本要求，代碼合併之前必須要有人審查通過才行。

然而對於我觀察到的大部分軟件開發團隊來說，認真做 Code Review 的很少，有的流於形式，有的可能根本就沒有 Code Review 的環節，代碼質量只依賴於事後的測試。也有些團隊想做好代碼審查，但不知道怎麼做比較好。

網上關於如何做 Code Review 的文章已經有很多了，這裡我結合自己的一些經驗，也總結整理了一下 Code Review 的優秀實踐，希望能對大家做好 Code Review 有所幫助。

Code Review 有什麼好處?

很多團隊或個人不做 Code Review，根源還是不覺得這是一件有意義的事情，不覺得有什麼好處。這個問題要從幾個角度來看。

團隊知識共享的角度

一個開發團隊中，水平有高有低，每個人側重的領域也有不同：

• 怎麼讓高水平的幫助新人成長?
• 怎麼讓大家都對自己側重領域之外的知識保持瞭解?
• 怎麼能有人離職後其他人能快速接手?

這些都是團隊管理者關心的問題。而代碼審查，就是一個很好的知識共享的方式。

通過代碼審查，高手可以直接指出新手代碼中的問題，新手可以馬上從高手的反饋中學習到好的實踐，得到更快的成長;通過代碼審查，前端也可以去學習後端的代碼，做功能模塊 A 的可以去了解功能模塊 B 的。

可能有些高手覺得給新手代碼審查浪費時間，自己也沒收穫。其實不然，新人成長了，就可以更多的幫高手分擔繁重的任務;代碼審查中花時間，就少一些幫新人填坑擦屁股的時間。

良好的溝通能力、發現問題的能力、幫助其他人成長，都是技術轉管理或技術上更上一層樓必不可少的能力，而通過代碼審查可以有效的去練習這些方面的能力。

現實中的項目總是人手缺進度緊，所以被壓縮的往往就是自動化測試和代碼審查，結果影響代碼質量，欠下技術債務，最後還是要加倍償還。

也有人寄希望於開發後的人工測試，然而對於代碼質量來說，很多問題通過測試是測試不出來的，只能通過代碼審查。

比如說代碼的可讀性可維護性，比如代碼的結構，比如一些特定條件才觸發的死循環、邏輯算法錯誤，還有一些安全上的漏洞也更容易通過代碼審查發現和預防。

也有人覺得自己水平高就不需要代碼審查了。對於高手來說，讓別人審查自己的代碼，可以讓其他人學習到好的實踐;在讓其他人審查的同時，在給別人說明自己代碼的時候，也等於自己對自己的代碼進行了一次審查。

這其實就跟我們上學時做數學題一樣，真正能拿高分的往往是那些做完後還會認真檢查的。

團隊規範的角度

每個團隊都有自己的代碼規範，有自己的基於架構設計的開發規範，然而時間一長，就會發現代碼中出現很多不遵守代碼規範的情況，有很多繞過架構設計的代碼。

比如難以理解和不規範的命名，比如三層架構裡面 UI 層繞過業務邏輯層直接調用數據訪問層代碼。

如果這些違反規範的代碼被糾正的晚了，後面再要修改就成本很高了，而且團隊的規範也會慢慢的形同虛設。

通過代碼審查，就可以及時的去發現和糾正這些問題，保證團隊規範的執行。關於代碼審查的好處，還有很多，也不一一列舉。

還是希望能認識到 Code Review 和寫自動化測試一樣，都是屬於磨刀不誤砍柴工的工作，在上面投入一點點時間，未來會收穫代碼質量，會節約整體的開發時間。

Code Review 該怎麼做?

現在很多人都已經有意識到 Code Review 的重要性了，只是苦於不知道如何去實踐，不知道怎麼樣算是好的 Code Review 實踐。

在很早以前，我就嘗試過將代碼審查作為代碼流程的一部分，但只是一個可選項，沒有 Code Review 也可以把代碼合併到 Master。

這樣的結果就是想起來才會去做 Code Review，去檢查的時候已經有了太多的代碼變更，審查起來非常困難，另外就算審查出問題，也很難得以修改。

我們現在對代碼的審查則是作為開發流程的一個必選項，每次開發新功能或者修復 Bug，開一個新的分支，分支要合併到 Master 有兩個必要條件：

• 所有的自動化測試通過。
• 有至少一個人 Code Review 通過，如果是新手的 PR，還必須有資深程序員 Code Review 通過。

這樣把 Code Review 作為開發流程的一個必選項後，就很好的保證了代碼在合併之前有過 Code Review。

而且這樣合併前要求代碼審查的流程，好處也很明顯：

• 由於每一次合併前都要做代碼審查，這樣一般一次審查的代碼量也不會太大，對於審查者來說壓力也不會太大。
• 如果在 Code Review 時發現問題，被審查者希望代碼能儘快合併，也會積極的對審查出來的問題進行修改，不至於對審查結果太過牴觸。

如果你覺得 Code Review 難以推行，不妨先嚐試著把 Code Review 變成你開發流程的一個必選項。

②把 Code Review 變成一種開發文化而不僅僅是一種制度

把 Code Review 作為開發流程的必選項後，不代表 Code Review 這件事就可以執行的很好，因為 Code Review 的執行，很大部分程度上依賴於審查者的認真審查，以及被審查者的積極配合，兩者缺一不可!

如果僅僅只是當作一個流程制度，那麼就可能會流於形式。最終結果就是看起來有 Code Review，但沒有人認真審查，隨便看下就通過了，或者發現問題也不願意修改。

真要把 Code Review 這件事做好，必須讓 Code Review 變成團隊的一種文化，開發人員從心底接受這件事，並認真執行這件事。

要形成這樣的文化，不那麼容易，也沒有想象的那麼難，比如這些方面可以參考：

• 首先，得讓開發人員認識到 Code Review 這件事為自己、為團隊帶來的好處。
• 然後，得要有幾個人做好表率作用，榜樣的力量很重要。
• 還有，對於管理者來說，你激勵什麼，往往就會得到什麼。
• 最後，像寫自動化測試一樣，把 Code Review 作為開發任務的一部分，給審查者和被審查者都留出專門的時間去做這件事，不能光想著馬兒跑得快又捨不得給馬兒吃草。

如何形成這樣的文化，有心的話，還有很多方法可以嘗試。只有真正讓大家都認同和踐行，才可能去做好 Code Review 這件事。

一些 Code Review 的經驗技巧

在做好 Code Review 這件事上，還有一些經驗技巧可以參考。

①選什麼工具輔助做 Code Review?

現在很多源代碼管理工具都自帶 Code Review 工具，典型的像 Github、Gitlab、微軟的 Azure DevOps，尤其是像 Gitlab，還可以自己在本地搭建環境，根據自己的需要靈活配置。

②配合什麼樣的開發流程比較好?

像 Github Flow 這樣基於分支開發的流程是特別適合搭配 Code Review 的。

其實不管什麼樣的開發流程，關鍵點在於代碼合併到 Master(主幹)之前，要先做 Code Review。

③真遇到緊急情況，來不及代碼審查怎麼辦?

雖然原則上，必須要 Code Review 才能合併，但有時候確實會存在一些緊急情況，比如說線上故障補丁，而又沒有其他人在線。

那麼這種情況下，最好是在任務管理系統中，創建一個 Ticket，用來後續跟蹤，確保後續補上 Code Review，並對 Code Review 結果有後續的代碼更新。

④先設計再編碼

有些新人發現自己的代碼提交 PR(Pull Request)後，會收到一堆的 Code Review 意見，必須要做大量的改動。這多半是因為在開始做之前，沒有做好設計，做出來後才發現問題很多。

建議在做一個新功能之前，寫一個簡單的設計文檔，表達清楚自己的設計思路，找資深的同事先幫你做一下設計的審查，發現設計上的問題。設計上沒問題了，再著手開發，那麼到 Review 的時候，相對問題就會少很多。

⑤代碼在提交 Code Review 之前，作者要自己先 Review 和測試一遍

我在做代碼審查的時候，有時候會發現一些非常明顯的問題，有些甚至自己都沒有測試過，就等著別人 Code Review 和測試幫助發現問題。這種依賴心理無論是對自己還是對團隊都是很不負責任的。

一個好的開發人員，代碼在提交 Code Review 之前，肯定是要自己先 Review 一遍，把該寫的自動化測試代碼寫上，自己把基本的測試用例跑一遍的。

我對於團隊提交的 PR，有個要求就是要在 PR 的描述中增加截圖或者錄屏，就是為了通過截圖或者錄屏，確保提交 PR 的人自己是先測試過的。這也是一個有效的輔助手段。

⑥PR 要小

在做 Code Review 的時候，如果有大量的文件修改，那麼 Review 起來是很困難的，但如果 PR 比較小，相對就比較容易 Review，也容易發現代碼中可能存在的問題。

所以在提交 PR 時，PR 要小，如果是比較大的改動，那麼最好分批提交，以減輕審查者的壓力。

⑦對評論進行分級

在做 Code Review 時，需要針對審查出有問題的代碼行添加評論，如果只是評論，有時候對於被審查者比較難甄別評論所代表的含義，是不是必須要修改。

建議可以對 Review 的評論進行分級，不同級別的結果可以打上不同的 Tag，比如說：

• [blocker]：在評論前面加上一個 [blocker] 標記，表示這個代碼行的問題必須要修改。
• [optional]：在評論前面加上一個 [optional] 標記，表示這個代碼行的問題可改可不改。
• [question]：在評論前面加上一個 [question] 標記，表示對這個代碼行不理解，有問題需要問，被審查者需要針對問題進行回覆澄清。

類似這樣的分級可以幫助被審查者直觀瞭解 Review 結果，提高 Review 效率。

雖然評論是主要的 Code Review 溝通方式，但也不要過於依賴，有時候面對面的溝通效率更高，也容易消除誤解。

另外文明用語，不要用一些負面的詞彙。

總結

Code Review 是一種非常好的開發實踐，如果你還沒開始，不妨逐步實踐起來。

如果已經做了效果不好，不妨對照一下，看有沒有把 Code Review 作為開發流程的必選項而不是可選項?有沒有把 Code Review 變成一種開發文化而不僅僅是一種制度?