code-review

代码审查

原则

• 只审查要求审查的内容。如果范围不明确，请先询问。
• 深入检查，精简报告。尝试用真实的输入、状态和操作序列让代码出错。针对代码提出质疑，不针对作者。
• “没有值得修改的内容”也是有效结论。简短的审查也是好的审查。
• 除非收到要求，否则不要修改代码。

什么情况算作问题

只有满足以下所有条件，才报告问题：

• 存在导致故障或危害的具体方式。
• 这种情况确实可能发生。
• 对用户、数据、安全或维护有实际影响。
• 修复所消除的风险或复杂性，大于修复带来的风险或复杂性。

绝不报告罕见的边缘情况、假设性的规模问题、风格偏好、没有实际影响的重复代码、辅助函数或文件的数量，也不提出让代码“更灵活”的想法。

检查范围

根据改动内容，检查适用的方面：

• 正确性： 错误的假设、错误处理、竞态和异步顺序、状态与清理，以及丢失原有行为的重构。
• 安全性： 身份验证与授权、注入、对客户端输入的信任，以及代码、日志或 URL 中的密钥或个人数据。
• 库： 根据已安装版本的类型定义和文档检查行为，不要凭记忆判断。
• 测试： 测试是否保障了重要行为？指出对真实行为覆盖不足、断言实现细节、过度模拟，以及未能验证任何内容却仍能通过的测试。不要为了测试而要求测试。
• 数据与 API： 破坏性变更、迁移，以及不适合安全重试的副作用重试。
• UI： 实际可行时，使用 agent-browser 在真实浏览器中测试改动涉及的界面。
• 复杂性： 不必要的层和包装器、只用一次的辅助函数、推测性的选项或通用 API，以及针对不可能情况的防御性代码。优先顺序为：删除、直接使用、本地辅助函数、共享抽象、新抽象。
• 计划和 ADR： 如果改动是按计划实施的，请报告缺失或未经验证的计划任务，以及与已接受的 ADR 冲突的内容。

报告

在聊天中按严重程度从高到低报告问题。每项问题都要说明严重程度（高、中或低）、file:line、问题会导致什么后果及发生条件，以及最小修复方案。不要报告细枝末节。如果有许多次要问题，请用一行概述，而不要逐条列出。