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

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

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

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

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

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

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

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

速度 vs. 中斷

有一段時間温赔，個人的速度比團(tuán)隊(duì)的速度更重要图筹。如果你正在集中精力做一項(xiàng)任務(wù)，比如寫代碼让腹，不要打斷自己去代碼評審远剩。研究表明，在中斷開發(fā)之后骇窍，開發(fā)人員可能需要很長時間才能恢復(fù)到正常的開發(fā)流程瓜晤。因此，對團(tuán)隊(duì)來說腹纳，在編寫代碼時打斷自己的工作實(shí)際上比讓另一個開發(fā)人員等待代碼評審的時間更昂貴痢掠。

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

快速的響應(yīng)

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

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

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

跨時區(qū)Review

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

LGTM的評論

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

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

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

過大的CL

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

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

隨著時間的推移贤惯，代碼評審會得到改進(jìn)

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

緊急情況

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

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