大家好，這里是架構(gòu)資源棧！點(diǎn)擊上方關(guān)注，添加“星標(biāo)”，一起學(xué)習(xí)大廠前沿架構(gòu)！

關(guān)注、發(fā)送C1即可獲取JetBrains全家桶激活工具和碼！

在開發(fā)者日常中，**代碼評(píng)審（Code Review）**幾乎是必不可少的環(huán)節(jié)。但你是不是也有過這樣的抱怨：

• GitHub 上堆疊 PR（stacked pull requests）和 interdiff review 支持太差？
• 瀏覽器里點(diǎn)點(diǎn)點(diǎn)、寫評(píng)語卡頓，還得忍受 HTTP 往返延遲？
• 明明寫代碼用本地 IDE 爽得不行，評(píng)審卻只能被迫“回到石器時(shí)代”？

image

TigerBeetle 的開發(fā)者就嘗試過用一個(gè)小工具 git-review 來解決這些痛點(diǎn)，結(jié)果雖然沒能一舉成功，但留下了不少值得思考的火花。

GitHub 評(píng)審的兩大硬傷

作者直言，自己對(duì) GitHub（以及幾乎所有代碼評(píng)審系統(tǒng)）最不滿的有兩點(diǎn)：

1. 評(píng)審狀態(tài)不在倉庫里存儲(chǔ)
   它們都依賴遠(yuǎn)端數(shù)據(jù)庫，導(dǎo)致數(shù)據(jù)分散、依賴平臺(tái)、延遲高。

2. 評(píng)審強(qiáng)制遠(yuǎn)程優(yōu)先，局限在瀏覽器界面
   寫代碼大家都用本地 IDE，高效、順滑、支持個(gè)性化工作流?？稍u(píng)審卻要跑到網(wǎng)頁里，打字還時(shí)常卡頓，體驗(yàn)極差。

相比之下，作者平時(shí)的本地評(píng)審流程是：

• 把分支拉到本地
• reset 到基準(zhǔn)，讓代碼“像自己寫的一樣”
• 用 magit 瀏覽 diff 和源碼
• 本地跑測試、跳轉(zhuǎn)定義、甚至直接試著改代碼

這樣的體驗(yàn)完全碾壓瀏覽器。

git-review：把評(píng)審變成一個(gè) commit

image

于是，git-review 應(yīng)運(yùn)而生。思路很簡單：

• 評(píng)審 = 一個(gè) commit，掛在 PR 分支最上方

• 里面包含了評(píng)語注釋，例如：

  // CR(matklad): 這個(gè)判斷是不是不夠精確？
  // 要不要比較 `replica.view` 而不是 `header.view`？
  if (header.view != view) return;
  

• 作者和評(píng)審者共同修改這個(gè) commit

• 評(píng)審結(jié)束時(shí)，加一個(gè) revert commit 來保存評(píng)審歷史

聽起來很 hacker 風(fēng)格，但用起來確實(shí)讓人爽：評(píng)語直接嵌在代碼里，就像 pair programming 一樣直觀。

image

為什么沒能成功？

問題也很快暴露出來：

• 沖突難搞：當(dāng)作者改動(dòng)底層 commit 時(shí)，評(píng)審注釋（本質(zhì)上也是代碼）就會(huì)和 diff 發(fā)生沖突。
• --force-with-lease 摩擦感大：頻繁 rebase、強(qiáng)推，體驗(yàn)比預(yù)期更麻煩。
• 評(píng)審和代碼的“物理特性”不匹配：代碼需要嚴(yán)格的哈希鏈一致性，而評(píng)審更適合寬松的沖突合并。

結(jié)果是：這個(gè)“500 行 hack”沒能跑通，但卻暴露了很多有價(jià)值的方向。

未來可能的解法

作者提到兩個(gè)可能的希望：

• Git 社區(qū)的 Change-Id 提案：或許以后能原生支持 per-commit interdiff review，讓每次修改都能被追蹤。
• 存儲(chǔ)與界面一體化：像 Gerrit 的 NoteDb、git-appraise、git-bug 那樣，把評(píng)審狀態(tài)直接塞進(jìn) git 里，真正本地化。

而 Jane Street 的內(nèi)部系統(tǒng)，已經(jīng)證明“更好的世界”是可能存在的，只是還沒普及到大眾開發(fā)者工具。

小D的思考

這次 git-review 實(shí)驗(yàn)雖然“敗退”，但給我們留下了一個(gè)啟示：

?? 代碼評(píng)審的未來，也許不是更花哨的網(wǎng)頁界面，而是更本地化、更貼近開發(fā)者日常工作流的工具。

就像寫代碼沒人會(huì)滿足于 GitHub 網(wǎng)頁編輯器一樣，評(píng)審也遲早要回到本地 IDE，讓開發(fā)者在同一個(gè)上下文里既能寫代碼，也能高效 review。

本文由博客一文多發(fā)平臺(tái) OpenWrite 發(fā)布！