為什么diff審查的速度總是那么慢？

代碼審查是軟件開發(fā)過程中最重要的環(huán)節(jié)之一。如果這項工作做得好，代碼審查能夠切實幫助我們發(fā)現 bug，普及最佳實踐并保障代碼質量。

近日，Meta 技術團隊宣布采用了幾款工具和相應流程，很大程度提高了代碼審查速率。

Meta 技術團隊將針對代碼庫做出的一組獨立變更稱為“diff”。雖然 Meta 非常重視開發(fā)效率，但每條 diff 也必須經受嚴格審查，絕無例外。代碼審查團隊深知審查周期越長，留給開發(fā)者們完成工作的時間就會越短。

為此，Meta 技術團隊研究了多項指標，希望更多了解哪些代碼審查瓶頸最令開發(fā)者們感到不滿，并積極利用這些結論探尋在不犧牲審查質量的前提下加快審查速度的辦法。通過研究發(fā)現，緩慢的 diff 審查速度跟工程師們的不滿情緒間存在相關性。另外，新研發(fā)的工具能夠在審查周期的各個關鍵節(jié)點向相應審查人員展示 diff，由此顯著改善審查體驗。

為什么 diff 審查的速度總是那么慢？

為了回答這個問題，首先需要查看自己的數據。在跟蹤了一項名為“審查時間”的指標后，Meta 技術團隊發(fā)現，需要衡量的是 diff 在單一審查周期內等待審查的時長。這里只計算 diff 等待審查者操作的時間。

審查時間（Time In Review）指標，計算的就是圖中各藍色部分（即無意義等待部分）耗費的時間總和。

最終的發(fā)現令人驚訝?；仡?2021 年初的數據，研發(fā)人員發(fā)現 diff 審查時間的中位數（第 50 百分位）只有幾個小時，這樣的結果還算不錯。但如果把目光投向第 75 百分位（即最慢的那四分之一審查），就會發(fā)現diff 的審查時間延長到了一整天。

研發(fā)人員分析了審查時間跟用戶滿意度（通過全公司范圍內的量化調查）之間的相關性。結果非常明確：速度最慢的那 25% diff 審查，才是決定人們實際體驗的核心；這部分耗時越長，大家對代碼審查過程的滿意度就越低。于是也就得出了最值得關注的改進指標：第 75 百分位（P75）審查時間。

縮短審查時間不單能讓人們對整個代碼審查過程的滿意度更高，也會提高每一位 Meta 工程師的工作效率?？s短 diff 審查時間，意味著工程師耗費在審查上的時間將大大減少、提升工作效率、改善審查體驗。

在速度與質量間求取平衡

然而，簡單粗暴地加快審查速度絕不是明智之舉，甚至會將審查變成毫無意義的走過場。因此需要設置一項護欄指標，防止過快審查帶來的負面后果。在這里，研究人員選擇了“注視時間”，即審查者花在查看 diff 上的總時長。查看時間過短，即代表審查者很可能是在敷衍了事。

現在已經有了核心指標“審查時間”，也有了護欄指標“注視時間”，接下來要怎么辦？

構建、試驗和迭代

在 Meta，幾乎每個產品團隊都會使用試驗加數據驅動的流程推進功能發(fā)布和迭代。但對于這些內部輔助團隊，這樣的流程仍然比較新鮮。因此人們需要克服一系列產品團隊根本不需要考慮的挑戰(zhàn)（樣本量、隨機化、網絡效應等）。研發(fā)人員通過運行網絡實驗積累起數據基準，并利用技術減少方差、增加樣本量。事實證明，這些努力都是值得的——通過奠定堅實的試驗基礎，使得研發(fā)團隊最終拿出了具有積極影響且行之有效的新一代代碼審查方案。

試驗過程：根據對代碼審查意義和體驗設計的假設，選擇了目標指標和護欄指標。此外還制定了一套選擇不同實驗單元以實現隨機化抽樣的機制，包括用戶集群的隨機化。

建立“下一可審查 diff”的概念

Meta 技術研發(fā)團隊表示，關于這個概念的靈感，來自視頻流服務。由于每集視頻之間會無縫過渡，所以流媒體服務平臺上的觀看體驗總是絲滑順暢。那能不能把同樣的體驗引入代碼審查當中？通過 diff 隊列，他們建立起了類似的 diff 審查流體系，鼓勵審查者們充分利用自己的時間和精力。

于是乎，“下一可審查 diff”的概念由此誕生。研發(fā)團隊使用機器學習識別出審查者當前最可能想要審查的 diff，并在其完成當前代碼審查之后，立即把感興趣的下一 diff 呈現出來。通過這種方式，我們就能輕松把 diff 審查循環(huán)起來，同時避免審查者接觸到與其不相干的 diff。

新方案上線之后，研發(fā)團隊發(fā)現，日均審查操作（包括 diff 接納量、提交量等）總體增長了 17%，而使用此流程的工程師們執(zhí)行的審查操作比未使用的審查員多出 44%！

改進審查者匹配效果

可以看到，新方案的關鍵在于為 diff 選擇適當的審查者。提交者當然希望審查者能夠更好、更快地審查自己的代碼，特別是要得熟悉相關 diff 的內容和作用。從以往的情況看，Meta 的審查者推薦器會根據一組有限數據給出匹配建議，但這往往無法適應新 diff 的需要，而且在工程師們輪換崗位后又得重新適配。

為此，研發(fā)團隊建立了新的審查者推薦系統(tǒng)，將工作時間感知和文件歸屬信息結合起來，這就讓有空審查 diff、擅長審查特定 diff 的審查者更可能被選中。我們重寫了建議支持模型，添加了回溯測試和自動再訓練等功能。

結果就是，一天之內 diff 審查量增加了 1.5%，而且前三條推薦的準確率（即實際審查者來自前三條推薦）的概率也從不到 60% 增長至近 75%。除此之外，新模型還將推薦速度（第 90 百分位延遲）提升了 14 倍！

用 Nudgebot 解決 Diff 積壓問題

我們知道工程師們最不喜歡的就是 diff 積壓問題。這不僅讓人不爽，而且審查速度過慢還會令代碼過時，導致開發(fā)者在不同上下文間來回切換、影響整體生產力。為了解決這個問題，Meta 研發(fā)團隊構建了 Nudgebot，其靈感來自微軟所做的相關研究。

對于需要額外長時間審查的 diff，Nudgebot 會首先確定最適合的審查者子集，然后向他們發(fā)送一條聊天 ping，其中包含 diff 的部分上下文和快速跳轉至審查流程的操作選項。

Nudgebnot 試驗也取得了不錯的效果。所有 diff 的平均審查時間縮短了 7%（不含周末時段），審查周期超過 3 天的 diff 比例也下降了 12%。

目前此功能已經單獨發(fā)布：

https://users.encs.concordia.ca/~pcr/paper/NudgeBot2022FSE-preprint.pdf

這里就是審查者在屏幕上看到的積壓 diff 通知，下方還有“稍后提醒我”按鈕。

審核編輯 ：李倩