我今天所參與的大多數項目都有相當嚴格的代碼審查政策。我的工作需要對我們大多數代碼進行代碼審查，隨著我們為夏季招募了一大批實習生，我負責審查大量代碼。此外，大約五個月前，我所開發的項目採用了官方的預提交審查政策。我必須坦白：我討厭強制性的代碼審查。
我應該明確表示，我仍然相信代碼審查是開發者在項目中協作的有用工具。審查者會標記出你在自己工作時放過的壞風格、不高效或醜陋的代碼。審查者在審查代碼時不會帶有你對其應該如何工作的假設，並且通常能夠發現你因為混淆了意圖的心理模型與實際編寫的代碼而犯的錯誤。
此外，代碼審查是一種確保至少兩個人熟悉你基礎設施中每一部分的好方法。不同的開發者通常會自然地對特定的代碼或基礎設施負責，並且成為唯一接觸或維護它的人。但當他們度假時，代碼壞了，其他人就不得不試圖弄清楚這段代碼本來應該如何運作。強制性的代碼審查政策通常是一種很好的方法來減輕這類問題。
但是，撇開代碼審查的理論和觀察到的好處，從個人角度來看，作為開發者和審查者，我發現這是一個非常令人沮喪的過程。
作為作者#
作為開發者，我討厭代碼審查為我的開發工作流程增加不可預測的長延遲。一旦我完成並測試了一個功能，並將其發送進行代碼審查，我必須等待一段潛在的長時間才能真正標記它為完成。這意味著，在決定下一步該做什麼時，我基本上有三個選擇：
- 忙等。喝咖啡，閱讀 reddit，檢查我的郵件，直到審查請求回來。
- 在我剛發送進行代碼審查的代碼上繼續開發。
- 做一些完全不同的事情。
這三個選擇都很糟糕。(1) 如果我可以預期審查很快回來，那麼這是方便的，因為做一些閒置的事情，比如閱讀 reddit 或檢查郵件，可以讓我將代碼放在腦海中，這樣當審查回應回來時，我不必重新回想起來。但顯然這是低效的，浪費時間，如果我不期望在最多一小時內收到回覆，那就是不可接受的。
(2) 通常是我想做的事情。我經常在一個項目中工作，這些項目有幾個邏輯上不同但相關的階段。對於每個階段發送審查請求通常是有意義的，因為它們可以單獨部署和審查。
然而，如果審查者對我發送的代碼提出了重大意見，我現在不僅需要更新該代碼，還需要將自那時以來我所做的工作重新基於結果上，這可能會很麻煩，尤其是當我正在處理某些密切相關的事情時（例如，如果我的工作使用了我之前構建的 API，而審查者以某種方式要求對這些 API 進行更改）。
選擇 (3) 避免了這兩個問題，但意味著我不斷在不同的項目之間切換焦點。這減慢了我的速度，因為我必須不斷重新記住我在每個項目中的進度，我使用了哪些 API，等等。任何開發者都可以告訴你，他們也討厭過於頻繁地在不同項目之間切換。
選擇 (3) 在大型項目中可能更可容忍，因為開發 / 審查週期通常是幾周。但這些並不是我正在處理的項目。
作為審查者#
審查代碼是我如果有無限時間會享受的事情之一，但在我沒有的時候卻覺得很麻煩。我確實喜歡閱讀其他人的代碼，並找出如何改進它，並給予反饋以幫助達到那個目標。
但做好這一點需要很多時間，而我這些日子很少有這麼多時間。此外，因為我對作為開發者處理代碼審查的上述抱怨，我總是敏銳地意識到可能有人在等待我的回覆以便完成工作。因此，我總是感到急於回覆代碼審查請求。
所以，即使我總覺得代碼審查應該是我享受的事情，我卻往往發現這是一個令人沮喪的經歷，感覺就像是一個我必須完成的任務，才能回到真正的工作中。
這當然在某種程度上只是忙碌的症狀，但代碼審查使這成為一項比其他時間消耗更讓我困擾的任務。如果客戶報告了一個我必須放下所有去調查的關鍵錯誤，我會感到煩惱，但至少我覺得我在做一些重要的事情，修復一個真正的問題，並希望能讓客戶滿意。如果我花一天時間只閱讀代碼審查，我會感到不滿和無所事事。因為代碼審查在根本上感覺是可選的 —— 儘管我相信它是有益的，但這是我們選擇去做的事情，而不是為了項目或業務繼續運作而必須做的事情 —— 因此發現自己花了大量時間在這上面會更加令人沮喪。
總結#
我相信代碼審查是一個強大的工具。但在實踐中，我發現與之合作令人沮喪。我想聽聽你的想法：代碼審查對你有用嗎？在某些方面我做錯了嗎？這只是改變我某種態度的問題嗎？
我知道有很多關於如何有效進行代碼審查的文章。如果你發現了特別有說服力的指導，請告訴我。