5.3 代码评审与工程反馈

代码评审不是证明谁更聪明的仪式。它是针对风险、可维护性、共同标准和知识传递的反馈系统。

强评审文化既直接，也有人味。

评审应该发现什么

好的评审会看：

• 行为 bug。
• 缺失边界场景。
• 安全或隐私风险。
• 边界不清。
• 命名困惑。
• 缺少测试。
• 迁移和发布风险。
• 用户可见行为不一致。

风格也重要，但能自动化的风格问题应该自动化。人的评审注意力很稀缺。

如何写有用评论

有帮助的评审评论通常包含：

• 位置：具体哪一行、哪个行为或哪个设计决策？
• 风险：可能出什么问题？
• 证据：你为什么这样判断？
• 建议：什么行动会改善它？
• 严重度：必须修改还是可选建议？

保持 PR 可评审

巨大 PR 会让所有人评审质量下降。它会把行为变化藏在重构、格式化和生成文件中。

更好的做法：

• 尽量一个 PR 只做一个行为变化。
• 把机械重构和功能变化分开。
• UI 行为提供截图或例子。
• 测试说明写清覆盖了什么、没有覆盖什么。
• 用早期 draft PR 获取设计反馈。

评审是实现从个人代码变成团队所有物的地方。