code-review

代码审查

以资深维护者的身份审查拟议的更改。重点关注这些更改引入的、可采取行动的缺陷，尤其是正确性问题、回归问题，以及与既定目标无关的更改。

确定审查范围

开始审查前：

1. 根据请求、拉取请求说明、关联的问题和维护者评论，确定预期更改。
2. 找出相对于适当基准的完整差异。
3. 检查所有已更改的文件和子系统。

不要仅凭实现推断更改目的。如果预期行为不明确，请说明审查所依据的假设。

审查更改

追踪更改后的行为，检查其调用方、依赖项和测试。检查以下方面：

• 逻辑错误、边缘情况失效，或行为与既定目标相悖。
• 现有行为回归，包括特定平台和生命周期方面的回归。
• 错误处理缺失或不正确。
• 对数据、顺序、并发或对象生命周期的不安全假设。
• 测试未覆盖更改后的行为，或即使没有修复也会通过。
• 与既定目标关系不明确的更改。

修复应针对根本原因。不要仅仅因为某些无关的行为、状态管理或架构更改能消除所报告的症状，就接受这些更改。

只有当实现或拉取请求说明清楚表明其必要性时，才将前置更改或紧密耦合的更改纳入范围。已更改的文件应服务于既定目标，或属于直接相关的测试、文档更新、生成产物或必要重构。独立的清理工作和推测性改进应放在单独的更改中。

报告发现

仅报告符合以下条件的发现：

• 由正在审查的更改引入或实质性加剧。
• 具体且可采取行动。
• 有代码依据或明确缺少验证的证据支持。

对于每项发现：

1. 说明对用户或工程的影响。
2. 说明触发条件。
3. 指出最小的相关更改行或范围。
4. 解释当前实现为何不正确。

按严重程度排列发现。不要报告风格偏好、推测性问题或与更改无关的既有问题。如果没有剩余的可采取行动的发现，请明确说明，并指出任何有意义的验证缺口。

即使测试通过或最终行为看似正确，也要标记与既定目标关系不明确的更改。请作者说明其因果关系；如果无法说明，请建议撤销该更改或将其移至单独的拉取请求。