代码审查的首要目的是找出将来会难以维护的代码

原文 ↗ Hacker News 讨论 ↗

代码审查的目的：单一目标还是多个目标

  • 许多人不同意把“找出难以维护的代码”表述为首要目标。
  • 被提出作为首要目标的替代项包括：知识传递、正确性/减少缺陷、设计健全性检查、安全性，或者仅仅是“就这次改动进行一次对话”。
  • 也有人认为不存在单一目的；代码审查本质上是多用途的，而且取决于上下文（团队规模、信任程度、领域、监管要求）。

可维护性 vs 发现 Bug

  • 有人支持以可维护性为先的表述：如果代码清晰、简单，更容易发现 bug，修复也更安全。
  • 也有人强调，他们在审查中经常发现真实 bug（逻辑错误、边界情况、安全和性能问题），并认为这不是附带收益，而是核心目的。
  • 多条评论反驳“检查代码不能发现 bug”这一说法，认为这要么与实践不符，要么只是理论表述没有说清。

知识共享与所有权

  • 一个反复出现的强主题是：代码审查是知识传递和共享所有权。
  • 阅读 PR 能让队友了解系统变更，避免意外，并提高“公交因子”。
  • 有些团队甚至会专门创建 PR 作为沟通载体，即使是立即合并也是如此。

流程、工作流与文化

  • 不同工作流下的看法差异很大：
    • 先有结构化设计的流程 vs “在 PR 里做设计”。
    • 小型、高信任团队 vs 大型、低信任或受监管环境。
    • 异步的 GitHub 式审查 vs 同步的会议式审查。
  • 代码审查既可以是健康的（教学、协作），也可以是有毒的（把关、地位之争、表演式批准）。团队文化和指导被认为至关重要。

测试 vs 审查

  • 许多人强调，主要的正确性保证应该来自测试，而不是审查。
  • 优秀的审查也会检查测试或测试计划是否存在，以及其质量如何。
  • 也有人指出，审查有时能发现测试可能漏掉的集成问题，尤其是在文档和系统边界薄弱的地方。

AI 与不断变化的环境

  • 有人指出，AI 生成代码和 AI 辅助审查会增加代码量和“垃圾内容”，让细致的人类审查更难。
  • 有人预见 PR 审查会变得不可持续，或者被彻底改变；也有人坚持，人类仍然必须确保理解和可维护 AI 编写的代码。