代码审查（Code Review）是软件工程中被讨论得最多、却也最容易被误解的实践之一。大多数团队都知道要做代码审查，但真正把代码审查做有效的团队并不多。代码审查做得好，是团队技术质量最重要的防线；做得不好，不仅不能提升代码质量，反而会成为团队的负担——拖慢开发速度、消耗工程师精力、甚至制造团队摩擦。
这篇文章不是代码审查的入门介绍，而是面向已经有一定工程经验、但对代码审查的实际效果不满意的团队。我会从代码审查的本质目标出发，分析常见的误区，给出可操作的审查清单，讨论工具选型和流程设计，最后谈谈团队文化的建设。目标不是给你一套可以照搬的流程，而是帮你理解代码审查的底层逻辑，让你能根据自己团队的情况做出合适的决策。
一、代码审查究竟在解决什么问题
在讨论怎么做代码审查之前，必须先搞清楚为什么要做代码审查。如果不清楚目标，审查行为就会演变成一种仪式：大家觉得"有总比没有好"，但没人说得清楚具体好在哪里。仪式化的代码审查有两个典型的失败模式：一是审查变成走过场，PR（Pull Request）发出去没人看，或者看了只挑格式问题；二是审查变成辩论场，双方为了一个风格问题争论半天，真正的设计缺陷反而被忽略。
要理解代码审查的目标，先要把代码审查和其他质量保障手段区分开。
单元测试解决的是"这段代码在逻辑上是否正确"的问题，通过构造输入-输出断言来验证函数的行为。集成测试解决的是"这些组件在一起是否能正常协作"的问题，通过端到端的场景覆盖来验证系统的行为。代码审查解决的是什么问题？它解决的是人类协作中的信息不对称问题：一个人写的代码，其他人要理解、使用、维护——这个过程中，代码的作者和使用者之间存在巨大的认知差距，代码审查是缩小这个差距的手段。
具体来说，代码审查在解决以下几个层面的问题：
第一，发现测试没发现的问题。 测试能验证你已经知道会出错的地方，但很难发现你"不知道你会出错"的地方。代码审查者的价值在于，他带着不同的背景知识，看到的是你没有看到的风险。一个常见的例子：作者认为某个字段"反正后端不会用"于是不加验证，审查者从用户输入的角度发现了安全漏洞。这是测试很难覆盖的场景，因为测试工程师按照"正常使用路径"构造数据，不会构造攻击者的视角。
第二，传播知识，防止知识孤岛。 任何只有一个人理解的代码，都是团队的风险点。代码审查强迫作者解释自己的设计决策，强迫审查者理解代码的上下文。经过审查的代码，即使审查者当时没有提出修改意见，也对这段代码有了足够的了解——至少知道这段代码在做什么、为什么这样做。当原作者休假、离职或者转岗时，代码的可维护性不会断崖式下降。
第三，约束代码质量的基线。 没有审查的代码，风格是随作者心情的，命名是随作者习惯的，架构决策是随作者认知的。代码审查把"什么是好的代码"从个人标准变成团队共识，通过一次次具体的反馈，把团队对代码质量的期望落实到每一行新增代码里。这是一个缓慢但有效的文化建设过程。
第四，在合入主分支之前捕获问题。 缺陷发现得越晚，修复成本越高。代码审查是缺陷离生产环境最近的检查点之一。在这个阶段发现问题，修改成本只是改几行代码；在测试阶段发现问题，要重新跑测试流程；在生产环境发现，代价可能是线上故障和用户损失。
这四个目标中，哪个是最重要的？不同团队有不同的答案，但我的观察是：大多数团队把代码审查当成质量检查工具，花了大量精力在"这段代码有没有 bug"上，却忽视了其他三个同样重要的目标。特别是"知识传播"这个目标，经常被低估——当团队扩张时，这个问题会突然爆发：老代码没人能看懂，新功能没人敢动，技术债务急剧积累。
理解了代码审查的目标，再来看常见的误区，就容易理解为什么这些做法偏离了本质。
二、代码审查的七个常见误区
误区一：审查者负责发现缺陷，作者负责修复
这是最普遍、也是危害最大的误区。持这种观点的团队，代码审查的默认模式是：作者提交 PR，审查者找出问题，作者逐个修复，直到审查者点头同意合入。
这个模式的问题在于，它把"代码质量"的责任完全压在审查者身上，而审查者往往只有部分上下文——他能看到这次改动的 diff，但不一定了解这段代码的历史、不了解产品的需求背景、不了解技术债务的现状。让审查者承担发现所有问题的责任，既不公平，也不可能。
更健康的模式是：作者在提交审查之前，自己先完成一轮自我审查。这个自我审查不是指跑完 CI 检查（CI 检查的是最低标准，不是质量标准），而是作者站在审查者的角度，提前过一遍自己的代码：有没有可读性差的地方？有没有自己也知道不太优雅但先凑合的实现？有没有边界情况没有处理？把这些自己知道但懒得改的问题主动标注出来，让审查者把精力放在作者看不到的盲区上。
这个模式的关键是：作者不是把审查当考试，把审查者当阅卷老师；而是把审查当协作，把审查者当第二双眼睛。
误区二：审查范围只限于"这次改了什么"
很多审查者的关注范围，是 PR 的 diff——只看你这次改了什么。这种审查方式能发现局部的问题（变量命名、逻辑错误、格式规范），但无法发现系统性的问题。
一个真实场景：某个微服务需要加一个接口，PR 的 diff 是新增了 200 行代码，看起来逻辑清晰、没有明显问题。但审查者不知道的是，这个微服务上周刚加了一个类似的接口，两个接口的业务逻辑高度重复——它们完全可以合并成一个更通用的实现。如果审查者的视野只限在这次 diff，他看不到这个系统层面的设计问题。
好的审查者会问：这个改动在整个系统里是什么位置？它和已有的代码是什么关系？它解决了用户的什么需求？这个需求有没有在其他地方以不同的方式被满足过？这些问题的答案，往往不在 diff 里，而在审查者对系统的整体理解中。
误区三：审查意见等于代码风格偏好
审查中争论最多的话题，往往是代码风格：括号应该换行还是不换行？变量名是 userId 还是 user_id？应该用 for 循环还是 map？这些不是不重要，但没有重要到值得消耗团队大量精力的地步。
代码风格问题应该通过自动化工具解决：ESLint、Prettier、gofmt、rustfmt、PEP8——每种语言都有成熟的格式化工具。把风格问题交给工具，审查者专注于真正需要人类判断的事情：设计是否合理、边界条件是否处理、安全风险是否存在、复杂度是否必要。
审查意见可以分为两类：必须修改的问题和建议修改的问题。风格问题通常是建议，不应该在审查中被当成必须项。如果团队对某些风格问题有强烈的共识（比如说命名应该用驼峰还是下划线），那应该把这种共识固化到 linter 配置里，而不是每次审查都讨论一遍。
误区四：PR 越大越好——一次审查更多代码
大 PR（Pull Request）是代码审查效率的最大杀手。一个 PR 改动了几千行代码，审查者面对的是一片代码海洋。在这种规模下，审查质量几乎必然下降——人的注意力是有限的，看 300 行代码和看 3000 行代码投入的精力是天壤之别。
研究表明，代码审查中发现缺陷的概率在审查时长超过 60-90 分钟后急剧下降。换句话说，大 PR 的边际审查收益是递减的：前 60 分钟的审查能发现大部分问题，后面的时间要么是疲劳带来的漏报，要么是无关紧要的细枝末节。
正确的做法是把 PR 控制在合理的规模：一次审查的代码量不超过 400 行（不同团队的舒适区可能略有差异，但 400 行是一个经过研究验证的参考值）。如果功能太大，应该拆成多个小的 PR，每个 PR 解决一个独立的问题。Git 的分支模型和 PR 机制本来就支持这种工作方式，feature branch 存在的意义之一就是让代码增量地、可管理地流入主分支。
误区五：审查速度不重要，等一等没关系
"反正我先做别的，这个 PR 等一下再审。"这句话在很多团队里是常态。但审查延迟对工程效率的损害是系统性的。
从作者的角度看，当一个 PR 等待审查的时间超过几个小时，工作流就被打断了。作者需要记住自己改了什么、为什么这样改、心理状态从"编码模式"切换到"等待模式"——这些都是有认知成本的。更糟糕的是，如果审查意见需要大改，作者需要重新加载上下文，重新理解自己的代码，这个"上下文切换"的代价可能比写代码本身还高。
从团队的角度看，PR 堆积是技术债务的隐性积累形式。太多的 open PR 会让代码分支状态变得混乱——有人在 feature/login 上改用户模块，有人在 feature/user-rework 上改登录模块，两个 PR 的改动可能有冲突，等合入的时候要解决大量的 merge conflict。这种状况往往不是哪个人的问题，而是审查速度跟不上开发速度的系统性问题。
Google 的工程实践建议：PR 应该在 24 小时内得到第一次审查反馈。这个目标不是要求审查者放下手头的所有工作去审代码，而是要求团队建立"审查优先级不低于编码"的意识——审查别人的代码和写自己的代码同样重要。
误区六：默认所有人都有审查权限
代码审查的权限设计是很多团队忽视的话题。一个常见的做法是：所有工程师都有权限审查所有代码、合并所有 PR。这个做法看起来很开放、很平等，但实际上会带来两个问题：
第一，审查质量参差不齐。一个刚入职三天的工程师和一个在这个系统上工作了三年的大牛，看问题的深度是不同的。如果不对审查者的权限做区分，可能出现这种情况：大牛的审查意见被淹没在一堆格式问题的评论里，或者作者的 PR 被经验不足的审查者提出了不合适的修改要求，导致反复修改拖延了时间。
第二，安全风险被忽视。在大型团队中，不是所有人都有权限接触所有代码——比如支付模块、安全相关配置、基础设施的核心逻辑。这些代码的审查需要额外的权限验证：如果一个没有权限的人可以"审查并合入"支付模块的代码，这个权限设计就是形同虚设的。
更好的做法是分层审查权限：基础权限允许审查和评论任意代码，但合并权限需要额外的授权。敏感模块的 PR 必须由特定人员审批，普通功能模块的 PR 可以由任意高级工程师审批，文档或测试文件的 PR 可以快速通道审批。这种分层设计让审查资源集中在最需要的地方，同时保证了关键代码的安全性。
误区七：把审查意见当成对人的评价
这是代码审查中最微妙、也最难处理的误区。当审查者说"这个设计有问题"时，作者听到的可能是"我这个人有问题"。这种情绪反应不是非理性的——代码审查确实是工程师表达专业能力的重要场景，否定一段代码确实可能让作者感到被否定。
但这种情绪反应如果不加控制，会让代码审查变成一场社交博弈：作者为了维护自尊，会为自己的代码辩护，即使心里知道审查者的意见是对的；审查者为了避免冲突，会把自己的意见包装得很委婉、很模糊，失去了审查应有的直接性。结果是：代码质量没有提升，团队关系变得微妙，代码审查成了一种大家都在表演的仪式。
解决这个问题的关键不是靠个人的情商，而是靠团队建立的共识和规范。当团队明确"审查意见是针对代码的，不是针对人的"这个原则，并且通过具体的实践来强化它——比如审查意见用客观的描述而非评价性的语言、"这个实现有问题"改成"这个实现可能导致 X 问题"——审查的社交压力就会大幅降低。好的代码审查文化，是让所有参与者都感到"我在帮这段代码变得更好"，而不是"我在证明我比你更懂"。
三、有效代码审查的清单
把代码审查从"凭感觉"变成"有框架"，最好的工具是一份实用的审查清单。清单不是为了机械地打勾，而是为了让审查者不要遗漏重要的检查维度，也为了让作者知道审查者会关注哪些方面，从而在提交前做好准备。
以下清单分四个维度，覆盖了代码审查中最重要的检查领域。
3.1 设计层面
这段代码是否解决了正确的问题？ 这是最根本的问题，但也是最容易被跳过的问题。很多审查者默认"产品需求是正确的"，只审查代码实现，不审查需求本身。但在实际工作中，需求文档有遗漏、实现和需求有偏差、需求本身有逻辑漏洞，这些情况都时有发生。审查者应该有能力、也有责任质疑需求本身——如果一个需求的实现成本很高，但业务价值不清晰，或者需求之间存在逻辑矛盾，这正是审查应该捕获的。
这个设计决策是否符合系统的整体架构？ 新增的代码不是孤立的，它会和现有的系统交互、共享数据、依赖服务。审查者需要判断：这个改动有没有破坏已有的架构约定？有没有引入隐藏的循环依赖？有没有绕过已有的抽象层直接操作底层数据？这些问题往往不是单看 diff 能看出来的，需要对系统的架构有整体了解。
模块边界是否清晰？ 新增的代码是否和现有模块之间有清晰的边界？还是混在了一个本不应该包含这段逻辑的模块里？模块边界不清晰是技术债务的典型来源——它不会立刻表现为 bug，但会让未来的修改越来越困难，因为改动的影响范围不可预测。
是否有过度设计或提前泛化？ 审查者不仅要防"设计不足"（逻辑直接暴露、缺乏抽象），也要防"过度设计"（为了未来可能的需求加了复杂的抽象层，当前需求反而变难实现了）。好的设计是满足当前需求前提下的最小复杂度，不是对未来所有可能性的穷尽覆盖。
3.2 正确性与安全性
边界条件是否被处理？ 空输入、空集合、最大值、最小值、并发情况——这些是 bug 的高发地带。审查者需要问：这段代码在各种边界条件下会怎么表现？有没有可能因为没有处理空值而抛出 NullPointerException？有没有可能因为整数溢出而产生错误的计算结果？
并发场景是否安全？ 如果这段代码涉及共享状态，是否正确处理了并发访问？有没有竞态条件？锁的粒度是否合适——太大导致性能问题，太小导致并发不安全？特别是在多线程环境或分布式系统中，并发问题往往在测试环境无法复现，只在生产环境的高并发场景下才暴露。
错误处理是否完善？ 错误是被吞掉了还是被正确传播了？错误信息是否包含足够的上下文（但不包含敏感信息）？是否有 fallback 机制——当某个依赖不可用时，系统能否优雅降级而不是直接崩溃？
是否有安全漏洞？ 注入攻击（SQL注入、XSS、命令注入）、认证和授权问题、敏感数据泄露、加密算法误用——这些是安全审查的重点。即使代码本身没有明显的漏洞，设计决策也可能引入安全风险：比如把内部接口暴露给了外部网络、把日志输出到了不应该去的地方、把敏感数据写入了不应该有的地方。
依赖是否可信？ 新增的依赖是否来自可信的来源？是否有已知的漏洞？依赖的版本是否稳定？特别是引入新的第三方库时，需要评估：这个库是否被维护、是否有社区支持、是否适合在这个安全等级的场景下使用。
3.3 可读性与可维护性
代码是否自解释？ 好的代码应该能在没有注释的情况下被理解。如果审查者看完一段代码后还需要问作者"这段是做什么的"，说明代码本身的可读性不够。注释应该解释"为什么这样写"，而不是"写了什么"——代码本身已经表达了"写了什么"，注释的价值在于解释那些不明显的决策背景。
命名是否准确？ 变量名、函数名、类名是否反映了实体的语义？有没有用 data、temp、result 这种泛泛的名字？函数名是否清晰地表达了函数的职责（一个函数最好只做一件事）？命名是代码可读性最基础也是最重要的因素——改一个好名字往往比重构一段代码更有价值。
是否有重复代码？ DRY（Don't Repeat Yourself）原则不是教条，但重复代码确实需要成本：修改一处逻辑需要在多处同步修改、测试覆盖不完整可能导致部分重复代码未被更新。审查者需要判断：这段重复是必要的（比如说两个相似但独立的需求，各自的演进路径可能不同），还是应该抽象成公共逻辑？
测试是否充分？ 这里的"测试"不单指单元测试覆盖率，而是测试的质量。覆盖率高的测试不一定有效——测试是否覆盖了有意义的场景？测试是否测试了行为而不是实现细节（避免脆弱的测试）？测试的命名是否表达了测试的意图？集成测试是否覆盖了组件之间的交互？
3.4 性能与资源
是否有明显的性能问题？ 审查阶段不需要做精确的性能测试，但应该能识别出明显的性能反模式：在循环里发起网络请求（N+1 问题）、在热路径上做不必要的内存分配、在高频调用的函数里加了同步的磁盘 I/O。这些问题在功能层面是对的，但在性能敏感的路径上会成为瓶颈。
资源管理是否正确？ 数据库连接、网络连接、文件句柄、锁——这些资源是否在所有代码路径上都被正确释放？有没有 try-with-resources 或者 defer 之类的机制来保证资源释放？资源泄漏往往是长时间运行后才暴露的问题，在审查阶段捕获的成本远低于在线上排查。
是否有缓存相关的风险？ 引入缓存时，需要考虑：缓存失效策略是什么？是否会导致数据不一致？缓存的内存上限是多少、是否会 OOM？是否有缓存穿透（大量请求查询不存在的数据）和缓存雪崩（大量缓存同时过期）的风险？
四、工具与流程设计
4.1 代码审查工具的选择
工具是代码审查体验的基础设施。工具选得好，审查流程就顺畅；工具选得差，审查体验就是折磨。主流的代码审查工具已经非常成熟，GitHub Pull Request、GitLab Merge Request、Bitbucket Pull Request 是最常见的三个选项，它们的核心功能差距不大，选哪个主要看团队已有的基础设施。
但工具的功能只是下限，选择工具更重要的是看团队如何使用工具，而不是工具本身提供了多少功能。
PR 描述的模板化是一个被严重低估的功能。一个好的 PR 描述模板应该包含：这段代码解决了什么问题（对应"正确的问题"审查）、有哪些变更（让审查者快速了解上下文）、如何测试（让审查者知道要关注哪些场景）、有没有需要审查者特别注意的地方（作者主动标注盲区）。有了模板，作者在写 PR 描述时就有了一个思考框架，不会发出一段"请审查"的空描述。
审查状态的流转也是值得设计的环节。PR 从 open 到 merged，之间有多个状态：待审查、审查中、需要修改、待合并。有些团队的 PR 状态是混乱的——PR 发出去没人知道要审、审查意见提完了不知道作者有没有看到、作者修完了不知道要不要重新通知审查者。这些混乱背后是流程设计的缺失，而不是工具的问题。一个简单的做法是约定：审查意见发布后，作者必须回复"已修改"或者"不修改+理由"；修改完成后，必须主动 tag 审查者。这些流程约定比任何工具功能都重要。
审查评论的分类是另一个值得考虑的设计。很多团队在审查中混杂了所有类型的意见——格式问题、设计问题、逻辑问题、安全问题——全部混在一起，审查者和作者都很难梳理。一种有效的做法是用标签或前缀来分类审查意见：nit: 表示小问题（不必阻止合入）、question: 表示需要澄清、suggestion: 表示建议修改、blocker: 表示必须修改。这种约定让意见的优先级一目了然，避免在次要问题上浪费时间争论。
4.2 CI/CD 与审查的集成
代码审查不应该孤立地存在，它需要和 CI/CD 流程紧密配合。好的集成能减少人工审查的负担，把有限的审查精力集中在真正需要人类判断的事情上。
自动化的质量门禁是第一步。代码风格检查（linter）、静态分析（SAST）、依赖漏洞扫描、单元测试——这些都应该由 CI 自动执行，审查者不需要在这些问题上花费精力。如果审查意见里有"格式不对"、"缩进有问题"、"这行有多余的空格"，说明 CI 的 linter 配置不完整或者没有强制执行。
自动化的可读性辅助也很重要。大型 PR 的 diff 非常难读——几百行变更密密麻麻，看不出重点。现代代码托管平台提供了"PR 文件树"的功能，能看到变更涉及哪些文件、每个文件的变更量有多大。这个信息对审查者判断审查优先级很有帮助：变更量大的文件是重点，变更量小的文件可以快速扫过。
自动化的问题检测是更高级的实践。现在有一些静态分析工具能检测常见的安全漏洞、性能问题、代码异味的模式（比如圈复杂度过高、重复代码块、过于深层的嵌套）。把这些工具集成到 CI 中，可以在代码合入之前就捕获一部分审查者需要关注的问题。代表性的工具有 SonarQube（代码异味和安全）、Semgrep（自定义规则的安全分析）、Snyk（依赖漏洞扫描）。
4.3 审查流程的设计
审查流程不是一成不变的，不同类型的变更应该有不同的审查要求。这种差异化能显著提升审查效率——让简单变更快速通过，让复杂变更获得足够的关注。
基于变更复杂度的分层审查是一个实用的设计原则：文档和测试文件的变更，可以走快速通道（一个审查者批准即可，不需要深入审查）；常规功能代码，需要至少一个审查者批准；架构性改动、涉及安全或性能的代码、需要至少两个审查者批准，或者明确指定由架构师或安全工程师审批；高风险操作（如数据库迁移、权限变更、配置变更），需要团队范围内的通知和额外的审查者数量。
这种分层设计需要和分支保护规则配合。在 GitHub/GitLab 的分支保护设置里，可以配置哪些类型的 PR 需要哪些审批条件——这是把流程约定变成自动化执行的关键。没有分支保护规则，流程约定就只是约定，无法保证被执行。
审查延迟的监控是另一个被忽视的实践。团队应该定期看看 PR 的平均审查时间分布——有多少 PR 在 1 小时内得到第一次审查？有多少超过 24 小时？这些数据能反映团队审查效率的真实状态。如果大多数 PR 的审查延迟超过 24 小时，说明团队的审查资源不足，需要考虑增加审查者数量、简化变更规模、或者重新调整团队对审查优先级的认知。
五、团队文化：代码审查的土壤
工具和流程是代码审查的骨架，文化才是代码审查的血肉。再好的审查清单、再先进的工具，如果团队文化不支持，审查就会变成走过场的形式主义。代码审查文化的建设，是团队工程成熟度的重要标志。
5.1 建立对审查的共识
团队成员对"代码审查的目的是什么"的理解应该是基本一致的。如果有人认为审查是"上级检查下级的工作"，有人认为是"同行之间的技术交流"，有人认为是"质量保证的流程环节"——这些不同的理解会导致对审查行为期待的冲突。
一个团队应该在早期就这些基本问题达成共识：审查者和作者的关系是平等的还是不对等的？审查意见是"必须修复"还是"建议参考"？对审查意见有异议时，应该如何处理（讨论、争论、还是 escalation 到其他人）？这些问题的答案没有绝对的对错，但团队必须有一致的理解，否则审查过程就会充满摩擦。
定期回顾审查实践是保持共识的有效方式。每个季度或者每半年，团队可以专门拿出一次技术回顾会议，讨论过去一段时间的审查实践：有没有遇到特别难处理的审查情况？有没有审查意见引发过争议或不快？有没有审查流程拖慢了开发速度？通过具体的案例讨论，团队可以校准对审查的共同期待，而不是依赖每个人的个体理解和猜测。
5.2 让审查变成学习机会
代码审查最被低估的价值，不是"找到 bug"，而是"互相学习"。当一个高级工程师审查初级工程师的代码时，审查者可以传递经验和最佳实践；当一个初级工程师审查高级工程师的代码时，审查者可以学到系统的设计思路和架构决策。后者往往被忽视——很多人认为审查是"上级对下级的指导"，忽略了"下级对上级的反馈"这个同等重要的维度。
把审查当成学习机会，需要两个前提：第一，初级工程师敢提审查意见。如果团队的文化是"级别低的工程师提的意见容易被忽略"，初级工程师就会逐渐失去提意见的动力，审查就变成了单向的指导。第二，高级工程师愿意接受审查。有些高级工程师不愿意让自己的代码被初级工程师审查，觉得这是对自己权威的挑战。这种心态会破坏审查的协作本质。
一个健康的审查文化里，没有人的代码是不可审查的。不管是刚入职的新人还是团队的首席工程师，每一段代码都值得被认真审视。这个原则说起来简单，但真正做到需要团队里的每个人——特别是资深成员——有足够的自信和开放心态。
5.3 审查反馈的质量
审查意见的质量，直接决定了审查的效率和作者的感受。低质量的审查意见有几个典型特征：太模糊（"这段代码不好"）、太主观（"我不喜欢这样写"）、太技术细节（纠结于格式和风格而忽略设计和逻辑）、太长（洋洋洒洒几百字但没有指出核心问题）。
高质量的审查意见有以下几个要素：
指出问题所在，而不是给出解决方案。 "这里可能有空指针风险，因为 X 不保证非空"比"改成 if (x != null)"更好。前者让作者理解问题的本质，后者只是给出了一个具体的修改。理解问题本质的作者，能在类似的地方自主避免同类问题；只看到具体修改的作者，下次换一个场景可能又犯同样的错误。
解释"为什么"，而不是只说"是什么"。 "这个函数为什么用递归而不是循环"比"不要用递归"更有价值。"为什么"让作者理解背后的推理过程，"是什么"只是指令。理解了推理过程的作者，下次遇到类似决策时能自己做判断；只收到指令的作者，每次遇到类似情况都要等审查意见。
用事实和证据支持观点，而不是个人偏好。 "这种写法在 Y 语言社区被认为是反模式，因为 Z"比"我不喜欢这种写法"更有说服力。前者基于共识和事实，后者基于个人感受。当然，有些时候确实只是个人偏好——这种情况下应该坦诚说明"这是我的个人偏好，你可以忽略"。
控制审查意见的数量和优先级。 审查不是要把代码改到完美——代码在绝大多数情况下不可能完美，审查也不可能穷尽所有问题。审查者应该区分"必须修改才能合入"和"如果方便的话可以改"两类意见，不要把所有的意见都标记为必改。如果一个 PR 的必改意见超过五个，可能说明这次变更的规模已经超出了合理范围，应该拆分成更小的变更。
5.4 心理安全感与审查的边界
心理安全感（Psychological Safety）是一个团队能否进行有效代码审查的底层条件。在一个心理安全感不足的团队里，审查者和作者都在防御：作者担心自己的代码被批评，会过度保护自己的实现；审查者担心自己的意见引发冲突，会过度委婉以至于失去了意义。
心理安全感不是说"我们不能批评代码"——恰恰相反，有效的批评是心理安全感高的表现，因为它意味着团队成员相信"我的批评是出于对代码的关心，而不是对人的攻击"。心理安全感低的团队，成员之间缺乏信任，批评和被批评都会触发防御反应。
建立心理安全感需要团队的长期积累，但有几个具体的实践可以加速这个过程：
作者主动降低审查门槛。在 PR 描述中主动说明自己已知的不完美之处，比如"这里的实现我知道不是最优的，因为时间关系先这样，后续会优化"——这种坦诚能减少审查者的批评冲动，也给审查者一个"这里不是问题"的参考。
审查者先肯定，再建议。先指出代码中做得好的一两个地方，再说需要改进的地方——这不是虚伪的客套，而是心理学上的"换位"策略：先表达理解和认可，再提出修改建议，作者更容易接受。
团队明确"审查失败"的数据定义。如果一个 bug 漏到了生产环境，团队不应该自动怪罪审查者。审查是降低风险的手段，不是消除风险的保证。如果每次线上问题都引发"审查者为什么没发现"的追责，审查者就会走向保守：为了避免责任，要么拒绝一切变更，要么完全放行不做实质性审查——两种都是审查实践的死亡。
5.5 审查的可持续性
代码审查是一个高频、长期的活动——几乎每一次代码提交都要经过审查。这种高频性意味着，审查必须是一件可持续的事情，不能靠消耗审查者的精力来维持。
轮值审查制度是保持可持续性的常见做法。团队成员轮流担任"审查负责人"，负责在特定时间段内优先响应 PR 审查请求。这个制度的好处是分散了审查负担，避免了总是"那几个最靠谱的人"被淹没在审查请求中的情况。轮值制度的挑战是：不同审查者的质量可能不一致，解决办法是在团队内部分享高质量的审查意见作为参考范本。
审查时间保护也很重要。如果工程师在深度编码时被频繁的审查请求打断，编码效率会大幅下降。一个有效的做法是约定"审查响应时间"而不是"即时响应"——比如，审查者应在 4 小时内响应审查请求，但不需要立即放下手头的工作去审查。让审查请求进入一个队列，审查者在适当的时刻集中处理，既保证了响应速度，又保护了深度工作的时间块。
审查量的合理分配是可持续性的关键。一个人的审查量不应该超过其工作时间的 15%-20%。如果一个工程师每天收到大量的审查请求，说明团队规模或者代码库的组织方式有问题——可能需要更多的审查者，或者需要通过拆分代码库来减少单个代码库上的审查压力。
六、代码审查与其他质量实践的关系
代码审查不是孤立的，它需要和团队的其他质量保障实践相互配合。理解这些关系，能帮助团队更合理地分配质量保障的资源。
代码审查不能替代测试。 有些人觉得"反正有代码审查，测试可以少写一点"——这是一个危险的误解。代码审查能发现设计层面的问题、逻辑错误、安全漏洞，但无法穷尽所有运行时行为。测试的价值在于自动化地验证代码的行为，特别是在边界条件和异常场景下。审查和测试是互补的，不是替代的。
代码审查不能替代架构评审。 对于架构性的重大决策——新的技术选型、新增的核心模块、数据库 schema 变更——代码审查的粒度是不够的。架构评审需要更广泛的参与、更长的时间窗口、更抽象的讨论。这些决策应该在代码审查之前完成，审查的是架构决策的实现，而不是架构决策本身。
代码审查对新人融入的作用。 代码审查是新工程师融入团队的重要渠道。通过阅读团队其他人的代码和审查意见，新工程师能快速了解团队的技术栈、编码风格、设计原则。在新工程师入职的前几周，安排经验丰富的工程师审查他们的代码，同时让他们审查（只评论，不批准）其他人的代码——这个过程本身就是最高效的学习方式。
七、总结
代码审查是软件工程中最接近"团队协作本质"的活动：它要求作者清晰地表达自己的意图，要求审查者理解作者的工作上下文，要求双方用技术事实而非个人偏好来讨论问题，要求团队建立对质量的共同期待。这一切都不是一个工具能解决的，也不是一套流程能自动产生的——它需要团队的持续投入和不断校准。
回到最初的问题：代码审查在解决什么问题？我认为核心是缩小认知差距、传播专业知识、建立质量共识。代码审查的最终目标，不是让每一行代码都完美，而是让团队成为一个更好的整体——每个人都了解系统的更多部分，每段代码都经过多双眼睛的审视，每个质量决策都被团队所理解。当代码审查做到这个程度，它就不再是一个负担，而是一种团队能力的体现。
最后，有一句话值得每一个参与代码审查的人记住：代码审查不是在证明谁更聪明，而是在确保系统长期健康地演进。抱着这个心态参与审查，代码审查就会从一场评判变成一次协作——对作者如此，对审查者亦然。
代码审查没有银弹。这篇文章提供的框架和清单是起点，而不是终点。每个团队都有自己独特的技术栈、开发节奏、团队文化，代码审查的最佳实践必须适应这些具体的约束。重要的不是照搬某套流程，而是理解代码审查背后的原理，然后找到适合自己团队的方式。持续审视和改进自己的审查实践，本身就是代码审查精神的体现。