本文轉(zhuǎn)載自：http://t.cn/AilixZCc
我一直認(rèn)為Code Review（代碼審查）是軟件開發(fā)中的最佳實(shí)踐之一，可以有效提高整體代碼質(zhì)量，及時(shí)發(fā)現(xiàn)代碼中可能存在的問題强法。包括像Google、微軟這些公司，Code Review都是基本要求楣导，代碼合并之前必須要有人審查通過才行废境。
然而對于我觀察到的大部分軟件開發(fā)團(tuán)隊(duì)來說，認(rèn)真做Code Review的很少筒繁，有的流于形式噩凹，有的可能根本就沒有Code Review的環(huán)節(jié)，代碼質(zhì)量只依賴于事后的測試毡咏。也有些團(tuán)隊(duì)想做好代碼審查驮宴，但不知道怎么做比較好。
網(wǎng)上關(guān)于如何做Code Review的文章已經(jīng)有很多了呕缭，這里我結(jié)合自己的一些經(jīng)驗(yàn)堵泽，也總結(jié)整理了一下Code Review的最佳實(shí)踐修己，希望能對大家做好Code Review有所幫助。
Code Review有什么好處迎罗？
很多團(tuán)隊(duì)或個(gè)人不做Code Review睬愤，根源還是不覺得這是一件有意義的事情，不覺得有什么好處纹安。這個(gè)問題要從幾個(gè)角度來看尤辱。
- 首先是團(tuán)隊(duì)知識共享的角度
一個(gè)開發(fā)團(tuán)隊(duì)中，水平有高有低厢岂，每個(gè)人側(cè)重的領(lǐng)域也有不同光督。怎么讓高水平的幫助新人成長？怎么讓大家都對自己側(cè)重領(lǐng)域之外的知識保持了解塔粒？怎么能有人離職后其他人能快速接手结借？這些都是團(tuán)隊(duì)管理者關(guān)心的問題。
而代碼審查窗怒，就是一個(gè)很好的知識共享的方式映跟。通過代碼審查，高手可以直接指出新手代碼中的問題扬虚，新手可以馬上從高手的反饋中學(xué)習(xí)到好的實(shí)踐努隙，得到更快的成長；通過代碼審查辜昵，前端也可以去學(xué)習(xí)后端的代碼荸镊，做功能模塊A的可以去了解功能模塊B的。
可能有些高手覺得給新手代碼審查浪費(fèi)時(shí)間堪置，自己也沒收獲躬存。其實(shí)不然，新人成長了舀锨，就可以更多的幫高手分擔(dān)繁重的任務(wù)岭洲；代碼審查中花時(shí)間，就少一些幫新人填坑擦屁股的時(shí)間坎匿；良好的溝通能力盾剩、發(fā)現(xiàn)問題的能力、幫助其他人成長替蔬，都是技術(shù)轉(zhuǎn)管理或技術(shù)上更上一層樓必不可少的能力告私，而通過代碼審查可以有效的去練習(xí)這些方面的能力。
- 然后是代碼質(zhì)量的角度
現(xiàn)實(shí)中的項(xiàng)目總是人手缺進(jìn)度緊承桥，所以被壓縮的往往就是自動化測試和代碼審查驻粟，結(jié)果影響代碼質(zhì)量，欠下技術(shù)債務(wù)凶异，最后還是要加倍償還蜀撑。
也有人寄希望于開發(fā)后的人工測試挤巡，然而對于代碼質(zhì)量來說，很多問題通過測試是測試不出來的屯掖，只能通過代碼審查玄柏。比如說代碼的可讀性可維護(hù)性，比如代碼的結(jié)構(gòu)贴铜，比如一些特定條件才觸發(fā)的死循環(huán)粪摘、邏輯算法錯(cuò)誤，還有一些安全上的漏洞也更容易通過代碼審查發(fā)現(xiàn)和預(yù)防绍坝。
也有人覺得自己水平高就不需要代碼審查了徘意。對于高手來說，讓別人審查自己的代碼轩褐，可以讓其他人學(xué)習(xí)到好的實(shí)踐椎咧；在讓其他人審查的同時(shí)，在給別人說明自己代碼的時(shí)候把介，也等于自己對自己的代碼進(jìn)行了一次審查勤讽。這其實(shí)就跟我們上學(xué)時(shí)做數(shù)學(xué)題一樣，真正能拿高分的往往是那些做完后還會認(rèn)真檢查的拗踢。
- 還有團(tuán)隊(duì)規(guī)范的角度
每個(gè)團(tuán)隊(duì)都有自己的代碼規(guī)范脚牍，有自己的基于架構(gòu)設(shè)計(jì)的開發(fā)規(guī)范，然而時(shí)間一長巢墅，就會發(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ī)范也會慢慢的形同虛設(shè)叉庐。
通過代碼審查，就可以及時(shí)的去發(fā)現(xiàn)和糾正這些問題会喝，保證團(tuán)隊(duì)規(guī)范的執(zhí)行陡叠。
關(guān)于代碼審查的好處，還有很多好乐，也不一一列舉。還是希望能認(rèn)識到Code Review和寫自動化測試一樣瓦宜，都是屬于磨刀不誤砍柴工的工作蔚万，在上面投入一點(diǎn)點(diǎn)時(shí)間，未來會收獲代碼質(zhì)量临庇，會節(jié)約整體的開發(fā)時(shí)間反璃。
該怎么做昵慌？
現(xiàn)在很多人都已經(jīng)有意識到Code Review的重要性了，只是苦于不知道如何去實(shí)踐淮蜈，不知道怎么樣算是好的Code Review實(shí)踐斋攀。
把Code Review作為開發(fā)流程的必選項(xiàng)而不是可選項(xiàng)
在很早以前，我就嘗試過將代碼審查作為代碼流程的一部分梧田，但只是一個(gè)可選項(xiàng)淳蔼，沒有Code Review也可以把代碼合并到master。這樣的結(jié)果就是想起來才會去做Code Review裁眯，去檢查的時(shí)候已經(jīng)有了太多的代碼變更鹉梨，審查起來非常困難，另外就算審查出問題穿稳，也很難得以修改存皂。
我們現(xiàn)在對代碼的審查則是作為開發(fā)流程的一個(gè)必選項(xiàng)，每次開發(fā)新功能或者修復(fù)Bug逢艘，開一個(gè)新的分支旦袋，分支要合并到master有兩個(gè)必要條件：
- 所有的自動化測試通過
- 有至少一個(gè)人Code Review通過，如果是新手的PR它改，還必須有資深程序員Code Review通過
圖片來源：How to Do Code Reviews Like a Human
這樣把Code Review作為開發(fā)流程的一個(gè)必選項(xiàng)后疤孕，就很好的保證了代碼在合并之前有過Code Review。而且這樣合并前要求代碼審查的流程搔课，好處也很明顯：
- 由于每一次合并前都要做代碼審查胰柑，這樣一般一次審查的代碼量也不會太大，對于審查者來說壓力也不會太大
- 如果在Code Review時(shí)發(fā)現(xiàn)問題爬泥，被審查者希望代碼能盡快合并柬讨，也會積極的對審查出來的問題進(jìn)行修改，不至于對審查結(jié)果太過抵觸
如果你覺得Code Review難以推行袍啡，不妨先嘗試著把Code Review變成你開發(fā)流程的一個(gè)必選項(xiàng)踩官。
把Code Review變成一種開發(fā)文化而不僅僅是一種制度
把Code Review 作為開發(fā)流程的必選項(xiàng)后，不代表Code Review這件事就可以執(zhí)行的很好境输，因?yàn)镃ode Review 的執(zhí)行蔗牡，很大部分程度上依賴于審查者的認(rèn)真審查，以及被審查者的積極配合嗅剖，兩者缺一不可辩越！
如果僅僅只是當(dāng)作一個(gè)流程制度，那么就可能會流于形式信粮。最終結(jié)果就是看起來有Code Review黔攒，但沒有人認(rèn)真審查，隨便看下就通過了，或者發(fā)現(xiàn)問題也不愿意修改督惰。
真要把Code Review這件事做好不傅，必須讓Code Review變成團(tuán)隊(duì)的一種文化，開發(fā)人員從心底接受這件事赏胚，并認(rèn)真執(zhí)行這件事访娶。
要形成這樣的文化，不那么容易觉阅，也沒有想象的那么難崖疤，比如這些方面可以參考：
- 首先，得讓開發(fā)人員認(rèn)識到Code Review這件事為自己留拾、為團(tuán)隊(duì)帶來的好處
- 然后戳晌，得要有幾個(gè)人做好表率作用，榜樣的力量很重要
- 還有痴柔，對于管理者來說沦偎，你激勵(lì)什么，往往就會得到什么
- 最后咳蔚，像寫自動化測試一樣豪嚎，把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í)會存在一些緊急情況掷倔，比如說線上故障補(bǔ)丁，而又沒有其他人在線个绍，那么這種情況下勒葱，最好是在任務(wù)管理系統(tǒng)中，創(chuàng)建一個(gè)Ticket巴柿，用來后續(xù)跟蹤凛虽，確保后續(xù)補(bǔ)上Code Review，并對Code Review結(jié)果有后續(xù)的代碼更新广恢。
先設(shè)計(jì)再編碼
有些新人發(fā)現(xiàn)自己的代碼提交PR（Pull Request）后凯旋，會收到一堆的Code Review意見，必須要做大量的改動钉迷。這多半是因?yàn)樵陂_始做之前至非，沒有做好設(shè)計(jì)，做出來后才發(fā)現(xiàn)問題很多糠聪。
建議在做一個(gè)新功能之前荒椭，寫一個(gè)簡單的設(shè)計(jì)文檔，表達(dá)清楚自己的設(shè)計(jì)思路舰蟆，找資深的先幫你做一下設(shè)計(jì)的審查趣惠，發(fā)現(xiàn)設(shè)計(jì)上的問題。設(shè)計(jì)上沒問題了身害，再著手開發(fā)味悄，那么到Review的時(shí)候，相對問題就會少很多题造。
代碼在提交CODE REVIEW之前傍菇，作者要自己先REVIEW和測試一遍
我在做代碼審查的時(shí)候，有時(shí)候會發(fā)現(xiàn)一些非常明顯的問題界赔，有些甚至自己都沒有測試過丢习，就等著別人Code Review和測試幫助發(fā)現(xiàn)問題。這種依賴心理無論是對自己還是對團(tuán)隊(duì)都是很不負(fù)責(zé)任的淮悼。
一個(gè)好的開發(fā)人員咐低，代碼在提交Code Review之前，肯定是要自己先Review一遍袜腥，把該寫的自動化測試代碼寫上见擦，自己把基本的測試用例跑一遍的钉汗。
我對于團(tuán)隊(duì)提交的PR，有個(gè)要求就是要在PR的描述中增加截圖或者錄屏鲤屡，就是為了通過截圖或者錄屏损痰，確保提交PR的人自己是先測試過的。這也是一個(gè)有效的輔助手段酒来。
PR要小
在做Code Review的時(shí)候卢未，如果有大量的文件修改，那么Review起來是很困難的堰汉，但如果PR比較小辽社，相對就比較容易Review，也容易發(fā)現(xiàn)代碼中可能存在的問題翘鸭。
所以在提交PR時(shí)滴铅，PR要小，如果是比較大的改動就乓，那么最好分批提交汉匙，以減輕審查者的壓力。
對評論進(jìn)行分級
在做Code Review時(shí)生蚁，需要針對審查出有問題的代碼行添加評論盹兢，如果只是評論，有時(shí)候?qū)τ诒粚彶檎弑容^難甄別評論所代表的含義守伸，是不是必須要修改绎秒。
建議可以對Review的評論進(jìn)行分級，不同級別的結(jié)果可以打上不同的Tag尼摹，比如說：
- [optional]：在評論前面加上一個(gè)[optional]標(biāo)記见芹，表示這個(gè)代碼行的問題可改可不改
- [question]：在評論前面加上一個(gè)[question]標(biāo)記，表示對這個(gè)代碼行不理解蠢涝，有問題需要問玄呛，被審查者需要針對問題進(jìn)行回復(fù)澄清
類似這樣的分級可以幫助被審查者直觀了解Review結(jié)果，提高Review效率和二。
評論要友好徘铝，避免負(fù)面詞匯；有說不清楚的問題當(dāng)面溝通
雖然評論是主要的Code Review溝通方式惯吕，但也不要過于依賴惕它，有時(shí)候面對面的溝通效率更高，也容易消除誤解废登。
另外文明用語淹魄，不要用一些負(fù)面的詞匯。
總結(jié)
Code Review是一種非常好的開發(fā)實(shí)踐堡距，如果你還沒開始甲锡，不妨逐步實(shí)踐起來兆蕉；如果已經(jīng)做了效果不好，不妨對照一下缤沦，看有沒有把Code Review作為開發(fā)流程的必選項(xiàng)而不是可選項(xiàng)虎韵？有沒有把Code Review變成一種開發(fā)文化而不僅僅是一種制度？
