评审流程与目标

• 理解评审与自动化测试/静态分析的互补关系
• 认识到评审的长期价值高于一次性缺陷发现
• 能够对比不同目标在不同阶段的权重

四个目标并非固定优先级，而是分层且相互促进的。普遍共识是"设计对齐"与"知识共享"是长期价值最高的目标，因为它们塑造团队整体能力与架构一致性；"发现缺陷"虽是评审最直接的目的，但自动化（CI、静态分析、单元测试）更擅长捕获确定性缺陷，人工评审应把注意力分配给自动化难以覆盖的设计问题与语义缺陷；"规范执行"应尽量下沉到 lint/CI 强制，减少人工重复审查。优先级排序上，可理解为"设计质量 > 知识共享 ≈ 缺陷发现 > 规范执行"，且评审者应主动区分"机器能做的事"与"只有人能做对的事"。

若把评审定位为"抓 bug"，则大 PR 与逐行审查会占据所有精力，反而牺牲设计讨论与知识传递。正确做法是把评审当作团队学习与架构对齐的机制，缺陷发现作为副产品。这也是为什么经验丰富的团队会让评审"先看设计意图、次看实现、最后看细节"。

• 理解心理安全对反馈质量与团队透明度的作用
• 掌握建设性反馈的表达方式
• 认识安全氛围如何影响缺陷发现率

心理安全指团队成员相信提出疑问、承认错误、暴露弱点不会遭到惩罚或羞辱。在评审中，心理安全能让作者坦然暴露"未完成的思路"、让评审者敢于提出"可能不对但值得商榷"的意见，从而提升真实反馈量。营造方式包括：把评审定义为"针对代码而非人"、用提问代替命令、承认自己也可能出错、对新手强调学习导向、公开感谢高质量的讨论而非单纯批评。安全氛围不足时，作者会倾向防御性辩解，评审者会倾向沉默或只报喜不报忧，最终缺陷逃逸率上升。

心理安全是 Google 等组织研究反复验证的高绩效团队特征。评审若让人感到"被审判"，反馈就会失真——要么枯萎、要么变成找茬。建设性反馈的关键是让作者感到"被帮助"而非"被评判"。

• 理解异步评审对注意力与可追溯性的优势
• 识别必须同步的场景（歧义、设计分歧、敏感反馈）
• 平衡异步的低打扰与同步的高效

评审默认采取异步优先：评审者在自己专注的时间段内完整阅读 diff、写下可追溯的评论，避免打断双方工作流，也给作者思考时间。异步的边界在于：当出现无法通过文字澄清的歧义、设计方向上的根本分歧、或涉及敏感反馈容易引发误解时，应升级为同步（视频/语音/面对面）讨论，并把结论回写到 PR 线程以保持可追溯。同步讨论的高效性应服务于"快速收敛"，而非替代异步的深度阅读。

异步优先符合分布式团队与"深度工作"的现实，但纯异步会在真正需要对话时反复低效拉锯。判断标准是"文字能否在合理轮次内达成共识"——不能则同步。

• 理解认知负荷与缺陷发现率的关系
• 掌握小 PR 的拆解方法与收益
• 认识大 PR 的隐性成本

研究（如 SmartBear 基于 Cisco 的数据）表明，评审的认知负荷随变更规模增长而非线性上升：超过约 400 行或在 200-400 行范围内，缺陷发现率随行数增加而显著下降。小 PR 让评审者能完整理解上下文、逐行推敲，反馈更具体、更及时，合并与回滚风险也降低。轻量 PR 的本质是在"评审深度"与"变更吞吐"之间取得平衡，它要求乐于把变更拆成可独立理解、独立验证的小块。

认知负荷是核心机制——大 PR 迫使评审者同时维护大量上下文，导致注意力分散、漏检增加。小 PR 让"上下文完整加载"成为可能，是诸多评审质量实践（分阶段、按功能垂直切片）的共同理论基础。

• 理解可执行建议的特征（具体、有依据、给出方案）
• 识别并克制个人偏好的表达
• 掌握反馈的质量过滤标准

高质量反馈应满足"可执行性"：指向具体位置、说明问题、给出可选方案或解释理由，让作者能据此直接行动。相反，个人偏好（如"我更喜欢用这个命名""通常我们这样写"）缺乏客观依据，无法转化为明确的改进，反而引入噪音。区分标准是：是否有一个可验证的改进方向、是否基于规范/模式/可测性等客观理由。评审者应主动自问"这条意见作者能据此改吗？改了对吗？"——不能则降级为 nit 或删除。团队还可通过规范与共享样例把"可执行"的期望显式化。

反馈质量是评审价值的关键变量。可执行建议让作者感知到"被帮助"，个人偏好则让评审显得主观武断。审慎表达偏好是评审者成熟度的体现，也避免"自行车棚效应"。

• 理解评审注意力的分层分配
• 认识到风格与低级规范应由自动化处理
• 把握架构与业务逻辑的深度审查

评审应把注意力集中在"自动化难以覆盖"的高价值层面：架构正确性、设计合理性、业务逻辑语义、并发与安全、错误处理与边界条件。风格类问题（命名习惯、格式、魔法数）应尽量交给 lint/format/CI 强制执行，评审者不必逐条评论命名问题，避免分散注意力。架构与业务逻辑是评审的核心，因为它们决定代码的正确性与可维护性，且无法被机器可靠判断。原则是"该看设计意图与语义，不该看可自动化的表面问题"。

评审范围决定了注意力分配。若把大量精力放在风格争论上，会挤占对架构与语义的审查，这就是"自行车棚效应"。分工明确：机器管风格低层，人管语义高层。

• 理解三类合并条件的独立作用
• 掌握在 GitHub/GitLab 中配置分支保护
• 认识门禁对质量底线的保障

合并门禁由三类条件组合而成：最少批准数（如 1-2 个 reviewer 批准）保证变更经过至少一次独立审阅；必需评审者（CODEOWNERS 匹配的 owner 必须批准）保证受影响模块的负责人把关；CI 全绿（测试、构建、静态分析通过）保证自动化质量底线。三者组合是在 GitHub/GitLab 分支保护规则中配置的，通常"需要至少 N 个批准"且"code owner 必须批准"且"状态检查必须通过"同时满足才允许合并。这种显式化把"形式上的评审"变成"可执行的流水线门禁"。

显式门禁让"应评审"变成"必须评审"，减少绕过。但门禁只是底线，避免过度依赖——过多的批准要求会拖慢节奏，需按风险分级调整。

• 理解通用项与领域项的分层
• 认识清单过长的失效机制
• 掌握按变更类型动态加载清单的思想

分层设计把清单分为通用层（命名、测试、错误处理、边界条件等所有变更都适用的项）与领域层（按技术栈或业务类型加载的项，如涉及数据库时检查 SQL 注入、涉及并发时检查线程安全）。关键在于"按需加载"而非全部堆叠：当一个列举出所有可能项，评审者会陷入逐项勾选的形式化，忽略真正的设计问题。通过模板/机器人按变更特征自动附加对应领域的清单，能保持清单精简且聚焦。经验法则是通用层控制在 5-10 项，领域层按触发条件动态补充。

清单失效的机制是"清单过长→勾选疲劳→形式化→漏掉设计"。分层+按需加载让清单成为"决策辅助"而非"应付流程"，是评审质量的保障。

• 理解自我评审是评审流程的第一道关口
• 掌握自审清单的关键项
• 认识自审对评审者负担的降低

作者自我评审是在提交前自己通读一遍变更，检查清单通常包括：是否符合设计意图与现有架构、是否有死代码或未使用变量、命名是否清晰、错误处理与边界条件是否完备、测试是否覆盖关键路径且能证明行为、是否遗漏了 TODO 或临时代码、diff 是否包含无关改动（如多余格式化）、PR 描述是否说明了动机与测试方式。自审能显著降低评审者的低价值评论量，让评审聚焦于真正需要第二个大脑的问题。提交前自审也被视为对评审者的尊重。

自我评审拦截"低级错误"，把评审者从"帮忙找拼写错误"中解放出来。它体现"作者对质量负责"的理念，评审是对已自审变更的补充而非替代。

• 理解首过时延对变更新鲜度的影响
• 认识快速反馈对开发节奏与合并速度的作用
• 掌握首过 SLA 的设定

快速首过指评审者在 PR 提交后尽快（通常 24 小时内）完成第一遍阅读并给出初步反馈。其价值在于：反馈越快，作者对变更的上下文越新鲜，修复成本越低；同时避免 PR 长时间滞留导致代码腐化、合并冲突与多 PR 堆积。首过不要求一次审完，而是尽快给出方向性反馈，让作者能并行推进。团队常把它设为评审 SLA（如时延 < 24h），并配合负载均衡避免瓶颈。

变更"新鲜度"是关键——延迟评审会让作者记忆模糊、上下文损耗，甚至绕过多改动。快速首过是流动效率（Flow）的体现，与批量大小、评审时延等指标直接相关。

• 理解模板的作用（引导作者提供必要上下文）
• 掌握模板的关键字段
• 认识模板与评审流程的衔接

pull_request_template.md 是仓库内配置的 PR 描述模板，引导作者在提交时提供评审所需的关键上下文：变更动机与解决的问题、实现方案概述、对现有行为的影响、测试方式与结果、相关链接（issue/设计文档）、可能的回滚影响。好的模板让评审者无需在代码中猜测意图，降低理解成本，也便于后期检索。设计时应避免字段过多导致作者敷衍填写，保持在"够用、精简"。

PR 描述是评审的"预期建立"入口。模板把"什么样的描述算好"显式化，提升作者与评审者的透明度，是低成本高收益的流程改进。

• 理解 DoD 的多维验收标准
• 认识 DoD 与评审/测试/文档的联动
• 掌握避免"能跑就行"的机制

DoD 是团队定义的"任务完成"的显式标准，通常包含：代码通过评审并合并、必须的测试已编写且通过、无遗留的阻断性问题、相关文档/日志更新、符合编码规范、关键路径可观测。它把"能跑"提升为"可交付"，通过合并门禁与 checklist 强制联动：评审通过、CI 全绿、文档变更入库都是 DoD 的一部分。DoD 防止"代码能跑就算完成"的短视，因为运行正确只是交付的起点，可维护性、可测试性与可观测性同样重要。

DoD 把隐性的完成标准显式化，减少团队成员对"完成"的不同理解。它让测试、评审、文档等支撑工作获得同等权重，避免被赶工牺牲。

• 理解 PR 各状态的含义与流转条件
• 掌握用分支保护与机器人自动化状态门禁
• 认识合并纪律的保障

PR 生命周期状态通常包括 draft（草稿，未请求评审）、in-review（评审中）、changes-requested（需修改）、approved（已批准）、merged（已合并）。状态流转由规则驱动：draft→in-review 需作者主动请求；评审给出 blocking 意见时进入 changes-requested；所有条件满足进入 approved；approved 后新提交会重置状态（stale review）需重新批准。自动化方面，分支保护规则强制"未批准不可合并""CI 未绿不可合并"，机器人可在批准后自动合并或在新提交时撤销批准。这套状态机+自动化把"合并纪律"变成不可绕过的流程。

状态机显式化使 PR 流程可预测、可审计。关键在"批准≠可无限塞变更"——新提交需重新批准，防止批准的变更被悄悄改坏。

• 理解"建立预期"的认知策略
• 掌握先读描述/测试再读 diff 的顺序价值
• 认识缺陷发现率的提升机制

推荐的阅读顺序是：先读 PR 描述（理解动机与范围）与新增测试用例（理解预期行为），再读 diff 实现。理由是"先建立预期、再验证实现"——测试用例描述了"应该发生什么"，评审者在读实现时能对照预期检查"是否真的做到了"，从而更易发现行为偏差、遗漏分支与边界缺失。这比漫无目的地逐行读代码更聚焦，能系统性提升缺陷发现率。测试还是"活文档"，能揭示作者对需求的真实理解。

认知上，预期先行为实现提供了"对照组"。没有预期时，评审者容易顺着代码"怎么实现都行"的惯性走，漏掉与需求不符的偏差。测试用例正是预期的最可靠载体。

• 理解机器可判定与人工判定的边界
• 掌握清单内容的下沉策略
• 认识两者结合的评审流程

确定性、可判定的规则（格式、命名、无未使用变量、静态安全检查、覆盖率阈值）应交给 lint/format/CI 强制执行，因为机器可靠、无疲劳，且能在合并前阻断。需要上下文、语义判断的项（架构合理性、设计取舍、并发正确性、业务语义、可维护性）必须保留人工评审，因为机器无法理解意图。职责切分的原则是"凡机器能可靠判定的，就下沉；人工只做机器做不了的高价值判断"。这样既减少评审噪音，又让评审聚焦于真正的设计问题。

清单人工化的代价是"逐项勾选疲劳"与"噪声"。把可判定项下沉到自动化，让清单成为"人机协作"的产物——机器管确定性问题，人管语义问题。

• 理解评审度量指标的分类
• 认识先行指标与滞后指标的区别
• 掌握度量组合解读

评审度量包括：覆盖率（多少 PR 实际经过评审、多少代码变更被评审覆盖）、周期（time-to-first-review、评审时延、批准到合并时间）、缺陷（缺陷逃逸率、评审密度 defects/KLOC、评审轮次）。这些指标可分为先行指标（评审周期、返工率，反映当前流程健康度）与滞后指标（线上缺陷，反映最终质量）。度量应组合解读而非单一使用——例如高覆盖率但零评论可能意味着橡皮图章式评审。度量的目的是改进流程而非考核个人，需防止被滥用（古德哈特定律）。

度量的价值在于"发现流程瓶颈"而非"给个人打分"。组合解读能揭示"表面合规、实际失效"的评审剧场，是评审质量改进的数据基础。

• 理解两种模式的时间点差异（事前 vs 事后）
• 认识两者质量与成本特征
• 掌握按场景选择的原则

评审是"异步、事后"的协作——变更完成后由他人审查，适合单人高效产出、受限于 reviewer 可用性；结对是"同步、事前"的协作——两人实时编写，缺陷在产生时即被拦截，适合复杂问题、知识传递与新人培养。取舍原则：简单/常规变更用评审，成本低；复杂/高风险/需要深度合作的任务用结对，虽同步成本高但能提前预防缺陷并传递隐性知识。两者也常结合：结对后再评审。质量上，结对前置预防、评审后置发现，互补而非互斥。

关键是时间点与同步成本。结对用"双倍人力"换"前置质量与知识共享"，评审用"异步并行的低打扰"换"后置的独立把关"。按变更复杂度与风险选择，是团队协作效率的关键。

• 理解评审反馈的闭环与知识管理
• 掌握问题分类与反哺机制
• 认识降低重复反馈的路径

建立反馈闭环：评审中反复出现的通用问题（如某个反模式、常见并发陷阱、命名误区）应被分类统计，定期（如月度）回溯，并把高频问题沉淀为编码规范、攻略文档或 FAQ，同时可转化为 lint 规则或 checklist 项。这样同类问题在下一次评审前就被预防，评审者也不必重复解释。沉淀的关键是"可搜索、可执行"——文档要被作者容易找到，规范要能转化为自动化检查。反向，评审意见的分层分类统计正是这种沉淀的输入。

知识沉淀把"个体经验"转化为"组织能力"，避免每个新人重复踩坑。它把评审从一个"发现问题的动作"升级为"不断完善规范的系统"。