| 原则 | 先理解再判断、评论指向代码而非作者、给可执行建议 |
|---|---|
| 高频场景 | 设计分歧、历史包袱、紧急修复 |
| 升级方式 | 分歧较大时改为同步沟通，把结论写回 PR |
表述对照
表述对照
差：这写法太差了
好：这个实现每次请求都会全表扫描，数据量上来会有性能问题，
能否改为按 id 查询？这里是我的参考写法：…在公开仓库评论前先确认语气适合公开场合；情绪化措辞会长期留存在历史里。
评审沟通的语气与方式
对事不对人：询问意图、给出依据、提出替代方案；把「你这样不对」换成「这里如果输入为空会怎样？」更容易达成共识。
易错点
- 用反问句表达否定容易被读成不满，直接说明问题与期待更有效
- 在 PR 里争论与本次变更无关的历史设计，应另开 Issue 讨论
数据来源与参考
- Google Engineering Practices：The Standard of Code Review
- GitHub Docs：Reviewing changes