Resources 实施手册

# 卓越代码审查实施手册 本文件包含该技能引用的详细模式、检查清单和代码示例。 ## 何时使用此技能 - 审查合并请求和代码变更 - 为团队建立代码审查标准 - 通过审查指导初级开发人员 - 进行架构审查 - 创建审查检查清单和指南 - 改善团队协作 - 缩短代码审查周期 - 维护代码质量标准 ## 核心原则 ### 1. 审查心态 **代码审查的目标：** - 发现 Bug 和边界情况 - 确保代码可维护性 - 在团队间共享知识 - 执行编码标准 - 改进设计和架构 - 建立团队文化 **非目标：** - 炫耀知识 - 对格式吹毛求疵（应使用 Lint 工具） - 不必要地阻碍进度 - 按照个人偏好重写代码 ### 2. 有效的反馈 **好的反馈应该是：** - 具体且可操作的 - 教育性的，而非评判性的 - 关注代码本身，而非个人 - 平衡的（也要表扬好的工作） - 有优先级的（关键问题 vs 建议性问题） markdown ❌ 差: "这是错的。" ✅ 好: "当多个用户同时访问时，这可能会导致竞态条件。考虑在这里使用互斥锁（mutex）。" ❌ 差: "你为什么不用 X 模式？" ✅ 好: "你考虑过使用 Repository 模式吗？它会让测试变得更容易。这是一个示例：[链接]" ❌ 差: "重命名这个变量。" ✅ 好: "[建议] 考虑将 `uc` 重命名为 `userCount` 以提高清晰度。如果你更喜欢原样，不强制修改。" ### 3. 审查范围 **审查内容：** - 逻辑正确性和边界情况 - 安全漏洞 - 性能影响 - 测试覆盖率和质量 - 错误处理 - 文档和注释 - API 设计和命名 - 架构契合度 **无需人工审查的内容：** - 代码格式（使用 Prettier, Black 等） - 导入顺序 - Lint 违规 - 简单的拼写错误 ## 审查流程 ### 第一阶段：收集上下文（2-3 分钟） markdown 在深入代码之前，请了解： 1. 阅读 PR 描述和关联的问题 2. 检查 PR 大小（超过 400 行？要求拆分） 3. 查看 CI/CD 状态（测试是否通过？） 4. 理解业务需求 5. 注意任何相关的架构决策 ### 第二阶段：高层审查（5-10 分钟） markdown 1. **架构与设计** - 解决方案是否符合问题需求？ - 是否有更简单的方法？ - 是否与现有模式一致？ - 是否会 s