Google 如何進行 Code Review - 4
一窺 Google 內部程式審核的指導原則 - Speed of Code Reviews
文章目錄
在 Google 我們優化開發團隊共同生產產品的速度，而不是優化個人開發程式的速度。
個人的開發速度很重要，但它不如整個團隊的開發速度 (velocity of the entire team) 那般重要。
當程式審核很慢時，會發生以下幾件事:
- 團隊整體的速度下降
是的，沒有快速回應的個人 (individual) 的確完成自己所屬的工作。但同時也表示，對於團隊其他人來說重要的新功能與缺陷修復將會被延遲數天、數週甚至數月，只因為它們正在等待審核與再審核。
- 開發人員開始抗議程式審查流程
若審核者每隔幾天才回應一次，但每次都要求對 CL 進行重大更改的話，那麼開發人員可能會感到非常沮喪與覺得困難，而這通常會演變成對評論者的「嚴格」程度的抱怨。 如果審核者請求相同的實質性更改 (且確實可以改善程式品質狀況)，但在每次開發人員提交新的改動時都能快速反應的話，這些抱怨往往會消失。
大多數關於程式審查過程的抱怨，往往可以通過加快流程來解決。
- 程式品質會受到影響
當審核評論很慢時，會造成開發者提交不完全盡如人意的 CL 的壓力越來越大 [1]。評論的越慢也會阻止他人進行程式清理 (cleanups)、重構 (refactorings)、甚至是對現有 CL 的進一步改進。
- [1] 還記得前面所說的嗎? 沒有完美的程式只有最佳的程式!
如果你並沒有處於需要專注工作 (focused task) 中間時，那麼你應該在 CL 被提交後儘快進行審查。
回應程式審查最長的極限是一個工作日是 (意即隔天早上的第一件事)
若遵循以上指南，意味著一般的 CL 應該在一天內得到多輪審核 (如果必要的話)。
但有時候個人的速度優先度會勝過團隊速度。
如果你處於需要專注工作的中間時 (比方說寫程式)，不要中斷自己去做程式審查
研究證實，若開發者在被打斷後會需要很長時間才能恢復到原本順暢的開發流程。
因此，開發程式時打斷自己實際上會比讓另一位開發者等待審查來得更加昂貴。
取而代之的是，我們可以在投入到處理他人給的審核評論之前，找個適當的時機點來進行程式審核。 這有可能是當你的當前開發任務完成後、午餐、剛從會議脫身或從微型廚房回來等等。
當我們談論程式審查的速度時，我們關注的是回應時間，而非 CL 需要多長時間才能完成整個審核過程並提交。 在理想情況下，整個過程應該是快速的。
總的來說個人回應評論的速度，比起讓整個審核過程快速結束來得更為重要。
即使有時需要很長時間才能完成整個審核流程，但若在整個過程中能快速獲得來自審核者的回應，這將會大大減輕開發人員對於緩慢的程式審核的挫敗感。
如果真的忙到難以抽身而無法對 CL 進行全面審核時，你依然可以快速的回應讓開發者知道你什麼時候會開始審核、建議其他能夠更快回覆的審核人員，又或者提供一些初步的廣泛評論。 (注意: 這並不意味著你應該中斷開發去發送這樣的回應 - 請找到適當的中斷點 (break point) 去做。)
很重要的是，審核人員要花足夠的時間來進行審核，
確保他們給出的「LGTM」意味著「此程式符合我們的標準」。
儘管如此，理想的個人的回應速度還是越快越好。
在面對時區不同的問題時，嘗試在他們還在辦公室時回覆作者。如果他們已經回家了，那麼請確保在他們第二天回到辦公室前完成審核。
為加快審查速度，在某些情況下審閱者可以給予 LGTM 或 Approval，即便 CL 上仍有未解決的評論。 類似情況會發生在:
- 審核者確信開發人員會適當地處理所有剩餘的評論
- 剩餘的評論是微不足道 [1] 的或它們不需由開發者來處理
審核者必須清楚指明他們是指上面哪種情況 [2]。
LGTM 評論對雙方處於不同的時區時尤其值得考慮，否則開發人員會等待一整天才得到 “LGTM，Approval”。
- [1] nitpick
- [2] 要說明是因為 nitpick 不用立刻解決或是留待其他 CL 來處理
改動本身帶來的效益超過因修改導致延遲合併時，不妨告知對方我們用另個 PR 來處理
如果有人要求審查時，但由於改動過於龐大導致你難以確定何時才有時間查看它時，你通常該做的是 要求開發人員將 CL 拆解成多個較小的 CL， 而不是一次審查巨大的 CL。這種事是可能發生的，而且對於審核人員非常有幫助，即便它需要開發人員付出額外心力來處理。
如果 CL 無法分解為較小的 CL，且你沒有足夠時間快速查看整個內容時，那麼至少對它的整體設計寫些評論，並發送回開發人員以便進行改進。
身為審核者，你的目標之一是在不犧牲程式品質的狀況下，避免阻檔 (unblock) 開發人員繼續前進，或讓他們能夠快速採取其他更進一步的動作。
如果你遵循這些準則，並且對於審查非常嚴格的話，你會發現整個程式審核流程會隨著時間的推移而變得越來越快。 因為開發者學到什麼是一個具有品質的程式該具備的內容，並於開頭就提交一個很棒的 CL，而這正恰好只需要越來越少的審核時間。 而審核者則學會快速回應，而非在審核過程中加入不必要的延遲。
但不要為提高想象中的速度 (imagined improvement in velocity)，
而對程式審核標準或品質做出妥協。
畢竟從長遠來看它實際上並不會讓任何事情發生得更快。
在某些緊急情況下，CL 會希望放寬審查標準以求迅速地通過整個審查過程。 但請看文件「什麼樣的緊急情況?」來知道哪些情況實際上屬於緊急情況，而哪些不符合。
下篇: How to Write Code Review Comments
相關文章
- Google 如何進行 Code Review - 6
- Google 如何進行 Code Review - 5
- Google 如何進行 Code Review - 3
- Google 如何進行 Code Review - 2
- Google 如何進行 Code Review - 1
文章內容的轉載、重製、發佈，請註明出處: https://tachingchen.com/tw/
Twitter
Google+
Facebook
Reddit
LinkedIn
StumbleUpon
Pinterest
Email