摘要：GitHub 上堆叠 PR（stacked pull requests）和 interdiff review 支持太差？浏览器里点点点、写评语卡顿，还得忍受 HTTP 往返延迟？明明写代码用本地 IDE 爽得不行，评审却只能被迫“回到石器时代”？
在开发者日常中，代码评审（Code Review）几乎是必不可少的环节。但你是不是也有过这样的抱怨：
GitHub 上堆叠 PR（stacked pull requests）和 interdiff review 支持太差？浏览器里点点点、写评语卡顿，还得忍受 HTTP 往返延迟？明明写代码用本地 IDE 爽得不行，评审却只能被迫“回到石器时代”？TigerBeetle 的开发者就尝试过用一个小工具 git-review 来解决这些痛点，结果虽然没能一举成功，但留下了不少值得思考的火花。
#技术分享作者直言，自己对 GitHub（以及几乎所有代码评审系统）最不满的有两点：
评审状态不在仓库里存储 它们都依赖远端数据库，导致数据分散、依赖平台、延迟高。评审强制远程优先，局限在浏览器界面 写代码大家都用本地 IDE，高效、顺滑、支持个性化工作流。可评审却要跑到网页里，打字还时常卡顿，体验极差。相比之下，作者平时的本地评审流程是：
把分支拉到本地reset 到基准，让代码“像自己写的一样”用 magit 浏览 diff 和源码本地跑测试、跳转定义、甚至直接试着改代码这样的体验完全碾压浏览器。
于是，git-review 应运而生。思路很简单：
评审 = 一个 commit，挂在 PR 分支最上方里面包含了评语注释，例如：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 的内部系统，已经证明“更好的世界”是可能存在的，只是还没普及到大众开发者工具。
代码评审的未来，也许不是更花哨的网页界面，而是更本地化、更贴近开发者日常工作流的工具。
就像写代码没人会满足于 GitHub 网页编辑器一样，评审也迟早要回到本地 IDE，让开发者在同一个上下文里既能写代码，也能高效 review。
本文由博客一文多发平台 OpenWrite 发布！
来源：墨码行者
免责声明：本站系转载，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与本站联系，我们将在第一时间删除内容!
