代码评审与协作
一、Code Review 的目的：质量、知识传播、一致性
质量：发现逻辑错误、边界遗漏、性能隐患、安全漏洞。作者容易「以为对了」；评审者以读者视角看，常能揪出「这里没判空」「那里会 N+1」等问题。知识传播：评审让更多人接触这段代码，新人能通过看 PR 学业务和实现；作者在写描述和回复评论时也会把设计说清楚，形成可追溯的讨论。一致性：命名、结构、错误处理方式等，通过 Review 统一到团队约定，避免各写各的、后期难以维护。
二、评审清单与礼仪
评审时「看什么」可以靠清单不遗漏：逻辑是否正确、边界与异常是否处理、是否有重复代码或可读性问题、命名与注释是否清晰、是否与现有架构和规范一致、测试是否足够、是否有明显性能或安全问题。团队可以把清单写进文档或 PR 模板，新人也能按图索骥。
礼仪：评审是协作，不是审判。评论要就事论事——指出「这段在 XX 情况下会怎样」而不是「你怎么写的」；分清楚建议与必须——必须改的明确说「请修改」，可选的说「建议」或「可以考虑」；肯定好的地方——设计清晰、测试到位时点个赞，对方更容易接受批评；及时响应——作者等 Review 时卡着，尽量在约定时间内（如 24 小时内）给第一轮反馈。
评审时可看的要点（示例清单）
- 逻辑与边界：正常路径与异常路径是否都正确？空值、越界、并发是否考虑？
- 可读性：命名、注释、结构是否容易理解？是否有重复可抽取？
- 一致性与规范：是否符合团队命名、目录、错误处理约定？
- 测试：改动是否有对应测试？关键路径是否覆盖？
- 安全与性能：是否有明显漏洞或低效实现？
三、异步评审与同步讨论
异步评审：评审者在 PR 上留言，作者稍后看、改、回复；不必同时在线。适合分布式团队、跨时区、或希望留下书面记录。要点：PR 描述写清「改了什么、为什么、如何验证」，方便评审者快速进入；评论尽量具体到行或段落，避免「这里有问题」却不说哪里。
同步讨论：作者与评审者实时沟通（当面、视频、语音），一起过一遍代码。适合复杂设计、争议点、或需要快速对齐时。可以「先同步讲清背景与设计，再异步细看 diff」；讨论结论最好在 PR 里补一句总结，方便后来人看。
四、如何写反馈、如何接收反馈
写反馈时：说清「问题是什么、为什么是问题、建议怎么改」（若一眼能改的可以直接给建议代码）；用疑问句代替断言有时更温和（「这里是否考虑过 XX 情况？」）；区分「必须改」与「建议」；一次 PR 不要堆太多「建议」，优先关键问题，否则作者容易疲。
接收反馈时：把 Review 当成「一起把代码变好」，而不是被挑刺。有疑问就回复问清楚；不认同可以说明理由、讨论取舍；认同就改并简短回复「已改」或「采纳」；改完记得通知评审者，方便对方确认。若反馈很多，可以分批改、分批请对方再看，避免一次改到天荒地老。
写反馈
- 说清：问题是什么、为什么、建议怎么改
- 区分「必须改」与「建议」
- 肯定做得好的地方
- 具体到行或段落，避免笼统
接收反馈
- 当成「一起变好」，不必防御
- 有疑问就问，不认同可讨论
- 改完回复或 @ 评审者确认
- 反馈多时可分批改、分批请看
一句话： Code Review 的目的包括质量（发现 bug 与隐患）、知识传播（更多人理解改动）、一致性（与团队约定对齐）。用评审清单保证不遗漏要点，用礼仪保证协作顺畅（就事论事、区分必须与建议、及时响应）。异步留痕、同步讲清复杂点；写反馈要具体、接收反馈要开放，改完及时确认。
五、小结
Code Review 目的：质量、知识传播、一致性。用评审清单（逻辑、可读性、规范、测试、安全等）和礼仪（就事论事、区分必须/建议、肯定好的、及时响应）让 Review 高效且友好。异步评审适合留痕与分布式，同步讨论适合复杂设计与快速对齐。写反馈要具体、分必须与建议；接收反馈要开放、改完确认。下一章讲文档与注释：何时写、写什么，把「文档类型、注释原则、文档即代码」说细。