代碼審查是軟件開發(fā)過程中最重要的環(huán)節(jié)之一。如果這項工作做得好，代碼審查能夠切實幫助我們發(fā)現(xiàn) bug，普及最佳實踐并保障代碼質(zhì)量。
近日，Meta 技術(shù)團(tuán)隊宣布采用了幾款工具和相應(yīng)流程，很大程度提高了代碼審查速率。
Meta 技術(shù)團(tuán)隊將針對代碼庫做出的一組 獨立變更 稱為“diff”。雖然 Meta 非常重視開發(fā)效率，但每條 diff 也必須經(jīng)受嚴(yán)格審查，絕無例外。代碼審查團(tuán)隊深知 審查周期越長，留給開發(fā)者們完成工作的時間就會越短。
為此，Meta 技術(shù)團(tuán)隊研究了多項指標(biāo)，希望更多了解哪些代碼審查瓶頸最令開發(fā)者們感到不滿，并積極利用這些結(jié)論探尋在不犧牲審查質(zhì)量的前提下加快審查速度的辦法。通過研究發(fā)現(xiàn)，緩慢的 diff 審查速度跟工程師們的不滿情緒間存在相關(guān)性。另外，新研發(fā)的工具能夠在審查周期的各個關(guān)鍵節(jié)點向相應(yīng)審查人員展示 diff，由此顯著改善審查體驗。
為了回答這個問題，首先需要查看自己的數(shù)據(jù)。在跟蹤了一項名為“審查時間”的指標(biāo)后，Meta 技術(shù)團(tuán)隊發(fā)現(xiàn)，需要衡量的是 diff 在單一審查周期內(nèi)等待審查的時長。這里只計算 diff 等待審查者操作的時間。
審查時間（Time In Review）指標(biāo)，計算的就是圖中各藍(lán)色部分（即無意義等待部分）耗費的時間總和。
最終的發(fā)現(xiàn)令人驚訝。回顧 2021 年初的數(shù)據(jù)，研發(fā)人員發(fā)現(xiàn) diff 審查時間的中位數(shù)（第 50 百分位）只有幾個小時，這樣的結(jié)果還算不錯。但如果把目光投向第 75 百分位（即最慢的那四分之一審查），就會發(fā)現(xiàn) diff 的審查時間延長到了一整天。
研發(fā)人員分析了審查時間跟用戶滿意度（通過全公司范圍內(nèi)的量化調(diào)查）之間的相關(guān)性。結(jié)果非常明確：速度最慢的那 25% diff 審查，才是決定人們實際體驗的核心；這部分耗時越長，大家對代碼審查過程的滿意度就越低。于是也就得出了最值得關(guān)注的改進(jìn)指標(biāo)：第 75 百分位（P75）審查時間。
縮短審查時間不單能讓人們對整個代碼審查過程的滿意度更高，也會提高每一位 Meta 工程師的工作效率?？s短 diff 審查時間，意味著工程師耗費在審查上的時間將大大減少、提升工作效率、改善審查體驗。
然而，簡單粗暴地加快審查速度絕不是明智之舉，甚至?xí)彶樽兂珊翢o意義的走過場。因此需要設(shè)置一項護(hù)欄指標(biāo)，防止過快審查帶來的負(fù)面后果。在這里，研究人員選擇了“注視時間”，即審查者花在查看 diff 上的總時長。查看時間過短，即代表審查者很可能是在敷衍了事。
現(xiàn)在已經(jīng)有了核心指標(biāo)“審查時間”，也有了護(hù)欄指標(biāo)“注視時間”，接下來要怎么辦？
在 Meta，幾乎每個產(chǎn)品團(tuán)隊都會使用試驗加數(shù)據(jù)驅(qū)動的流程推進(jìn)功能發(fā)布和迭代。但對于這些內(nèi)部輔助團(tuán)隊，這樣的流程仍然比較新鮮。因此人們需要克服一系列產(chǎn)品團(tuán)隊根本不需要考慮的挑戰(zhàn)（樣本量、隨機(jī)化、網(wǎng)絡(luò)效應(yīng)等）。研發(fā)人員通過運行網(wǎng)絡(luò)實驗積累起數(shù)據(jù)基準(zhǔn)，并利用技術(shù)減少方差、增加樣本量。事實證明，這些努力都是值得的——通過奠定堅實的試驗基礎(chǔ)，使得研發(fā)團(tuán)隊最終拿出了具有積極影響且行之有效的新一代代碼審查方案。
試驗過程：根據(jù)對代碼審查意義和體驗設(shè)計的假設(shè)，選擇了目標(biāo)指標(biāo)和護(hù)欄指標(biāo)。此外還制定了一套選擇不同實驗單元以實現(xiàn)隨機(jī)化抽樣的機(jī)制，包括用戶集群的隨機(jī)化。
Meta 技術(shù)研發(fā)團(tuán)隊表示，關(guān)于這個概念的靈感，來自視頻流服務(wù)。由于每集視頻之間會無縫過渡，所以流媒體服務(wù)平臺上的觀看體驗總是絲滑順暢。那能不能把同樣的體驗引入代碼審查當(dāng)中？通過 diff 隊列，他們建立起了類似的 diff 審查流體系，鼓勵審查者們充分利用自己的時間和精力。
于是乎，“下一可審查 diff”的概念由此誕生。研發(fā)團(tuán)隊使用機(jī)器學(xué)習(xí)識別出審查者當(dāng)前最可能想要審查的 diff，并在其完成當(dāng)前代碼審查之后，立即把感興趣的下一 diff 呈現(xiàn)出來。通過這種方式，我們就能輕松把 diff 審查循環(huán)起來，同時避免審查者接觸到與其不相干的 diff。
新方案上線之后，研發(fā)團(tuán)隊發(fā)現(xiàn)，日均審查操作（包括 diff 接納量、提交量等）總體增長了 17%，而使用此流程的工程師們執(zhí)行的審查操作比未使用的審查員多出 44%！
可以看到，新方案的關(guān)鍵在于為 diff 選擇適當(dāng)?shù)膶彶檎?。提交者?dāng)然希望審查者能夠更好、更快地審查自己的代碼，特別是要得熟悉相關(guān) diff 的內(nèi)容和作用。從以往的情況看，Meta 的審查者推薦器會根據(jù)一組有限數(shù)據(jù)給出匹配建議，但這往往無法適應(yīng)新 diff 的需要，而且在工程師們輪換崗位后又得重新適配。
為此，研發(fā)團(tuán)隊建立了新的審查者推薦系統(tǒng)，將工作時間感知和文件歸屬信息結(jié)合起來，這就讓有空審查 diff、擅長審查特定 diff 的審查者更可能被選中。我們重寫了建議支持模型，添加了回溯測試和自動再訓(xùn)練等功能。
結(jié)果就是，一天之內(nèi) diff 審查量增加了 1.5%，而且前三條推薦的準(zhǔn)確率（即實際審查者來自前三條推薦）的概率也從不到 60% 增長至近 75%。除此之外，新模型還將推薦速度（第 90 百分位延遲）提升了 14 倍！
我們知道工程師們最不喜歡的就是 diff 積壓問題。這不僅讓人不爽，而且審查速度過慢還會令代碼過時，導(dǎo)致開發(fā)者在不同上下文間來回切換、影響整體生產(chǎn)力。為了解決這個問題，Meta 研發(fā)團(tuán)隊構(gòu)建了 Nudgebot，其靈感來自微軟所做的相關(guān)研究。
對于需要額外長時間審查的 diff，Nudgebot 會首先確定最適合的審查者子集，然后向他們發(fā)送一條聊天 ping，其中包含 diff 的部分上下文和快速跳轉(zhuǎn)至審查流程的操作選項。
Nudgebnot 試驗也取得了不錯的效果。所有 diff 的平均審查時間縮短了 7%（不含周末時段），審查周期超過 3 天的 diff 比例也下降了 12%。
目前此功能已經(jīng)單獨發(fā)布：
https://users.encs.concordia.ca/~pcr/paper/NudgeBot2022FSE-preprint.pdf
閩公網(wǎng)安備 35010202001226號
