代码评审还能更好！

大家好，这里是架构资源栈！点击上方关注，添加“星标”，一起学习大厂前沿架构！

关注、发送C1即可获取JetBrains全家桶激活工具和码！

在开发者日常中，**代码评审（Code Review）**几乎是必不可少的环节。但你是不是也有过这样的抱怨：

• GitHub 上堆叠 PR（stacked pull requests）和 interdiff review 支持太差？
• 浏览器里点点点、写评语卡顿，还得忍受 HTTP 往返延迟？
• 明明写代码用本地 IDE 爽得不行，评审却只能被迫“回到石器时代”？

TigerBeetle 的开发者就尝试过用一个小工具 git-review 来解决这些痛点，结果虽然没能一举成功，但留下了不少值得思考的火花。

GitHub 评审的两大硬伤

作者直言，自己对 GitHub（以及几乎所有代码评审系统）最不满的有两点：

1. 评审状态不在仓库里存储 它们都依赖远端数据库，导致数据分散、依赖平台、延迟高。

2. 评审强制远程优先，局限在浏览器界面 写代码大家都用本地 IDE，高效、顺滑、支持个性化工作流。可评审却要跑到网页里，打字还时常卡顿，体验极差。

相比之下，作者平时的本地评审流程是：

• 把分支拉到本地
• reset 到基准，让代码“像自己写的一样”
• 用 magit 浏览 diff 和源码
• 本地跑测试、跳转定义、甚至直接试着改代码

这样的体验完全碾压浏览器。

git-review：把评审变成一个 commit

于是，git-review 应运而生。思路很简单：

• 评审 = 一个 commit，挂在 PR 分支最上方

• 里面包含了评语注释，例如：

  // CR(matklad): 这个判断是不是不够精确？
  // 要不要比较 `replica.view` 而不是 `header.view`？
  if (header.view != view) return;
  

• 作者和评审者共同修改这个 commit

• 评审结束时，加一个 revert commit 来保存评审历史

听起来很 hacker 风格，但用起来确实让人爽：评语直接嵌在代码里，就像 pair programming 一样直观。

为什么没能成功？

问题也很快暴露出来：

• 冲突难搞：当作者改动底层 commit 时，评审注释（本质上也是代码）就会和 diff 发生冲突。
• --force-with-lease 摩擦感大：频繁 rebase、强推，体验比预期更麻烦。
• 评审和代码的“物理特性”不匹配：代码需要严格的哈希链一致性，而评审更适合宽松的冲突合并。

结果是：这个“500 行 hack”没能跑通，但却暴露了很多有价值的方向。

未来可能的解法

作者提到两个可能的希望：

• Git 社区的 Change-Id 提案：或许以后能原生支持 per-commit interdiff review，让每次修改都能被追踪。
• 存储与界面一体化：像 Gerrit 的 NoteDb、git-appraise、git-bug 那样，把评审状态直接塞进 git 里，真正本地化。

而 Jane Street 的内部系统，已经证明“更好的世界”是可能存在的，只是还没普及到大众开发者工具。

小D的思考

这次 git-review 实验虽然“败退”，但给我们留下了一个启示：

? 代码评审的未来，也许不是更花哨的网页界面，而是更本地化、更贴近开发者日常工作流的工具。

就像写代码没人会满足于 GitHub 网页编辑器一样，评审也迟早要回到本地 IDE，让开发者在同一个上下文里既能写代码，也能高效 review。