代碼審核的速度
為什么代碼審核要快？
在谷歌，我們會(huì)對(duì)一個(gè)開發(fā)團(tuán)隊(duì)交付產(chǎn)品的速度進(jìn)行優(yōu)化，另外一面就是優(yōu)化獨(dú)立開發(fā)者的編碼速度。獨(dú)立開發(fā)者的速度很重要，但是絕對(duì)無法與整組的速度相比。
如果代碼審核太慢，就會(huì)產(chǎn)生下面的影響：
- 整組的效率會(huì)降低。當(dāng)審核不能快速反饋時(shí)，單個(gè)開發(fā)可以投入其他的工作。然而對(duì)于小組來講，新功能或者bug修復(fù)可能就會(huì)因?yàn)榇a審核被延遲數(shù)天、數(shù)周甚至數(shù)月。
- 開發(fā)者會(huì)反對(duì)代碼審核流程。如果審核者每次都需要數(shù)日才能有反饋，但是要求主要變更每次都要審核，開發(fā)者會(huì)感到沮喪和麻煩。大家會(huì)認(rèn)為審核過程太過“嚴(yán)厲”。如果審核者要求同樣可靠的變更（變更真實(shí)的提高了代碼質(zhì)量），但是在每次開發(fā)者提交更新時(shí)都能夠快速響應(yīng)，這樣的抱怨就會(huì)消失。大部分關(guān)于代碼審核流程的抱怨都能夠在加快審核速度之后切實(shí)消除掉。
- 代碼質(zhì)量會(huì)受到?jīng)_擊。當(dāng)審核很慢時(shí)，會(huì)對(duì)開發(fā)者產(chǎn)生持續(xù)增加的壓力，使得他們沒辦法以最好的狀態(tài)提交代碼。緩慢的審核也會(huì)影響代碼整理、重構(gòu)和基于現(xiàn)有代碼的改進(jìn)的意愿熱情。
代碼審核應(yīng)該要多塊？
如果你當(dāng)前沒有在一項(xiàng)專注的任務(wù)中，你就應(yīng)該在代碼提交后盡快進(jìn)行審核。
針對(duì)一次代碼審核請(qǐng)求最晚反饋時(shí)間不要超過一個(gè)工作日。（例如第二天早晨的第一件事）
遵守這些指南的話，意味著一次典型的變更提交應(yīng)當(dāng)是會(huì)在一天內(nèi)進(jìn)行多輪審核（如果有必要）。
速度與打斷
有時(shí)候個(gè)人效率是要高于團(tuán)隊(duì)效率的。例如，你正在全身心投入一項(xiàng)需要專注的工作中——比如寫代碼，這時(shí)候不要打斷自己來進(jìn)行代碼審核。研究表明，一旦專注平滑的節(jié)奏被打斷，開發(fā)者需要花很長(zhǎng)時(shí)間才能重回這個(gè)狀態(tài)。所以打斷你個(gè)人的編碼節(jié)奏對(duì)團(tuán)隊(duì)來講，與讓另外一位開發(fā)者等待代碼審核實(shí)際上更昂貴。
你應(yīng)當(dāng)選擇一個(gè)空檔時(shí)間來進(jìn)行代碼審核的工作，比如當(dāng)前的編碼任務(wù)完成，午飯之后，會(huì)議結(jié)束后，或者一次茶歇之后等等。
快速響應(yīng)
當(dāng)我們?cè)谟懻摯a審核的速度時(shí)，我們關(guān)心的就是響應(yīng)時(shí)間，相對(duì)的就是變更提交整體審核并提交共花費(fèi)多少時(shí)間。整個(gè)過程理論上應(yīng)該要快速，但是快速的獨(dú)立反饋比整體的過程速度更加重要。
哪怕有時(shí)我們需要花很長(zhǎng)的時(shí)間來完成整個(gè)審核過程，在過程中能夠從審核者很快的獲得反饋，就能夠明顯的降低開發(fā)者對(duì)于“審核慢”的印象。
如果當(dāng)有提交時(shí)你沒有足夠的時(shí)間來做完整的審核，你可以先回復(fù)一下你預(yù)計(jì)什么時(shí)候會(huì)進(jìn)行審核，確認(rèn)其他審核者是否能夠有時(shí)間來響應(yīng)，或者先提供一些初始的寬泛通用的建議。（注意：這并不意味著你需要中斷你的編碼工作來進(jìn)行反饋，你仍然應(yīng)該在空檔時(shí)間進(jìn)行回應(yīng)。）
審核者需要在審核工作上投入足夠多的時(shí)間來確保他們接受提交就意味者“這份代碼符合我們的標(biāo)準(zhǔn)”。然而盡量保證單個(gè)響應(yīng)速度要快。
跨時(shí)區(qū)審核
當(dāng)存在時(shí)區(qū)差異的時(shí)候，盡量要在他還在辦公室的工作時(shí)間內(nèi)回復(fù)。如果他們已經(jīng)下班來，盡量在他們第二天上班前完成審核。
使用評(píng)論標(biāo)志完成審核（LGTM[1]）
為了提高審核的速度，會(huì)有一些確定的場(chǎng)景應(yīng)該通過審核，即使他們?cè)谧兏峤恢袀渥⑺麄冞€沒有完成。下面就是這些情況：
- 審核者確信開發(fā)者能夠很好的處理標(biāo)記出來的所有問題。
- 待處理的內(nèi)容很小而且不是必須由當(dāng)前開發(fā)者完成。
審核者需要明確當(dāng)前是哪種情況，如果不是那就說明已經(jīng)處理完畢了。
評(píng)論中說明審核完成特別值得審核者與開發(fā)者在不同時(shí)區(qū)的組織考慮，否則開發(fā)者可能要等一整天，然后只為了等到一個(gè)通過評(píng)審的評(píng)論。
大型變更提交
如果某人提交過來的變更非常大，大到你沒有足夠的時(shí)間能夠?qū)徍?，你?yīng)當(dāng)要求開發(fā)者將這個(gè)提交拆分成幾個(gè)更小的提交，而不是一次性審核一個(gè)很大的提交。這個(gè)對(duì)于審核者是很有幫助的，雖然可能會(huì)增加一些開發(fā)者的工作量。
如果說一個(gè)大型提交沒辦法拆分成更小的提交，你也沒有足夠的時(shí)間來完整審核完整個(gè)提交，至少可以針對(duì)提交的整體設(shè)計(jì)提出一些評(píng)論并且反饋給開發(fā)者用于改進(jìn)。作為審核者的目標(biāo)之一就是幫助開發(fā)者清除障礙或者能夠讓他們放心的改進(jìn)代碼，而不用太過擔(dān)心代碼質(zhì)量。
隨著時(shí)間代碼審核的改進(jìn)
Code Review Improvements Over Time {#time}
如果跟隨指南嚴(yán)格執(zhí)行代碼審核，你會(huì)發(fā)現(xiàn)隨著時(shí)間變化審核的速度也會(huì)越來越快。開發(fā)者也能理解如何提高代碼質(zhì)量，變更提交也會(huì)比剛開始更好，需要花在審核上面的時(shí)間也越來越少。審核者也懂得快速響應(yīng)，并且不需要在審核過程中加入無意義的延遲。
但是決不要因?yàn)榭紤]到進(jìn)度原因，在代碼審核標(biāo)準(zhǔn)或者質(zhì)量上妥協(xié) ，事實(shí)上在長(zhǎng)期的任務(wù)執(zhí)行中，也不會(huì)讓事情進(jìn)行的更快。欲速則不達(dá)。
緊急情況
某些緊急情況下，變更提交必須非?？焱ㄟ^完整審核過程，這時(shí)候質(zhì)量標(biāo)準(zhǔn)可以適當(dāng)放松。然后需要根據(jù)《什么是緊急情況》一文來判定什么情況是緊急什么不是。
下一篇：如何寫代碼審核評(píng)論
-
Git 團(tuán)隊(duì)協(xié)作中常用術(shù)語 WIP PTAL CC LGTM 等解釋
WIP :? Work in progress, do not merge yet. // 開發(fā)中
LGTM : Looks good to me. // Riview 完別人的 PR ，沒有問題
PTAL : Please take a look. // 幫我看下，一般都是請(qǐng)別人 review 自己的 PR
CC : Carbon copy // 一般代表抄送別人的意思
RFC ?:? request for comments. // 我覺得這個(gè)想法很好, 我們來一起討論下
IIRC ?:? if I recall correctly. // 如果我沒記錯(cuò)
ACK ?:? acknowledgement. // 我確認(rèn)了或者我接受了,我承認(rèn)了
NACK/NAK : negative acknowledgement. // 我不同意 ?
