Code Review（代码评审）是代码合入主干或发布分支之前，由作者以外的开发者检查这次变更、讨论问题并给出结论的协作活动。它判断的是这次变更是否可读、可维护、符合团队约定、风险可控，并用明确的评审结论决定代码能否合入。下面从定义、边界、环节和相邻概念几个方面展开。
要点总览（TL;DR）
- Code Review 是代码合入主干或发布分支之前，由作者以外的开发者检查一次具体变更并给出是否允许合入结论的协作活动。
- 评审关注可读性、约定一致性、变更影响面以及测试与文档配套；性能调优方案、算法教学和评审等待指标不属于单次评审的检查范围。
- 一次评审通常包含作者提交并说明意图、评审者阅读差异并给出结论、作者修改后复审、结论达成后合入并保留记录四个环节。
- 评审与自动化测试、代码走查、结对编程的检查对象和产出不同，评审的核心产出是明确的合入结论。
- 评审通过表示变更在当前检查范围内可以合入，不代表代码没有缺陷；只签字不检查会让合入前的检查失去作用。
Code Review的直接定义
可以这样复述：Code Review 是代码合入前的变更检查活动，由作者以外的开发者阅读一次具体的代码变更，提出问题或确认无误，并给出是否允许合入的结论。
这个定义包含三个要点。第一，评审对象是一次具体的代码变更，通常以一次提交或一个合并请求为单位，而不是整个代码库。第二，评审发生在合入之前，是变更进入主干或发布分支前的一道检查。第三，评审的产出是一个结论：通过、要求修改，或在讨论后关闭这次变更。评审意见和结论与这次变更关联保存，后续可以回溯当时为什么这样改、谁确认过。
理解这个定义时，可以把 Code Review 看作一次有明确对象的同行检查：作者提交变更并说明意图，评审者基于差异内容判断这次变更是否适合进入下一环节。它既不是对作者能力的评价，也不是对整份代码的全面审计。
它检查什么，不检查什么
Code Review 关注的是这次变更本身的质量与风险。判断标准围绕变更是否适合合入展开，常见检查内容可以归为四类。
- 可读性：命名是否表意清楚，逻辑是否容易跟随，注释是否解释了必要的背景。
- 约定一致性：是否符合团队的编码规范、目录结构、接口约定和提交说明要求。
- 变更影响面：改动是否波及调用方、配置、数据或上下游模块，影响是否被识别并处理。
- 测试与文档配套：新增或修改的行为是否有对应测试，必要的说明文档是否同步更新。
相应地，有几类内容不属于 Code Review 的范围。性能调优方案的设计与验证、算法思路的教学与讲解，属于专门的技术设计与学习活动，评审环节只需判断变更是否引入了明显风险，不承担优化方案评审或算法教学的任务。评审等待时长、评审周期这类指标，属于研发流动效率与瓶颈分析的范畴，用于观察协作节奏和排队情况，不在单次评审的检查清单内。
| 类别 | 内容 | 归属 |
|---|---|---|
| 纳入评审 | 可读性、约定一致性、变更影响面、测试与文档配套 | Code Review |
| 不纳入评审 | 性能调优方案、算法设计教学 | 技术设计与学习活动 |
| 不纳入评审 | 评审等待时长、评审周期等指标 | 研发流动效率与瓶颈分析 |
这条边界有助于团队把评审讨论集中在“这次变更能不能合入”上。遇到超出范围的议题，可以另开设计讨论或专题分析，避免评审线程被拉长、结论被稀释。
一次评审由哪些环节组成
一次完整的评审通常按以下顺序推进，每个环节都有明确的角色和动作。
- 作者提交变更并说明意图：作者完成修改后发起评审，写清这次改了什么、为什么改、影响哪些部分，必要时附上验证方式。说明意图能减少评审者的猜测成本。
- 评审者阅读差异并给出结论：评审者逐段阅读变更内容，对疑问处提出问题或修改建议，最后给出通过或要求修改的结论。提出问题时应指向具体位置和具体理由。
- 作者修改后复审：作者根据意见调整代码或补充说明，再次提交。评审者确认问题已解决，结论达成一致。
- 合入并保留记录：结论为通过后，变更合入目标分支。评审意见、讨论过程和最终结论与这次变更关联保存，便于日后回溯。
角色分工上，作者对变更内容和说明负责，评审者对检查质量和结论负责。团队规模较小时，同一人可能在不同变更中交替承担两种角色，但同一次变更的评审应由作者以外的人完成，这是评审能够独立判断的前提。
当评审以工作项或合并请求的方式承载时，变更状态、评审意见和结论需要在一处可见，交接才不容易遗漏。ONES 可以把代码变更关联到对应的工作项，记录评审意见与结论，并让状态从待评审推进到已通过或已关闭，方便作者和评审者在同一处完成流转与回溯。这一衔接适用于希望把评审结论与需求、任务进度放在一起管理的团队。
与测试、走查、结对编程的区别
Code Review 常与几个相邻概念混用，它们的检查对象和产出并不相同。
| 概念 | 检查对象 | 主要产出 | 时点与形式 |
|---|---|---|---|
| Code Review | 一次具体的代码变更 | 是否允许合入的明确结论 | 变更完成后、合入前的异步检查 |
| 自动化测试 | 代码运行时的行为结果 | 通过或失败的验证信号 | 提交后自动执行，可反复运行 |
| 代码走查 | 一段代码或一个模块的整体写法 | 发现的问题与集体学习收获 | 多人参与的集体阅读，偏讨论 |
| 结对编程 | 正在编写的代码 | 实时形成的实现结果 | 两人同时编写，实时协作 |
与自动化测试的区别在于，测试验证代码运行起来行为是否符合预期，评审判断这次变更是否应该合入。测试全部通过，仍可能存在命名混乱、约定不一致或缺少说明的问题，这些需要人来判断。与代码走查的区别在于，走查偏向集体阅读和发现问题，收获常常包括经验分享；评审则围绕一次变更给出明确的合入结论。与结对编程的区别在于，结对是编写过程中的实时协作，评审是变更完成之后的检查，两者可以并存，但不能互相替代。
一个具体例子与常见误解
假设一位开发者修复了订单查询接口在空结果时返回格式不一致的问题，改动涉及一个函数和两处调用。作者提交变更，说明问题现象、修改思路，并附上新增的单元测试。评审者阅读差异后提出两点：函数名沿用了旧含义，容易误解；另一处调用方没有同步调整。作者修改命名并补齐调用方，再次提交。评审者确认后给出通过结论，变更合入。整个过程里，评审既发现了具体问题，也留下了这次修改为什么这样做的记录。
围绕这个例子，有三个常见误解值得澄清。
- 误解一：评审就是找 bug。找缺陷只是评审的一部分。评审同样关注可读性、约定一致性和影响面，很多意见属于改进建议，并不对应运行错误。
- 误解二：评审通过等于代码没有缺陷。评审通过表示这次变更在当前检查范围内可以合入，不代表代码不存在任何问题。测试、线上监控和后续维护仍在持续发现问题。
- 误解三：评审只是形式签字。有效的评审需要评审者真正阅读差异并给出有依据的结论。只签字不检查，会让合入前的这道检查失去作用，问题被推迟到更晚的阶段才暴露。
把这三点放在一起看，Code Review 的定位就清楚了：它是一次有明确对象、明确结论的合入前检查，帮助团队在变更进入主干之前完成判断和记录，同时把优化方案、指标分析等议题留给更合适的场合处理。
常见问题
评审者应该检查到什么程度才算完成一次有效的 Code Review？
有效的评审需要评审者真正阅读变更差异，并围绕这次变更是否适合合入给出有依据的结论。检查程度可以按变更影响面调整：小范围修改重点看可读性、约定一致性和测试配套；涉及调用方、配置或数据变更时，需要确认影响是否被识别和处理。评审者不必对整份代码库做全面审计，也不承担性能调优方案或算法设计的评审任务。结论应当明确，是通过、要求修改还是关闭变更，避免只留下零散评论而没有最终判断。
团队规模较小、人员紧张时，同一个人可以既提交变更又评审自己的代码吗？
同一次变更的评审应由作者以外的人完成，这是评审能够独立判断的前提。团队规模较小时，同一人可以在不同变更中交替承担作者和评审者角色，但不宜对自己提交的变更给出评审结论。如果确实缺少其他评审者，可以考虑安排交叉评审、邀请相邻模块的开发者参与，或者把变更拆小以便快速检查。评审记录与变更关联保存，也能帮助团队在人员轮换后回溯当时的判断依据。
自动化测试已经全部通过，为什么还需要人工做 Code Review？
自动化测试验证的是代码运行时的行为结果，评审判断的是这次变更是否应该合入。测试全部通过，仍可能存在命名表意不清、与团队约定不一致、缺少必要说明或影响面未被识别的问题，这些需要人来判断。两者检查的对象不同，可以并存但不能互相替代。评审通过也不等于代码没有缺陷，测试、线上监控和后续维护仍在持续发现问题。
评审意见出现分歧、作者和评审者无法达成一致时，应该怎么处理？
分歧通常来自对变更意图、影响面或约定理解不同。可以先回到变更说明，确认作者是否把改了什么、为什么改、影响哪些部分写清楚；再针对具体位置讨论理由，避免停留在笼统判断。如果涉及团队约定或跨模块影响，可以邀请相关模块的负责人参与讨论，或者把议题拆出来另开设计讨论。评审线程的目标是形成这次变更能否合入的结论，超出范围的优化方案和指标分析适合放到专门场合处理，避免评审被拉长、结论被稀释。
把评审结论和代码变更关联记录，对后续工作有什么实际帮助？
评审意见、讨论过程和最终结论与变更关联保存后，后续可以回溯当时为什么这样改、谁确认过。这对排查问题、交接工作和复盘都有帮助：新加入的成员能理解变更背景，维护时能判断某段代码是否经过检查，出现争议时也有依据可查。当评审以工作项或合并请求的方式承载时，变更状态、评审意见和结论需要在一处可见，交接才不容易遗漏。ONES 可以把代码变更关联到对应的工作项，记录评审意见与结论，并让状态从待评审推进到已通过或已关闭，方便作者和评审者在同一处完成流转与回溯。
