Google最佳實踐 – 程式碼審核的速度

• 2019 年 10 月 3 日
• 筆記

來源

程式碼審核的速度

為什麼程式碼審核要快？

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

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

程式碼審核應該要多塊？

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

速度與打斷

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

快速響應

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

跨時區審核

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

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

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

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

大型變更提交

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

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

Code Review Improvements Over Time {#time}

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

緊急情況

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

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