Good Code Reviews, Better Code Reviews¶
十年代码审查经验的总结：从"好"到"更好"的关键区别。
Key Takeaways¶
- "Good" vs "Better" 的四个维度：
- 覆盖范围：好——检查代码本身；更好——在更大系统上下文中审视
- 语气：好——开放式问题；更好——同理心，赞美好的方案
- nitpick：好——标记不重要评论；更好——意识到 nitpick 过多是工具/标准缺失的信号
- 跨时区：好——重叠时间审阅；更好——从系统层面解决跨团队依赖
- 新人的第一印象："更好的"审查会额外关注新人的首次体验，多解释、多引导、多鼓励
- 组织层面：顶级组织有硬性规则——没有 code review 的代码不能上线，投入工具改进
Better 的本质¶
与其说是"做得更多"，不如说是系统性思维：
| Good | Better |
|---|---|
| 审查这次变更 | 思考变更如何适应整个系统 |
| 在 code review 工具里来回争论 | 主动约作者聊，解决误解 |
| 忍受大量 nitpick | 推动 lint 自动化 + 团队标准 |
| 适应跨时区协作的延迟 | 思考能否消除跨团队依赖 |
Related¶
- [[wiki/summaries/mentoring-developers|Developers Mentoring Other Developers]] — 代码审查是最常见的非正式 mentorship
- [[wiki/concepts/systems-thinking|系统思维]] — better code reviews 的底层方法论