軟件交付智能平臺 LinearB 的數(shù)據(jù)科學團隊研究了來自 2.6 萬名開發(fā)者的 73.3 萬個 PR 和 390 萬條評論，發(fā)現(xiàn)：

• 50% 的 PR 在其生命周期的 50.4% 的時間里處于閑置狀態(tài) ;
• 33% 的 PR 在其生命周期中閑置了 77.8%(高達)的時間;
• 參與調(diào)查的開發(fā)人員的平均周期時間為 6 天 + 5 小時;
• 這些開發(fā)人員的平均 PR 審查時間為 4 天 + 7 小時。

對此，LinearB 的 COO 兼聯(lián)合創(chuàng)始人 Dan Lines 則認為，PR 過程中的閑置時間就是開發(fā)者流程中的一個 killer。并表示，PR 悖論給自己和團隊帶來了很大的困擾。根據(jù)解釋，所謂 PR 悖論(Pull Request Paradox)就是：我剛剛寫了一些代碼，可以對我們的客戶產(chǎn)生積極的影響，我有動力盡快發(fā)布它。我需要你的幫助，但你卻很忙，而且有動力繼續(xù)寫你自己的代碼。這種沖突就是 PR 悖論。

Dan 稱，研究所得的數(shù)據(jù)意味著：

• 每塊工作平均有兩天的閑置時間，造成了生產(chǎn)力浪費。

此舉損害了開發(fā)團隊合并和發(fā)布代碼的能力，從而阻止價值交付。

閑置的時間會導致情景意識的降低、代碼質(zhì)量的降低和努力的浪費。“在我們打開一個新的 PR 之后，每過一個小時，重新審視我們的代碼的認知負荷就會增加。如果我在一兩天后收到問題或修改請求，就很難再回到我原來的流程狀態(tài)。閑置時間損害了質(zhì)量，因為當生產(chǎn)中出現(xiàn)我?guī)滋旎驇字芮皩懙拇a的問題時，就更難調(diào)試了。”

導致團隊承諾無法兌現(xiàn)。

不過 Dan 的觀點也遭到了一些網(wǎng)友的反駁，以下是 Reddit 上網(wǎng)友討論中的一些高贊回答：

IceSentry：

文章中提到，在任務之間很難找到時間進行 quick review。這就是你的問題所在。審查 PR 應該是一項與創(chuàng)建 PR 同樣重要的任務。如果有公開的 PR，就不要開始工作。開始在一個新問題上工作只會使一切變得更糟，并使你的團隊更加緩慢。

顯然，要鼓勵提交小的 PR;如果是大的 PR，則至少要盡量把它分成明確的提交。

grauenwolf：

審查 PR 應該是一項與創(chuàng)建 PR 同樣重要的任務。

大眾需要理解這一點。高質(zhì)量的代碼并不 cheap，尤其是在為項目定義設計模式的初期。

如果你在這一步上偷懶，你的代碼將很快變得雜亂無章(big ball of mud)。

8BitSk8r：

請告訴我的同事這個​​。他們認為“agile”意味著“we don't plan we just react”。

此外，Dan 還在文章中列舉了一些 PR 的替代方案。首先是"真正的"持續(xù)集成?，F(xiàn)在很流行的一種說法是，CI 和 PR 是相互排斥的?；谥鞲傻拈_發(fā)允許開發(fā)人員直接提交到主分支，而不需要任何形式的審查或合并過程。但 Dan 認為，這種方法可能只適用于最精英的團隊;對 95% 的人來說，它的缺點要大于優(yōu)點。

其次是有人提出了一種 Ship / Show / Ask 策略：這是一種分支策略，它結(jié)合了 PR 的功能和保持發(fā)送變更的能力。Changes 被歸類為"Ship"(不經(jīng)審查合并到主線)、"Show"(打開 PR 進行審查，但立即合并到主線)或 "Ask"(在合并之前打開 PR 進行討論)?？偟膩碚f，此策略對于低風險的工作，選擇直接合并而不審查或事后審查是有一定道理的。但是 Dan 指出它也存在一個問題，即目前大多數(shù)團隊都沒有適當?shù)亩x、流程和自動化來使其發(fā)揮作用。

此外還有結(jié)對編程(Pair programming)，不過這一方法好像也不盡適用。“我知道很多開發(fā)團隊使用結(jié)對來補充異步拉取請求審查，而我個人從未在一個使用結(jié)對來取代 PR 的團隊工作過。”

Dan 表示，他不認為 PR 會消失。“根據(jù)我的經(jīng)驗，在合并之前讓隊友審查你的代碼是提高質(zhì)量和減少錯誤的最好、最實惠的方法。PR 在捕捉可維護性錯誤方面特別有效，而這些錯誤是很難通過自動測試發(fā)現(xiàn)的”。且很多開發(fā)人員都同意 PR 是提高學習和教學質(zhì)量的好工具。

而 LinearB 團隊也針對 PR 悖論推出了一個相關的提升 PR 審查效率的方案，并表示已收獲了積極地反饋。詳情可查看文章。

本文轉(zhuǎn)自OSCHINA

本文標題：PR 閑置時間太長?審查 PR 與創(chuàng)建 PR 同樣重要

本文地址：https://www.oschina.net/news/176589/pull-request-review