作者走查是什么
作者走查（walkthrough）是作者向评审者当面讲解改动的形式：先讲背景与设计目标，再进入结构与关键代码。它适合大型或高复杂度的改动，准备得当时常能一次抵掉好几轮文字往来。
基本信息
| 形式 | 作者主讲，评审者现场提问与讨论 |
|---|---|
| 时长建议 | 控制在 30 分钟以内 |
| 讲解顺序 | 先背景与目标，再结构变化，最后过关键代码 |
| 产出 | 当场记录的决议与遗留问题，回写到评审里 |
典型使用场景
- 跨团队接口变更：让相关方在同一场里对齐
- 大型重构：用讲解替代几百行的逐行阅读
- 架构敏感改动：先对齐设计取舍，再看实现
- 新人主导的改动：作者在场回应疑问，减少往返
- 评审长期卡住：当面讲一遍，通常比继续打字更快
准备走查要做的事
- 列出改动清单与设计要点
- 标出自己最不确定的几处，主动请评审者重点看
- 准备可运行的演示或关键路径用例
- 约定时间盒，超时就收尾并另约后续
走查提纲模板
走查提纲模板
1. 背景：这次改动解决什么问题，影响哪些调用方。
2. 目标：哪些行为变化是预期的，哪些必须保持不变。
3. 结构：新增与修改的模块，依赖方向如何变化。
4. 关键代码：走一遍主路径与失败路径。
5. 疑难点：明确列出想听意见的几处。走查与逐行评审的差别
| 维度 | 走查 | 逐行评审 |
|---|---|---|
| 强项 | 对齐设计意图与背景 | 核对实现细节与边界 |
| 弱项 | 细节容易被带过 | 大改动阅读成本高 |
| 记录 | 当场写结论，容易遗漏 | 平台自动留存 |
在评审中怎么用
- 走查结论当场写进评审，不要只留在聊天记录里
- 讲不清的部分明确标注需要作者补文档
- 会后把遗留问题拆成任务并指定负责人
- 把走查内容整理进描述，供后来者查阅
走查不是通过仪式：口头讲不清的部分，评审者仍然需要亲自读代码。
走查擅长解决对齐问题，不适合替代细节核对：两件事都要做，只是顺序不同。
走查变成单向宣讲：评审者没时间深入阅读，容易产生虚假的安全感。