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

作者：寶玉

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

圖片來自 Unsplash

包括像 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 作為開發流程的必選項而不是可選項

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

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

圖片來源：How to Do Code Reviews Like a Huma

我們現在對代碼的審查則是作為開發流程的一個必選項，每次開發新功能或者修復 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 變成一種開發文化而不僅僅是一種制度?

閱讀目錄（置頂)(長期更新計算機領域知識）

閱讀目錄（置頂)(長期更新計算機領域知識）

閱讀目錄（置頂)(長期科技領域知識）

歌謠帶你看java面試題

?

總結

以上是生活随笔為你收集整理的第四十八期:你太菜了，竟然不知道Code Review？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。