為什么代碼評審應(yīng)該是快速的?

我們優(yōu)化的是開發(fā)團隊共同生產(chǎn)產(chǎn)品的速度，而不是單個開發(fā)人員編寫代碼的速度。個人發(fā)展的速度很重要，只是沒有整個團隊的速度重要。

當代碼評審緩慢時，會發(fā)生以下幾種情況:

• 整個團隊的速度降低了。是的，那些對評審沒有快速反應(yīng)的人，可以完成其他的工作。但是，由于每個CL都要等待評審和重新評審，團隊其他成員的新特性和bug修復(fù)會延遲幾天、幾周或幾個月。
• 開發(fā)人員開始抗議代碼審查過程。如果評審員每隔幾天才回復(fù)一次，但每次都要求對CL進行重大修改，這對開發(fā)人員來說是很困難的。通常情況下，這表現(xiàn)為對評審員的“嚴格”的抱怨。如果評審員要求進行同樣的重大更改(這些更改確實改善了代碼的健康狀況)，但是每次開發(fā)人員進行更新時都能快速做出響應(yīng)，那么抱怨就會消失。對代碼評審過程的大多數(shù)抱怨實際上是通過加快過程來解決的。
• 代碼健康狀況可能會受到影響。當評審緩慢時，就會增加壓力而允許開發(fā)人員提交不太好的CLs。緩慢的評審還會阻礙代碼清理、重構(gòu)和對現(xiàn)有CLs的進一步改進。

代碼評審應(yīng)該多快?

如果你沒有在執(zhí)行一個正在關(guān)注的任務(wù)中，當有Code Reivew請求后應(yīng)該在很短時間內(nèi)進行Code Reivew。

一個工作日是響應(yīng)代碼評審請求(即第二天早上的第一件事)所需要的最長時間。

遵循這些指導原則意味著一個典型的CL應(yīng)該在一天之內(nèi)(如果需要的話)進行多輪評審。

速度 vs. 中斷

有一段時間，個人的速度比團隊的速度更重要。如果你正在集中精力做一項任務(wù)，比如寫代碼，不要打斷自己去代碼評審。研究表明，在中斷開發(fā)之后，開發(fā)人員可能需要很長時間才能恢復(fù)到正常的開發(fā)流程。因此，對團隊來說，在編寫代碼時打斷自己的工作實際上比讓另一個開發(fā)人員等待代碼評審的時間更昂貴。

相反，在你的工作中等待一個斷點，然后你才回應(yīng)一個審查的請求。這可能是當你當前的編碼任務(wù)完成后，午飯后，從會議回來，從茶水間回來，等等

快速的響應(yīng)

當我們討論代碼評審的速度時，我們關(guān)心的是響應(yīng)時間，而不是CL完成整個評審并提交所需的時間。理想情況下，整個過程也應(yīng)該是快速的，但個人快速響應(yīng)比整個過程快速發(fā)生更重要。

即使有時需要很長時間才能完成整個評審過程，在整個過程中得到評審員的快速響應(yīng)可以極大地減輕開發(fā)人員對“緩慢”的代碼評審感到的挫敗感。

當需要你對一個CL進行Review時，你實在太忙了。你仍然可以發(fā)送一個快速反應(yīng),讓開發(fā)人員知道什么時候可以開始Review,或建議其他可以更快地響應(yīng)的評審員,或者提供一些最初的廣泛評論。(注意:這并不意味著您應(yīng)該中斷編碼，即使是為了發(fā)送這樣的響應(yīng)—在您工作中的一個合理的斷點發(fā)送響應(yīng)。)
重要的是評審員要花足夠的時間在評審上，以確保他們的“LGTM”(looks good to me:看起來不錯)是指“這段代碼符合我們的標準”。然而，個人的反應(yīng)仍然應(yīng)該是快速的。

跨時區(qū)Review

處理時區(qū)差異時，試著在作者還在辦公室的時候聯(lián)系他。如果他們已經(jīng)回家了，那么在他們第二天回到辦公室之前，確保你的Review已經(jīng)完成。

LGTM的評論

為了加快代碼審查的速度，在某些情況下，審查員應(yīng)該給予LGTM/通過，即使他們在CL上留下了未解決的注釋。這是在以下情況下完成的:

• 評審員確信開發(fā)人員將適當?shù)靥幚碓u審員的所有剩余評論。
• 其余的變更是次要的，不必由開發(fā)人員完成。
  如果不清楚的話，評審員應(yīng)該指明他們想要的選項。

當開發(fā)人員和評審員在不同的時區(qū)時，LGTM的評論尤其值得考慮，否則開發(fā)人員可能要等一整天才能得到“LGTM，通過”。

過大的CL

如果有人提交給你一個過大的CL，你無法確定有時間去review。你一般要求開發(fā)者將該CL拆分成幾個小的CLs，而不是一個必須一次全部審查的巨大CL。這通常是可行的，并且對評審員非常有幫助，即使它需要開發(fā)人員做額外的工作。

如果一個CL不能分解成更小的CL，并且您沒有時間快速地檢查整個CL，那么至少要對CL的總體設(shè)計寫一些注釋，并將其發(fā)送給開發(fā)人員進行改進。作為審查人員，您的目標之一應(yīng)該是始終解除對開發(fā)人員的阻塞，或使他們能夠迅速采取某種進一步的行動，而不犧牲代碼的健康狀況。

隨著時間的推移，代碼評審會得到改進

如果您遵循這些指導原則，并且對代碼評審非常嚴格，那么您應(yīng)該會發(fā)現(xiàn)，隨著時間的推移，整個代碼評審過程會變得越來越快。開發(fā)人員了解健康的代碼需要什么，并從一開始就向您發(fā)送很棒的CLs，這需要的審查時間越來越少。評審員要學會快速響應(yīng)，不要在評審過程中增加不必要的延遲。但是不要為了提高速度而在Code Review標準或質(zhì)量上妥協(xié)——從長遠來看，這實際上不會使任何事情效率得到提升。

緊急情況

在一些緊急情況下，CLs必須非常快速地通過整個評審過程，并且質(zhì)量方針將會放松。但是，請看看什么是緊急情況?用于描述哪些情況實際上屬于緊急情況，哪些不屬于緊急情況。

下一章：如何編寫代碼評論