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