PR 閑置時間太長？審查 PR 與創建 PR 同樣重要
軟件交付智能平臺 LinearB 的數據科學團隊研究了來自 2.6 萬名開發者的 73.3 萬個 PR 和 390 萬條評論，發現：
- 50% 的 PR 在其生命周期的 50.4% 的時間里處于閑置狀態 ;
- 33% 的 PR 在其生命周期中閑置了 77.8%(高達)的時間;
- 參與調查的開發人員的平均周期時間為 6 天 + 5 小時;
- 這些開發人員的平均 PR 審查時間為 4 天 + 7 小時。
對此，LinearB 的 COO 兼聯合創始人 Dan Lines 則認為，PR 過程中的閑置時間就是開發者流程中的一個 killer。并表示，PR 悖論給自己和團隊帶來了很大的困擾。根據解釋，所謂 PR 悖論(Pull Request Paradox)就是：我剛剛寫了一些代碼，可以對我們的客戶產生積極的影響，我有動力盡快發布它。我需要你的幫助，但你卻很忙，而且有動力繼續寫你自己的代碼。這種沖突就是 PR 悖論。
Dan 稱，研究所得的數據意味著：
- 每塊工作平均有兩天的閑置時間，造成了生產力浪費。
此舉損害了開發團隊合并和發布代碼的能力，從而阻止價值交付。
閑置的時間會導致情景意識的降低、代碼質量的降低和努力的浪費。“在我們打開一個新的 PR 之后，每過一個小時，重新審視我們的代碼的認知負荷就會增加。如果我在一兩天后收到問題或修改請求，就很難再回到我原來的流程狀態。閑置時間損害了質量，因為當生產中出現我幾天或幾周前寫的代碼的問題時，就更難調試了。”
導致團隊承諾無法兌現。
不過 Dan 的觀點也遭到了一些網友的反駁，以下是 Reddit 上網友討論中的一些高贊回答：
IceSentry：
文章中提到，在任務之間很難找到時間進行 quick review。這就是你的問題所在。審查 PR 應該是一項與創建 PR 同樣重要的任務。如果有公開的 PR，就不要開始工作。開始在一個新問題上工作只會使一切變得更糟，并使你的團隊更加緩慢。
顯然，要鼓勵提交小的 PR;如果是大的 PR，則至少要盡量把它分成明確的提交。
grauenwolf：
審查 PR 應該是一項與創建 PR 同樣重要的任務。
大眾需要理解這一點。高質量的代碼并不 cheap，尤其是在為項目定義設計模式的初期。
如果你在這一步上偷懶，你的代碼將很快變得雜亂無章(big ball of mud)。
8BitSk8r：
請告訴我的同事這個。他們認為“agile”意味著“we don't plan we just react”。
此外，Dan 還在文章中列舉了一些 PR 的替代方案。首先是"真正的"持續集成。現在很流行的一種說法是，CI 和 PR 是相互排斥的。基于主干的開發允許開發人員直接提交到主分支，而不需要任何形式的審查或合并過程。但 Dan 認為，這種方法可能只適用于最精英的團隊;對 95% 的人來說，它的缺點要大于優點。
其次是有人提出了一種 Ship / Show / Ask 策略：這是一種分支策略，它結合了 PR 的功能和保持發送變更的能力。Changes 被歸類為"Ship"(不經審查合并到主線)、"Show"(打開 PR 進行審查，但立即合并到主線)或 "Ask"(在合并之前打開 PR 進行討論)。總的來說，此策略對于低風險的工作，選擇直接合并而不審查或事后審查是有一定道理的。但是 Dan 指出它也存在一個問題，即目前大多數團隊都沒有適當的定義、流程和自動化來使其發揮作用。
此外還有結對編程(Pair programming)，不過這一方法好像也不盡適用。“我知道很多開發團隊使用結對來補充異步拉取請求審查，而我個人從未在一個使用結對來取代 PR 的團隊工作過。”
Dan 表示，他不認為 PR 會消失。“根據我的經驗，在合并之前讓隊友審查你的代碼是提高質量和減少錯誤的最好、最實惠的方法。PR 在捕捉可維護性錯誤方面特別有效，而這些錯誤是很難通過自動測試發現的”。且很多開發人員都同意 PR 是提高學習和教學質量的好工具。
而 LinearB 團隊也針對 PR 悖論推出了一個相關的提升 PR 審查效率的方案，并表示已收獲了積極地反饋。詳情可查看文章。
本文轉自OSCHINA
本文標題：PR 閑置時間太長?審查 PR 與創建 PR 同樣重要
本文地址：https://www.oschina.net/news/176589/pull-request-review
