代码审查的主要目的：优先考虑可维护性而非捕捉 Bug

代码审查作为可维护性的工具

代码审查的主要目的是识别那些难以维护的代码。虽然审查者在过程中常常会发现 bug，但将代码审查作为主要的捕捉 bug 手段并不切实际，因为仅仅通过查看源代码并不能保证发现所有 bug。

当审查者难以理解某段代码的作用及其实现方式时，这种困难本身就是代码未来难以维护的信号。最有效的修复时机是在审查过程中进行，此时原作者仍然对实现细节了如指掌。

围绕可维护性来构建代码审查，使审查者拥有更可实现且客观的目标。

捕捉 Bug 是开放式的： 要求审查者“找出 bug”是一项没有明确成功定义的困难任务。审查者可能花数小时只找到三个 bug，却仍会因漏掉第四个而受到批评。
可理解性是二元的： 要求审查者“看看你能否理解这段代码”是一个直接的任务。成功是有保证的：审查者要么理解代码，要么不理解。如果不理解，只需标记出让其困惑的部分即可。

虽然可维护性是核心目标，完整的代码审查流程还能为工程团队提供若干关键的次要收益：

代码审查充当了一个关卡，使代码从个人作者的所有权转移到团队所有权。它确保至少有两个人了解代码库的每一部分，防止出现只有单个人知道关键系统工作原理的“知识孤岛”。

审查是向初级开发者传授团队约定和系统架构的主要渠道。资深开发者可以分享专业知识——例如优化技巧或库函数——并帮助作者遵循团队标准，以防止未来出现可维护性问题。

虽然不是捕捉 bug 的主要工具，审查仍充当最终的安全检查。它可以发现自动化测试可能遗漏的“代码异味”、安全风险和性能问题。审查还确保测试不仅仅是“绿灯”，而是真正验证预期逻辑，而不是仅仅映射代码实现。

并非所有工程师都认同可维护性应是主要关注点。讨论中出现了若干不同的观点：

高可靠性领域： 在航空航天等领域（如 DO-178C），代码审查往往被倒置，严格要求验证、准确性以及对需求的符合度作为首要任务。
“质量门”观点： 有人认为代码审查是整个生命周期中最重要的质量控制过程，尤其在需求模糊或缺乏 QA 流程时。在这种观点下，找 bug 是核心目标，而非次要目标。
自动化的角色： 大多数人同意功能正确性应由单元测试和 CI/CD 流水线负责。正如一位贡献者所说：

"如果主要目的是找 bug，或者缺少 bug，那么这就不是审查，而是审计。"

为了最大化以可维护性为中心的审查价值，审查者应当：