來源

程式碼稽核的速度

為什麼程式碼稽核要快？

在谷歌，我們會對一個開發團隊交付產品的速度進行優化，另外一面就是優化獨立開發者的編碼速度。獨立開發者的速度很重要，但是絕對無法與整組的速度相比。
如果程式碼稽核太慢，就會產生下面的影響：

• 整組的效率會降低。當稽核不能快速反饋時，單個開發可以投入其他的工作。然而對於小組來講，新功能或者bug修復可能就會因為程式碼稽核被延遲數天、數週甚至數月。
• 開發者會反對程式碼稽核流程。如果稽核者每次都需要數日才能有反饋，但是要求主要變更每次都要稽核，開發者會感到沮喪和麻煩。大家會認為稽核過程太過“嚴厲”。如果稽核者要求同樣可靠的變更（變更真實的提高了程式碼質量），但是在每次開發者提交更新時都能夠快速
  響應，這樣的抱怨就會消失。大部分關於程式碼稽核流程的抱怨都能夠在加快稽核速度之後切實消除掉。
• 程式碼質量會受到衝擊。當稽核很慢時，會對開發者產生持續增加的壓力，使得他們沒辦法以最好的狀態提交程式碼。緩慢的稽核也會影響程式碼整理、重構和基於現有程式碼的改進的意願熱情。

程式碼稽核應該要多塊？

如果你當前沒有在一項專注的任務中，你就應該在程式碼提交後儘快進行稽核。
針對一次程式碼稽核請求最晚反饋時間不要超過一個工作日。（例如第二天早晨的第一件事）
遵守這些指南的話，意味著一次典型的變更提交應當是會在一天內進行多輪稽核（如果有必要）。

速度與打斷

有時候個人效率是要高於團隊效率的。例如，你正在全身心投入一項需要專注的工作中——比如寫程式碼，這時候不要打斷自己來進行程式碼稽核。研究表明，一旦專注平滑的節奏被打斷，開發者需要花很長時間才能重回這個狀態。所以打斷你個人的編碼節奏對團隊來講，與讓另外一位開發者等待程式碼稽核實際上更昂貴。
你應當選擇一個空檔時間來進行程式碼稽核的工作，比如當前的編碼任務完成，午飯之後，會議結束後，或者一次茶歇之後等等。

快速響應

當我們在討論程式碼稽核的速度時，我們關心的就是響應時間，相對的就是變更提交整體稽核並提交共花費多少時間。整個過程理論上應該要快速，但是快速的獨立反饋比整體的過程速度更加重要。
哪怕有時我們需要花很長的時間來完成整個稽核過程，在過程中能夠從稽核者很快的獲得反饋，就能夠明顯的降低開發者對於“稽核慢”的印象。
如果當有提交時你沒有足夠的時間來做完整的稽核，你可以先回復一下你預計什麼時候會進行稽核，確認其他稽核者是否能夠有時間來響應，或者先提供一些初始的寬泛通用的建議。（注意：這並不意味著你需要中斷你的編碼工作來進行反饋，你仍然應該在空檔時間進行迴應。）
稽核者需要在稽核工作上投入足夠多的時間來確保他們接受提交就意味者“這份程式碼符合我們的標準”。然而儘量保證單個響應速度要快。

跨時區稽核

當存在時區差異的時候，儘量要在他還在辦公室的工作時間內回覆。如果他們已經下班來，儘量在他們第二天上班前完成稽核。

使用評論標誌完成稽核（LGTM¹）

為了提高稽核的速度，會有一些確定的場景應該通過稽核，即使他們在變更提交中備註他們還沒有完成。下面就是這些情況：

• 稽核者確信開發者能夠很好的處理標記出來的所有問題。
• 待處理的內容很小而且不是必須由當前開發者完成。
  稽核者需要明確當前是哪種情況，如果不是那就說明已經處理完畢了。
  評論中說明稽核完成特別值得稽核者與開發者在不同時區的組織考慮，否則開發者可能要等一整天，然後只為了等到一個通過評審的評論。

大型變更提交

如果某人提交過來的變更非常大，大到你沒有足夠的時間能夠稽核，你應當要求開發者將這個提交拆分成幾個更小的提交，而不是一次性稽核一個很大的提交。這個對於稽核者是很有幫助的，雖然可能會增加一些開發者的工作量。
如果說一個大型提交沒辦法拆分成更小的提交，你也沒有足夠的時間來完整稽核完整個提交，至少可以針對提交的整體設計提出一些評論並且反饋給開發者用於改進。作為稽核者的目標之一就是幫助開發者清除障礙或者能夠讓他們放心的改進程式碼，而不用太過擔心程式碼質量。

隨著時間程式碼稽核的改進

Code Review Improvements Over Time {#time}

如果跟隨指南嚴格執行程式碼稽核，你會發現隨著時間變化稽核的速度也會越來越快。開發者也能理解如何提高程式碼質量，變更提交也會比剛開始更好，需要花在稽核上面的時間也越來越少。稽核者也懂得快速響應，並且不需要在稽核過程中加入無意義的延遲。
但是決不要因為考慮到進度原因，在程式碼稽核標準或者質量上妥協 ，事實上在長期的任務執行中，也不會讓事情進行的更快。欲速則不達。

緊急情況

某些緊急情況下，變更提交必須非常快通過完整稽核過程，這時候質量標準可以適當放鬆。然後需要根據《什麼是緊急情況》一文來判定什麼情況是緊急什麼不是。

下一篇：如何寫程式碼稽核評論