Back to Details

reviewing-code

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Review

Code Review

Use this skill when the user asks for a code review, feedback on their code, or to check code quality.
当用户请求代码审查、代码反馈或检查代码质量时，使用此skill。

Steps

步骤

  1. Understand the change — read the files or diff to understand what the code is supposed to do. Identify the scope (new feature, bug fix, refactor).
  2. Check correctness
    • Does the code handle edge cases (empty input, null, zero, negative numbers)?
    • Are error states handled (try/catch, error boundaries, fallback UI)?
    • Does async code handle race conditions, cancellation, and timeouts?
    • Are there off-by-one errors in loops or array access?
  3. Check maintainability
    • Are functions focused on a single responsibility?
    • Are variable and function names descriptive?
    • Is there unnecessary duplication that should be extracted?
    • Are magic numbers replaced with named constants?
    • Is the code complexity reasonable (deeply nested conditionals, long functions)?
  4. Check performance
    • Are there N+1 query patterns in database access?
    • Are expensive computations or API calls happening in render loops?
    • Are large lists missing virtualization or pagination?
    • Are there missing indexes for common database queries?
    • Is memoization used appropriately (not over-applied)?
  5. Check type safety (TypeScript projects)
    • Are there 
      any
      types that should be narrowed?
    • Are function return types explicit for public APIs?
    • Are union types handled exhaustively?
  6. Check testing
    • Are there tests for the new/changed code?
    • Do tests cover the happy path AND error cases?
    • Are tests isolated (no shared mutable state)?
  7. Provide feedback — organize findings by severity:
    • Must fix: bugs, security issues, data loss risks
    • Should fix: performance issues, maintainability concerns
    • Nit: style preferences, minor suggestions
    For each finding, include the file, line, the issue, and a suggested fix.
  1. 理解变更 — 阅读文件或diff以了解代码的预期功能。确定范围（新功能、bug修复、重构）。
  2. 检查正确性
    • 代码是否处理了边缘情况（空输入、null、零、负数）？
    • 是否处理了错误状态（try/catch、错误边界、备用UI）？
    • 异步代码是否处理了竞态条件、取消和超时？
    • 循环或数组访问中是否存在差一错误？
  3. 检查可维护性
    • 函数是否专注于单一职责？
    • 变量和函数名称是否具有描述性？
    • 是否存在应提取的不必要重复代码？
    • 魔术数字是否已替换为命名常量？
    • 代码复杂度是否合理（深度嵌套的条件语句、过长的函数）？
  4. 检查性能
    • 数据库访问中是否存在N+1查询模式？
    • 昂贵的计算或API调用是否发生在渲染循环中？
    • 大型列表是否缺少虚拟化或分页？
    • 常见数据库查询是否缺少索引？
    • memoization是否得到恰当使用（未过度应用）？
  5. 检查类型安全性（TypeScript项目）
    • 是否存在应缩小范围的
      any
      类型？
    • 公共API的函数返回类型是否明确？
    • 联合类型是否得到全面处理？
  6. 检查测试
    • 新代码/变更代码是否有测试覆盖？
    • 测试是否覆盖了正常路径和错误场景？
    • 测试是否隔离（无共享可变状态）？
  7. 提供反馈 — 按严重程度整理发现的问题：
    • 必须修复：bug、安全问题、数据丢失风险
    • 应该修复：性能问题、可维护性问题
    • 细微建议：风格偏好、次要建议
    对于每个问题，需包含文件、行号、问题描述以及建议的修复方案。

Notes

注意事项

  • Be constructive — explain why something is a problem, not just that it is.
  • Acknowledge what's done well, not just what needs fixing.
  • Don't bikeshed on style issues that a linter/formatter should handle.
  • 保持建设性——解释问题存在的原因，而不仅仅指出问题。
  • 认可做得好的部分，而不仅仅关注需要修复的内容。
  • 不要在代码风格问题上吹毛求疵，这些应由代码检查工具/格式化工具处理。