我一直認(rèn)為Code Review(代碼審查)是軟件開發(fā)中的優(yōu)秀實(shí)踐之一，可以有效提高整體代碼質(zhì)量，及時(shí)發(fā)現(xiàn)代碼中可能存在的問題。

[[280325]]

圖片來自 Unsplash

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

然而對(duì)于我觀察到的大部分軟件開發(fā)團(tuán)隊(duì)來說，認(rèn)真做 Code Review 的很少，有的流于形式，有的可能根本就沒有 Code Review 的環(huán)節(jié)，代碼質(zhì)量只依賴于事后的測(cè)試。也有些團(tuán)隊(duì)想做好代碼審查，但不知道怎么做比較好。

網(wǎng)上關(guān)于如何做 Code Review 的文章已經(jīng)有很多了，這里我結(jié)合自己的一些經(jīng)驗(yàn)，也總結(jié)整理了一下 Code Review 的優(yōu)秀實(shí)踐，希望能對(duì)大家做好 Code Review 有所幫助。

Code Review 有什么好處?

很多團(tuán)隊(duì)或個(gè)人不做 Code Review，根源還是不覺得這是一件有意義的事情，不覺得有什么好處。這個(gè)問題要從幾個(gè)角度來看。

團(tuán)隊(duì)知識(shí)共享的角度

一個(gè)開發(fā)團(tuán)隊(duì)中，水平有高有低，每個(gè)人側(cè)重的領(lǐng)域也有不同：

• 怎么讓高水平的幫助新人成長(zhǎng)?
• 怎么讓大家都對(duì)自己側(cè)重領(lǐng)域之外的知識(shí)保持了解?
• 怎么能有人離職后其他人能快速接手?

這些都是團(tuán)隊(duì)管理者關(guān)心的問題。而代碼審查，就是一個(gè)很好的知識(shí)共享的方式。

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

可能有些高手覺得給新手代碼審查浪費(fèi)時(shí)間，自己也沒收獲。其實(shí)不然，新人成長(zhǎng)了，就可以更多的幫高手分擔(dān)繁重的任務(wù);代碼審查中花時(shí)間，就少一些幫新人填坑擦屁股的時(shí)間。

良好的溝通能力、發(fā)現(xiàn)問題的能力、幫助其他人成長(zhǎng)，都是技術(shù)轉(zhuǎn)管理或技術(shù)上更上一層樓必不可少的能力，而通過代碼審查可以有效的去練習(xí)這些方面的能力。

代碼質(zhì)量的角度

現(xiàn)實(shí)中的項(xiàng)目總是人手缺進(jìn)度緊，所以被壓縮的往往就是自動(dòng)化測(cè)試和代碼審查，結(jié)果影響代碼質(zhì)量，欠下技術(shù)債務(wù)，最后還是要加倍償還。

也有人寄希望于開發(fā)后的人工測(cè)試，然而對(duì)于代碼質(zhì)量來說，很多問題通過測(cè)試是測(cè)試不出來的，只能通過代碼審查。

比如說代碼的可讀性可維護(hù)性，比如代碼的結(jié)構(gòu)，比如一些特定條件才觸發(fā)的死循環(huán)、邏輯算法錯(cuò)誤，還有一些安全上的漏洞也更容易通過代碼審查發(fā)現(xiàn)和預(yù)防。

也有人覺得自己水平高就不需要代碼審查了。對(duì)于高手來說，讓別人審查自己的代碼，可以讓其他人學(xué)習(xí)到好的實(shí)踐;在讓其他人審查的同時(shí)，在給別人說明自己代碼的時(shí)候，也等于自己對(duì)自己的代碼進(jìn)行了一次審查。

這其實(shí)就跟我們上學(xué)時(shí)做數(shù)學(xué)題一樣，真正能拿高分的往往是那些做完后還會(huì)認(rèn)真檢查的。

團(tuán)隊(duì)規(guī)范的角度

每個(gè)團(tuán)隊(duì)都有自己的代碼規(guī)范，有自己的基于架構(gòu)設(shè)計(jì)的開發(fā)規(guī)范，然而時(shí)間一長(zhǎng)，就會(huì)發(fā)現(xiàn)代碼中出現(xiàn)很多不遵守代碼規(guī)范的情況，有很多繞過架構(gòu)設(shè)計(jì)的代碼。

比如難以理解和不規(guī)范的命名，比如三層架構(gòu)里面 UI 層繞過業(yè)務(wù)邏輯層直接調(diào)用數(shù)據(jù)訪問層代碼。

如果這些違反規(guī)范的代碼被糾正的晚了，后面再要修改就成本很高了，而且團(tuán)隊(duì)的規(guī)范也會(huì)慢慢的形同虛設(shè)。

通過代碼審查，就可以及時(shí)的去發(fā)現(xiàn)和糾正這些問題，保證團(tuán)隊(duì)規(guī)范的執(zhí)行。關(guān)于代碼審查的好處，還有很多，也不一一列舉。

還是希望能認(rèn)識(shí)到 Code Review 和寫自動(dòng)化測(cè)試一樣，都是屬于磨刀不誤砍柴工的工作，在上面投入一點(diǎn)點(diǎn)時(shí)間，未來會(huì)收獲代碼質(zhì)量，會(huì)節(jié)約整體的開發(fā)時(shí)間。

Code Review 該怎么做?

現(xiàn)在很多人都已經(jīng)有意識(shí)到 Code Review 的重要性了，只是苦于不知道如何去實(shí)踐，不知道怎么樣算是好的 Code Review 實(shí)踐。

①把 Code Review 作為開發(fā)流程的必選項(xiàng)而不是可選項(xiàng)

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

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

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

我們現(xiàn)在對(duì)代碼的審查則是作為開發(fā)流程的一個(gè)必選項(xiàng)，每次開發(fā)新功能或者修復(fù) Bug，開一個(gè)新的分支，分支要合并到 Master 有兩個(gè)必要條件：

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

這樣把 Code Review 作為開發(fā)流程的一個(gè)必選項(xiàng)后，就很好的保證了代碼在合并之前有過 Code Review。

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

• 由于每一次合并前都要做代碼審查，這樣一般一次審查的代碼量也不會(huì)太大，對(duì)于審查者來說壓力也不會(huì)太大。
• 如果在 Code Review 時(shí)發(fā)現(xiàn)問題，被審查者希望代碼能盡快合并，也會(huì)積極的對(duì)審查出來的問題進(jìn)行修改，不至于對(duì)審查結(jié)果太過抵觸。

如果你覺得 Code Review 難以推行，不妨先嘗試著把 Code Review 變成你開發(fā)流程的一個(gè)必選項(xiàng)。

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

把 Code Review 作為開發(fā)流程的必選項(xiàng)后，不代表 Code Review 這件事就可以執(zhí)行的很好，因?yàn)?Code Review 的執(zhí)行，很大部分程度上依賴于審查者的認(rèn)真審查，以及被審查者的積極配合，兩者缺一不可!

如果僅僅只是當(dāng)作一個(gè)流程制度，那么就可能會(huì)流于形式。最終結(jié)果就是看起來有 Code Review，但沒有人認(rèn)真審查，隨便看下就通過了，或者發(fā)現(xiàn)問題也不愿意修改。

真要把 Code Review 這件事做好，必須讓 Code Review 變成團(tuán)隊(duì)的一種文化，開發(fā)人員從心底接受這件事，并認(rèn)真執(zhí)行這件事。

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

• 首先，得讓開發(fā)人員認(rèn)識(shí)到 Code Review 這件事為自己、為團(tuán)隊(duì)帶來的好處。
• 然后，得要有幾個(gè)人做好表率作用，榜樣的力量很重要。
• 還有，對(duì)于管理者來說，你激勵(lì)什么，往往就會(huì)得到什么。
• 最后，像寫自動(dòng)化測(cè)試一樣，把 Code Review 作為開發(fā)任務(wù)的一部分，給審查者和被審查者都留出專門的時(shí)間去做這件事，不能光想著馬兒跑得快又舍不得給馬兒吃草。

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

一些 Code Review 的經(jīng)驗(yàn)技巧

在做好 Code Review 這件事上，還有一些經(jīng)驗(yàn)技巧可以參考。

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

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

②配合什么樣的開發(fā)流程比較好?

像 Github Flow 這樣基于分支開發(fā)的流程是特別適合搭配 Code Review 的。

其實(shí)不管什么樣的開發(fā)流程，關(guān)鍵點(diǎn)在于代碼合并到 Master(主干)之前，要先做 Code Review。

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

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

那么這種情況下，最好是在任務(wù)管理系統(tǒng)中，創(chuàng)建一個(gè) Ticket，用來后續(xù)跟蹤，確保后續(xù)補(bǔ)上 Code Review，并對(duì) Code Review 結(jié)果有后續(xù)的代碼更新。

④先設(shè)計(jì)再編碼

有些新人發(fā)現(xiàn)自己的代碼提交 PR(Pull Request)后，會(huì)收到一堆的 Code Review 意見，必須要做大量的改動(dòng)。這多半是因?yàn)樵陂_始做之前，沒有做好設(shè)計(jì)，做出來后才發(fā)現(xiàn)問題很多。

建議在做一個(gè)新功能之前，寫一個(gè)簡(jiǎn)單的設(shè)計(jì)文檔，表達(dá)清楚自己的設(shè)計(jì)思路，找資深的同事先幫你做一下設(shè)計(jì)的審查，發(fā)現(xiàn)設(shè)計(jì)上的問題。設(shè)計(jì)上沒問題了，再著手開發(fā)，那么到 Review 的時(shí)候，相對(duì)問題就會(huì)少很多。

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

我在做代碼審查的時(shí)候，有時(shí)候會(huì)發(fā)現(xiàn)一些非常明顯的問題，有些甚至自己都沒有測(cè)試過，就等著別人 Code Review 和測(cè)試幫助發(fā)現(xiàn)問題。這種依賴心理無論是對(duì)自己還是對(duì)團(tuán)隊(duì)都是很不負(fù)責(zé)任的。

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

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

⑥PR 要小

在做 Code Review 的時(shí)候，如果有大量的文件修改，那么 Review 起來是很困難的，但如果 PR 比較小，相對(duì)就比較容易 Review，也容易發(fā)現(xiàn)代碼中可能存在的問題。

所以在提交 PR 時(shí)，PR 要小，如果是比較大的改動(dòng)，那么最好分批提交，以減輕審查者的壓力。

⑦對(duì)評(píng)論進(jìn)行分級(jí)

在做 Code Review 時(shí)，需要針對(duì)審查出有問題的代碼行添加評(píng)論，如果只是評(píng)論，有時(shí)候?qū)τ诒粚彶檎弑容^難甄別評(píng)論所代表的含義，是不是必須要修改。

建議可以對(duì) Review 的評(píng)論進(jìn)行分級(jí)，不同級(jí)別的結(jié)果可以打上不同的 Tag，比如說：

• [blocker]：在評(píng)論前面加上一個(gè) [blocker] 標(biāo)記，表示這個(gè)代碼行的問題必須要修改。
• [optional]：在評(píng)論前面加上一個(gè) [optional] 標(biāo)記，表示這個(gè)代碼行的問題可改可不改。
• [question]：在評(píng)論前面加上一個(gè) [question] 標(biāo)記，表示對(duì)這個(gè)代碼行不理解，有問題需要問，被審查者需要針對(duì)問題進(jìn)行回復(fù)澄清。

類似這樣的分級(jí)可以幫助被審查者直觀了解 Review 結(jié)果，提高 Review 效率。

⑧評(píng)論要友好，避免負(fù)面詞匯;有說不清楚的問題當(dāng)面溝通

雖然評(píng)論是主要的 Code Review 溝通方式，但也不要過于依賴，有時(shí)候面對(duì)面的溝通效率更高，也容易消除誤解。

另外文明用語，不要用一些負(fù)面的詞匯。

總結(jié)

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

如果已經(jīng)做了效果不好，不妨對(duì)照一下，看有沒有把 Code Review 作為開發(fā)流程的必選項(xiàng)而不是可選項(xiàng)?有沒有把 Code Review 變成一種開發(fā)文化而不僅僅是一種制度?