軟件交付智能平臺(tái) LinearB 的數(shù)據(jù)科學(xué)團(tuán)隊(duì)研究了來(lái)自 2.6 萬(wàn)名開發(fā)者的 73.3 萬(wàn)個(gè) PR 和 390 萬(wàn)條評(píng)論，發(fā)現(xiàn)：

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

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

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

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

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

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

導(dǎo)致團(tuán)隊(duì)承諾無(wú)法兌現(xiàn)。

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

IceSentry：

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

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

grauenwolf：

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

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

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

8BitSk8r：

請(qǐng)告訴我的同事這個(gè)​​。他們認(rèn)為“agile”意味著“we don't plan we just react”。

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

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

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

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

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

本文轉(zhuǎn)自O(shè)SCHINA

本文標(biāo)題：PR 閑置時(shí)間太長(zhǎng)?審查 PR 與創(chuàng)建 PR 同樣重要

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