代碼審查速度
爲什麼代碼審查應該很快？
在Google，我們優化了一組開發人員可以一起生產產品的速度，而不是優化了單個開發人員可以編寫代碼的速度。個人發展的速度很重要，但並不像整個團隊的速度那麼重要。
當代碼審查緩慢時，會發生幾件事：
- 整個團隊的速度下降。是的，對評論沒有快速回應的個人可以完成其他工作。但是，由於每個CL等待審查和重新審查，因此團隊其餘成員的新功能和錯誤修復被延遲了幾天，幾周或幾個月。
- 開發人員開始抗議代碼審查過程。如果審閱者僅每隔幾天回答一次，但是每次都要求對CL進行重大更改，那麼這對於開發人員來說可能會令人沮喪並且困難重重。通常，這表示爲對審閱者的“嚴格”程度的抱怨。如果審閱者要求進行相同的實質性更改（確實可以改善代碼運行狀況的更改），但是每次開發人員進行更新時都做出快速響應，則抱怨往往會消失。實際上，大多數對代碼審查過程的抱怨都可以通過加快過程來解決。
- 代碼的健康狀況可能會受到影響。當審覈緩慢時，允許開發人員提交不盡如人意的CL的壓力就會越來越大。慢速審覈還會阻止代碼清理，重構和對現有CL的進一步改進。
代碼審查應該有多快？
如果您不在一項重點任務的中間，則應在其進入後不久進行代碼審查。
一個工作日是響應代碼檢查請求所需的最長時間（即第二天早上的第一件事）。
遵循這些準則意味着典型的CL應在一天之內進行多輪審覈（如果需要）。
速度與中斷
有一次，個人速度的考慮勝過團隊速度。如果您正在處理諸如編寫代碼之類的重點任務，請不要打擾自己進行代碼檢查。研究表明，開發人員在中斷之後要花很長時間才能恢復到平穩的開發流程。因此，在編寫代碼時打擾自己實際上 對團隊來說要比讓其他開發人員稍等一會兒進行代碼審查更爲昂貴。
而是，在您的工作中遇到一個斷點，然後再響應審閱請求。可能是當您當前的編碼任務完成時，午餐後，從會議中回來，從休息室回來等時。
快速反應
當我們談論代碼審查的速度時，它是我們所關注的響應時間，而不是CL通過整個審查並提交所花的時間。整個過程在理想情況下也應該是快速的，但是對於個人的響應來說，比整個過程迅速發生更爲重要。
即使有時需要很長時間才能完成整個審閱過程，但在整個審閱 過程中獲得審閱者的快速響應仍可以極大地緩解開發人員對“緩慢”代碼審閱的不滿。
如果您忙於在CL上進行全面審覈時，仍然可以發送快速響應，以使開發人員知道何時獲得該反饋，建議其他可能會更快響應的審閱者，或者 提供一些初步的廣泛評論。（注意：這都不意味着您即使發送這樣的響應也不應中斷編碼-在工作中的合理斷點處發送響應。）
重要的是，審閱者應花費足夠的時間進行審閱，以確保他們的“ LGTM”表示“此代碼符合我們的標準”。 但是，理想情況下，個人響應仍然應該很快。
跨時區評論
在處理時區差異時，請嘗試在仍在辦公室時與作者聯繫。如果他們已經回家了，請嘗試確保您的審覈完成，然後他們第二天才回到辦公室。
LGTM帶評論
爲了加速代碼審查，在某些情況下，即使審查員也將未解決的評論留在了CL上，他們仍應給予LGTM /批准。在以下情況之一時完成此操作：
- 審閱者有信心開發人員將適當地解決所有審閱者的其餘評論。
- 剩下的變化是輕微的，不具備由開發商來完成。
除非另有明確說明，否則審閱者應指定他們打算使用這些選項中的哪一個。
當開發人員和審閱者位於不同時區時，帶有註釋的LGTM特別值得考慮，否則，開發人員將等待一整天才獲得“ LGTM，批准”。
大型CL
如果有人向您發送瞭如此大的代碼審查，您不確定何時有時間進行審查，通常的回答是請開發人員 將CL拆分爲多個相互構建的較小的CL，而不必一次審查所有巨大的CL。這通常是可能的，並且對審閱者非常有用，即使它需要開發人員進行其他工作。
如果無法將一個CL 分解爲較小的CL，並且您沒有時間快速查看整個內容，則至少要對CL的總體設計寫一些評論，然後將其發回給開發人員進行改進。作爲審閱者，您的目標之一應該是始終解除開發人員的封鎖或使他們能夠迅速採取進一步的措施，而又不犧牲代碼的運行狀況。
隨着時間的推移，代碼審查的改進
如果您遵循這些準則，並且嚴格執行代碼審查，則應該發現整個代碼審查過程隨着時間的流逝會越來越快。開發人員將瞭解健康代碼的要求，並從一開始就向您發送出色的CL，所需的審查時間越來越少。審閱者學會快速做出響應，並且不會在審閱過程中增加不必要的延遲。但是，不要在代碼審查標準或質量上做出讓步，以提高速度，這是可以想象的 —從長遠來看，這實際上不會使任何事情更快地發生。
緊急情況
在某些緊急情況下，CL必須非常快速地通過 整個審覈過程，並且放寬質量準則。但是，請參閱什麼是緊急情況？描述哪些情況實際上屬於緊急情況，哪些情況不屬於緊急情況。
參考
https://google.github.io/eng-practices/review/reviewer/speed.html