review的目的
有和沒有之間的態(tài)度差別
很簡(jiǎn)單涩澡，一段代碼完成之后蹋砚，有人看和沒有人看粉寞，在質(zhì)量上還是會(huì)有差別的昌执。
當(dāng)你知道你的代碼會(huì)被人一行一行review時(shí)烛亦，你的代碼一定為努力寫的最好，而不是為了完成功能而應(yīng)付了事仙蚜，這就是態(tài)度上的區(qū)分此洲。因?yàn)楫?dāng)你知道你寫的代碼是有人看的，你會(huì)更加在意你寫的東西委粉，你一定不想背后被人說呜师，代碼寫的像一坨**。
而且確實(shí)我自己在review代碼時(shí)贾节，就能看出哪些為了趕上線而寫的就和平常寫的會(huì)有差別汁汗。
什么是代碼review衷畦？
其實(shí)就是代碼再次查看評(píng)審。
什么時(shí)間該去Review知牌？
在我們每一個(gè)小的版本迭代完后祈争，就去Review代碼。
怎樣對(duì)代碼進(jìn)行Review角寸？
下面是每次提交代碼之前菩混，可以參考的一份Review代碼的清單，事實(shí)證明這樣做可以提高代碼的質(zhì)量和功能的穩(wěn)定性扁藕。
代碼的可讀沮峡，可維護(hù)
代碼的可讀和可維護(hù)在大團(tuán)隊(duì)很關(guān)鍵，最初我們代碼審核為什么嚴(yán)格到令人發(fā)指亿柑，就是因?yàn)榭勺x性和可維護(hù)性邢疙。
嚴(yán)格的code review可以感覺整個(gè)團(tuán)隊(duì)寫出的代碼就像是一個(gè)人寫的。這樣就是為了能讓你隨時(shí)切換到其他業(yè)務(wù)上望薄，而且不需要什么適應(yīng)時(shí)間疟游。
可讀性和可維護(hù)對(duì)于大型的多人合作系統(tǒng)，可以說非常關(guān)鍵痕支，當(dāng)一個(gè)團(tuán)隊(duì)30多人在一個(gè)單頁面開發(fā)時(shí)颁虐，如果風(fēng)格各異，代碼僅僅符合功能和測(cè)試要求的話采转，你會(huì)發(fā)現(xiàn)多人開發(fā)的成本和新需求的升級(jí)的成本會(huì)越來越高聪廉。
舉個(gè)常見的例子：
如果某個(gè)業(yè)務(wù)突然需要提高進(jìn)度瞬痘，這時(shí)的辦法就是加人力故慈，但是如果代碼風(fēng)格各異，加入的人力適應(yīng)時(shí)間和學(xué)習(xí)成本是極高的框全，有時(shí)甚至不如保持原有人力去加班hold察绷。要不就只能找些技術(shù)很強(qiáng)，可以無障礙學(xué)習(xí)的資深工程師江湖救急津辩。
我們這邊其實(shí)就是會(huì)出現(xiàn)上面項(xiàng)目突然加急的情況拆撼，但是，因?yàn)橛衏ode review喘沿，所以我們多人合作時(shí)闸度，基本上可以保證1+1≈2的效率。為什么這么任性蚜印，就是因?yàn)樵赾ode review時(shí)已經(jīng)控制了大家的寫法和模式莺禁，讓新加入的同學(xué)能夠馬上看懂以前邏輯并且做大概的業(yè)務(wù)了解就能上手了。
我這邊最近就經(jīng)歷了這些窄赋，因?yàn)樾枰€一些歷史遺留的技術(shù)債務(wù)哟冬，所以我需要調(diào)整底層的一些代碼結(jié)構(gòu)楼熄，這時(shí)保證功能和互相調(diào)用ok的情況下切換代碼位置和路徑就是我遇到的最大的障礙。
不過由于之前業(yè)務(wù)代碼的高質(zhì)量和開發(fā)模式基本上完全一致浩峡，所以我能很快找到統(tǒng)一的切入點(diǎn)可岂，預(yù)先就能預(yù)估好可能會(huì)踩的坑。
如果沒有code review之前嚴(yán)格的約束翰灾，我基本上需要每個(gè)業(yè)務(wù)功能去分析了缕粹，效率降到極低。
對(duì)于新人纸淮，快速引導(dǎo)致开，快速反饋
對(duì)于新人加入我們的團(tuán)隊(duì)，最快的上手方式就是萎馅，簡(jiǎn)單熟悉完之后双戳，接手一個(gè)業(yè)務(wù)項(xiàng)目，然后我們會(huì)通過不斷的code review給與開發(fā)方式糜芳，編碼習(xí)慣飒货，設(shè)計(jì)模式之間的反饋。
第一個(gè)項(xiàng)目的review 基本上會(huì)是最嚴(yán)格的峭竣。
其實(shí)對(duì)于技術(shù)人員塘辅，code review 就是用代碼在做溝通。
及時(shí)發(fā)現(xiàn)非代碼上的問題
有時(shí)我在review代碼時(shí)會(huì)發(fā)現(xiàn)皆撩，有些地方經(jīng)常在反復(fù)修改扣墩，或者有時(shí)實(shí)現(xiàn)會(huì)非常別扭。這時(shí)我就會(huì)問開發(fā)人員扛吞，是不是需求不明確導(dǎo)致的呻惕，是不是對(duì)需求的理由有偏差。
因?yàn)閷?duì)于正在開發(fā)的同學(xué)滥比，經(jīng)常會(huì)陷入到業(yè)務(wù)具體的實(shí)現(xiàn)中亚脆，有時(shí)就是饒了很大的圈子但是自己確不知道。這時(shí)review時(shí)是能感覺到的盲泛，而且我也成功的多次阻止過濒持。
對(duì)于效率的影響
很很多團(tuán)隊(duì)拒絕code review 主要是基于時(shí)間不允許，項(xiàng)目追的太緊之類的寺滚。
不過因?yàn)槲乙步?jīng)歷過沒有code review的開發(fā)方式柑营，我的感受是code review的影響不會(huì)有大家想的那么嚴(yán)重。
這里關(guān)鍵是具體如何去做
舉例：
在開發(fā)一個(gè)新模塊時(shí)村视，由于對(duì)于業(yè)務(wù)的開發(fā)模式不熟悉官套，上來就直接把功能什么的，需求什么的都搞定了。洋洋灑灑幾千行代碼的產(chǎn)出虏杰。最后需要提交時(shí)讥蟆，review的人發(fā)現(xiàn)，我靠纺阔。瘸彤。。這種實(shí)現(xiàn)不是我需要的笛钝，以后會(huì)埋很多坑啊质况。這時(shí)怎么辦，重構(gòu)玻靡？時(shí)間夠嗎结榄，還是就這樣了，把坑留給二期囤捻？
我們要求的code review不是上面那種臼朗，我們要求每次提交的內(nèi)容盡量少，完成一個(gè)小的功能點(diǎn)就可以提交蝎土。這樣review的人看起來也會(huì)越快视哑，反饋的時(shí)間也會(huì)約迅速。
例如誊涯，完成目錄結(jié)構(gòu)和框架就可以提交一版挡毅，這時(shí)可以review文件名字起的是否合理之類的。
在每次提交代碼的時(shí)間上暴构，我們也是期望每天都會(huì)有提交跪呈，最長(zhǎng)也不要超過3天，不然最后提交的代碼對(duì)于review的人也是負(fù)擔(dān)取逾，出現(xiàn)的問題也不一定來得及修復(fù)耗绿。如果長(zhǎng)期這樣，確實(shí)是會(huì)影響到開發(fā)效率菌赖。
其實(shí)合理的code review即不用浪費(fèi)很多時(shí)間缭乘，而且問題都能快速暴露沐序，快速修復(fù)琉用。代碼始終都能在保證在一個(gè)正確的方向上。
