SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场code-review

code-review

编程与开发

查看项目

更新于 10-15 11:01

技能介绍

用途

本技能用于支持高效的代码审查工作，提供审查清单、PR 审查模式、反馈技巧以及审查自动化方案。当用户提出“review this code”“code review checklist”“PR review”等需求时适用。

主要能力

分类审查清单

  • 逻辑与正确性：代码是否实现 PR 描述所述功能；边界情况（空输入、边界值、并发访问）是否处理；错误条件是否以合适错误类型优雅处理；循环、切片、分页是否存在差一错误；null/undefined/nil 情况是否处理；控制流是否符合预期行为（提前返回、fallthrough）。
  • 安全性：无硬编码密钥、令牌或密码；对所有用户提供的数据（查询参数、请求体、请求头）做输入校验；无 SQL 注入、XSS、命令注入向量；每个端点都有认证与授权检查；敏感数据不写入日志、错误信息或响应；状态变更请求有 CSRF 保护；敏感端点（认证、密码重置）有速率限制。
  • 性能：无 N+1 数据库查询（循环内查询）；无内存泄漏（事件监听器、定时器、订阅未清理）；大数据集分页而非全量载入内存；昂贵计算适当缓存；主线程或事件循环无阻塞操作；数据库查询使用索引（对新查询检查 EXPLAIN 计划）。
  • 可读性与可维护性：无需作者解释即可理解；函数职责单一且命名清晰；无重复逻辑（在降低耦合处遵循 DRY，而非盲目）；命名约定与代码库一致；无死代码、注释掉的代码或未使用导入；复杂逻辑注释解释“为什么”而非“做什么”。
  • 测试：覆盖主要成功路径；测试边界情况与错误路径；测试确定性（不引入不稳定测试）；测试名称描述行为而非实现；Mock 最小且贴近真实。

建设性反馈

原则：具体（“第 42 行 user 为 null 时会抛错”优于“更好地处理错误”）；解释原因；提供替代方案；承认权衡；提出真诚问题。

带前缀的评论标记：

  • [nit] 次要风格问题，可改可不改
  • [suggestion] 可选改进建议
  • [question] 寻求理解，不一定要求修改
  • [issue] 合并前必须解决
  • [praise] 值得表扬的优点
  • [thought] 分享背景或视角，无需行动

PR 规模与审查速度

规模指南：小（<200 行）15-30 分钟，理想；中（200-400 行）30-60 分钟，可接受；大（400-800 行）考虑拆分；超大（>800 行）几乎总应拆分。

应拆分的情形：重构与功能变更混合；基础设施变更与业务逻辑混合；数据库迁移与应用代码混合；多个独立功能或修复捆绑。

可接受大 PR 的情形：生成代码（protobuf、OpenAPI、迁移样板）；批量重命名或自动格式化；初始项目搭建或删除大量死代码。

速度与周转：目标首次审查在 4 个工作小时内；阻塞其他工作的 PR 优先；异步规范（“我会在今天结束前审查”优于沉默）；反馈处理后 2 小时内复审，聚焦 diff；不要批量审查；24 小时以上未审查应升级或重新分配。

自动化审查工具

  • GitHub Actions：CI 检查、lint、类型检查、测试覆盖率门禁。
  • Danger.js：可编程 PR 审查规则与警告（如 PR 过大、缺少描述、敏感文件变更）。
  • 其他工具：CodeRabbit（AI 审查摘要与行内建议）、SonarQube/SonarCloud（静态分析）、Codacy/CodeClimate（代码质量评分）、Reviewbot/Prow（机器人标签、分配、合并门禁）、Codecov/Coveralls（覆盖率跟踪与 PR 评论）。

安全审查

对照 OWASP Top 10 常见模式：注入、认证失效、数据暴露、访问控制、配置错误、XSS、SSRF。认证审查细节：登录后重新生成会话令牌；密码重置令牌一次性且限时；JWT 校验签名、过期、签发者与受众；API 密钥最小权限；等。

性能审查模式

N+1 查询（循环内查询 vs 批量查询）、内存泄漏（监听器/定时器/订阅未清理、缓存无淘汰、闭包持有大对象）、React 不必要渲染（JSX 内联对象/数组、缺少 useMemo/useCallback、Context 值未 memo）。

数据库迁移审查

是否可逆、回滚函数是否有效；是否锁表；新列是否可空或有默认值；索引是否并发创建（CREATE INDEX CONCURRENTLY）；数据迁移与模式迁移是否分离；是否幂等；是否按生产规模数据测试运行时间；删除列是否有弃用路径。

常见反模式

吹毛求疵（评论 linter 应捕获的格式问题）、橡皮图章（2 分钟对 500 行 PR 说 LGTM）、自行车棚效应（在琐事上长篇争论）、守门人心理（因个人风格偏好阻塞 PR）、顺路评论（一句模糊评论后消失）。

按 PR 类型的审查模板

功能 PR、缺陷修复 PR、重构 PR、依赖更新 PR 各有对应检查项。

代码所有权与 CODEOWNERS

保持所有权粒度；每季度审查 CODEOWNERS；用于强制审查而非通知；结合分支保护规则要求 CODEOWNERS 批准。

结对审查 vs 异步审查

结对审查适合复杂架构、不熟悉代码库、新人上手、有争议设计；异步审查适合常规变更、熟悉领域、分布式团队。当同一问题来回超过 2 轮、评论无法解决分歧、PR 涉及需要讲解的不熟悉领域时，从异步切换到结对。

请求修改 vs 带评论批准

请求修改：会破坏生产的缺陷、安全漏洞、PR 未实现描述所述、关键路径缺少测试、会导致数据丢失或损坏。带评论批准：建议是改进但代码本身正确、团队风格指南未涵盖的风格偏好、不紧急的次要重构、出于好奇的问题。规则：若 PR 现在发布会造成伤害则请求修改；若可用但可更好则带评论批准。

审查工作流

  1. 阅读 PR 描述与关联 issue；2. 理解上下文；3. 检查 PR 规模，过大则先要求拆分；4. 先审查测试文件理解预期行为；5. 按 PR 类型清单审查主要变更；6. 检查正确性、安全、性能、可读性；7. 复杂或有风险时本地运行；8. 使用带前缀评论留下反馈；9. 总结整体评估与明确状态。

使用方式

本技能以文档形式提供上述清单、模式与模板，供开发者在审查代码或制定团队审查流程时参考。资料未提供具体的安装命令或调用方式。

适用场景

开发者提交或评审代码、团队制定代码审查规范、编写 PR 审查模板、配置自动化审查工具、进行安全与性能专项审查时。

限制

资料未提供该技能的具体运行环境、安装方式、收费信息或平台支持情况。