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

近日，Meta 技術(shù)團(tuán)隊(duì)宣布采用了幾款工具和相應(yīng)流程，很大程度提高了代碼審查速率。

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

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

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

為了回答這個(gè)問題，首先需要查看自己的數(shù)據(jù)。在跟蹤了一項(xiàng)名為“審查時(shí)間”的指標(biāo)后，Meta 技術(shù)團(tuán)隊(duì)發(fā)現(xiàn)，需要衡量的是 diff 在單一審查周期內(nèi)等待審查的時(shí)長。這里只計(jì)算 diff 等待審查者操作的時(shí)間。

審查時(shí)間（Time In Review）指標(biāo)，計(jì)算的就是圖中各藍(lán)色部分（即無意義等待部分）耗費(fèi)的時(shí)間總和。

最終的發(fā)現(xiàn)令人驚訝。回顧 2021 年初的數(shù)據(jù)，研發(fā)人員發(fā)現(xiàn) diff 審查時(shí)間的中位數(shù)（第 50 百分位）只有幾個(gè)小時(shí)，這樣的結(jié)果還算不錯(cuò)。但如果把目光投向第 75 百分位（即最慢的那四分之一審查），就會(huì)發(fā)現(xiàn)diff 的審查時(shí)間延長到了一整天。

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

縮短審查時(shí)間不單能讓人們對(duì)整個(gè)代碼審查過程的滿意度更高，也會(huì)提高每一位 Meta 工程師的工作效率。縮短 diff 審查時(shí)間，意味著工程師耗費(fèi)在審查上的時(shí)間將大大減少、提升工作效率、改善審查體驗(yàn)。

在速度與質(zhì)量間求取平衡

然而，簡單粗暴地加快審查速度絕不是明智之舉，甚至?xí)彶樽兂珊翢o意義的走過場(chǎng)。因此需要設(shè)置一項(xiàng)護(hù)欄指標(biāo)，防止過快審查帶來的負(fù)面后果。在這里，研究人員選擇了“注視時(shí)間”，即審查者花在查看 diff 上的總時(shí)長。查看時(shí)間過短，即代表審查者很可能是在敷衍了事。

現(xiàn)在已經(jīng)有了核心指標(biāo)“審查時(shí)間”，也有了護(hù)欄指標(biāo)“注視時(shí)間”，接下來要怎么辦？

構(gòu)建、試驗(yàn)和迭代

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

試驗(yàn)過程：根據(jù)對(duì)代碼審查意義和體驗(yàn)設(shè)計(jì)的假設(shè)，選擇了目標(biāo)指標(biāo)和護(hù)欄指標(biāo)。此外還制定了一套選擇不同實(shí)驗(yàn)單元以實(shí)現(xiàn)隨機(jī)化抽樣的機(jī)制，包括用戶集群的隨機(jī)化。

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

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

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

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

改進(jìn)審查者匹配效果

可以看到，新方案的關(guān)鍵在于為 diff 選擇適當(dāng)?shù)膶彶檎摺Ｌ峤徽弋?dāng)然希望審查者能夠更好、更快地審查自己的代碼，特別是要得熟悉相關(guān) diff 的內(nèi)容和作用。從以往的情況看，Meta 的審查者推薦器會(huì)根據(jù)一組有限數(shù)據(jù)給出匹配建議，但這往往無法適應(yīng)新 diff 的需要，而且在工程師們輪換崗位后又得重新適配。

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

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

用 Nudgebot 解決 Diff 積壓問題

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

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

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

目前此功能已經(jīng)單獨(dú)發(fā)布：

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

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

審核編輯 ：李倩