作者在Goatmire Elixir会议上观看了Saša Jurić的演讲"Tell Me a Story"，该演讲通过戏剧化方式讲述代码审查和拉取请求(PR)的常见问题，将技术主题转化为富有启发性的故事，兼具趣味性和实用性。演讲内容深刻，作者已开始实践其中的建议。

代码评审的艺术：如何让Pull Request讲好故事

作者：Meks McClure · 2025年9月23日

在Goatmire Elixir大会上，Saša Jurić的演讲《给我讲个故事》将戏剧表演与代码评审实践完美结合。这场兼具喜剧与悲剧元素的演讲，为困扰开发者的代码评审难题提供了全新视角。

代码评审的困境

大多数工程师都面临着相似的困境：冗长复杂的Pull Request（PR）让人望而生畏。我们常以"看起来不错"的敷衍评论草草了事，这种表面功夫正是代码库逐渐失控的根源。虽然git blame只会指向原作者，但每个团队成员都应对整个系统负责。

可评审PR的标准

Saša提出一个颠覆性观点：应当将难以理解的PR退回作者。这需要勇气承认"我看不懂"，但远比虚伪的"LGTM"更有价值。理想的可评审PR应具备： - 评审耗时：5-10分钟（针对熟悉业务的中高级开发者） - 代码量：控制在300行以内，超过500行将难以维护 - 结构化提交：通过commit讲述完整的开发故事

用commit讲故事的艺术

在演示环节，Saša用13个精心设计的commit完成了仅152行代码变动的PR。这些commit像章节般清晰： 1. 添加:runtime_tools依赖（为获取:scheduler.get_sample()） 2. 实现计算平均利用率功能（含迭代修正过程） 3. 采用fixup commit保持历史整洁

这种叙事方式让评审者能追踪每个决策背后的思考，而非面对一团混沌的最终差异。当使用git bisect排查故障时，这种清晰的commit历史更能快速定位问题源头。

协作共赢的评审文化

当PR具备： - 聚焦的修改范围 - 故事化的提交记录 - 可独立运行的每个commit 评审过程就会转变为真正的技术对话。这种实践不仅能加速开发周期，更能培养团队对代码质量的集体责任感。

下次提交PR时，不妨自问：你的代码故事足够引人入胜吗？从小处着手——控制代码量、完善commit信息，你和你的团队都将受益于这份用心。

[相关Git工具指南] - git blame：追溯代码修改者 - git rebase：整理提交历史 - git fixup：修正前期commit - git bisect：定位问题提交

代码审查的主要观点总结

1. PR拆分与范围

• 支持小PR拆分：认为小PR更易审查，降低认知负担。
  • "stacked PRs are a thing for a reason" (kaapipo)
  • "A good rule of thumb is 300 lines of code changes" (epage引用)
• 反对过度拆分：认为拆分会导致交互逻辑隐藏、审查时间延长，或增加冲突风险。
  • "If you split all the changes...make the development at least 10x longer" (ValleZ)
  • "You end up doing work on branches of branches...having tons of conflicts" (davedx)

2. 审查质量与时间投入

• 支持深度审查：认为审查是保证代码质量的关键，需投入足够时间。
  • "I take code reviews as possibly the most important part of my job" (surgical_fire)
  • "5-10 minute reviews are...thoughtless rubber-stamping" (mtlynch)
• 支持快速审查：认为某些场景下快速审查即可，需平衡效率与质量。
  • "Balance between get shit done and operational, quality concerns" (nenenejej)
  • "Simply reading through a PR in 10 minutes...can be fine" (ekidd)

3. 审查文化与团队协作

• 强调协作与共享理解：认为审查应注重上下文共享而非形式化。
  • "There’s no substitute for shared understanding of the context" (jvanderbot)
  • "Get reviewers involved before you even start coding" (williamcotton)
• 批评形式化审查：指出部分审查流于表面（如“LGTM”文化）。
  • "All you ever saw in review logs was 'LGTM'...What a farce" (vdupras)
  • "Peer-to-peer reviews pretend hierarchy does not exist" (octo888)

4. 工具与流程优化

• 推荐工具辅助：如分支堆叠、Git命令优化等。
  • "Use git log --first-parent to hide intermediate commits" (rjmunro)
  • "Jane Street’s system...reviews one commit at a time" (danielfalbo)
• 反对过度依赖工具：认为核心问题在于开发者态度而非工具。
  • "The core problem is developers accepting 'LGTM-stamping'" (vdupras)

5. AI与自动化审查

• 支持AI辅助：认为AI可处理浅层审查，释放人力。
  • "Why not just use AI for shallow reviews?" (osigurdson)
• 反对完全替代人工：认为AI无法替代深度审查。
  • "My preference...would be to eliminate human reviews...Oh, not like that" (stack_framer)

关键争议点

• PR大小：是否应以LOC为标准拆分（如300行）？部分观点认为逻辑连贯性更重要。
• 审查深度：快速审查是否足够？部分人认为需根据代码重要性调整（如核心模块需更严格）。
• 文化优先级：审查应侧重“质量把关”还是“知识共享”？多数倾向后者。

代表性引用

• 支持小PR：
  "stacked PRs are a thing for a reason" (kaapipo)
  "A PR should ideally have one controversial part" (epage)
• 反对形式化审查：
  "LGTM-stamping is the core problem" (vdupras)
  "Reviewing is NOT a purity test" (bob1029)