AgentSkillsCN

Code Review

Code Review

中文原作
SKILL.md

Code Review Skill

Name: code-review Description: 深度代码审查，基于Clean Code、Clean Architecture、SOLID等原则 Version: 1.0.0 Author: Sheldon

Purpose

提供全面、专业的代码审查，从多个维度评估代码质量，包括：

  • •Clean Code原则（可读性、简洁性、命名）
  • •Clean Architecture原则（分层、依赖规则）
  • •SOLID原则（单一职责、开闭原则等）
  • •设计模式应用
  • •性能优化
  • •安全性
  • •测试覆盖

Usage

bash
/code-review [file_path or directory]

如果未指定路径，则审查当前工作目录或最近修改的文件。

Review Framework

1. Clean Code 原则审查

1.1 命名规范

  • •变量/函数命名：是否有意义、自解释？
  • •避免缩写：除非是业界通用（如 HTTP, API）
  • •布尔值命名：使用 is/has/can 前缀
  • •类名：使用名词，表示职责
  • •函数名：使用动词，表示行为
  • •常量：全大写，下划线分隔

1.2 函数设计

  • •单一职责：每个函数只做一件事
  • •函数长度：建议不超过20-30行
  • •参数数量：理想 ≤ 3个，最多5个
  • •副作用：避免隐藏的副作用
  • •抽象层级：同一函数内保持一致的抽象层级
  • •命令查询分离：函数要么执行操作，要么返回信息

1.3 注释与文档

  • •代码自解释：优先通过好的命名和结构
  • •必要注释：解释"为什么"而非"是什么"
  • •删除废弃代码：不要注释掉的代码
  • •TODO/FIXME：标记临时方案和待办事项

1.4 代码结构

  • •DRY原则：不要重复自己
  • •避免嵌套过深：最多3层嵌套
  • •提前返回：使用 guard clauses
  • •魔法数字：提取为常量

2. Clean Architecture 原则审查

2.1 分层架构

  • •依赖方向：外层依赖内层，内层不依赖外层
  • •领域层：核心业务逻辑，不依赖框架
  • •应用层：用例编排
  • •接口适配层：控制器、API、UI
  • •基础设施层：数据库、外部服务

2.2 依赖倒置

  • •抽象接口：高层模块依赖抽象，不依赖具体实现
  • •依赖注入：使用DI容器或构造注入
  • •接口隔离：客户端不应依赖不需要的接口

2.3 边界清晰

  • •跨层通信：使用DTO/VO进行数据传输
  • •避免泄漏：数据库模型不直接暴露到API
  • •端口与适配器：清晰定义输入输出边界

3. SOLID 原则审查

3.1 Single Responsibility Principle (SRP)

  • •单一职责：一个类只有一个改变的理由
  • •内聚性：相关功能聚合在一起
  • •职责明确：类的职责可以用一句话描述

3.2 Open/Closed Principle (OCP)

  • •对扩展开放：通过继承或组合扩展
  • •对修改封闭：不修改现有代码
  • •策略模式：使用多态代替条件判断

3.3 Liskov Substitution Principle (LSP)

  • •子类可替换：子类可以替换父类
  • •契约一致：前置条件不强化，后置条件不弱化
  • •行为一致：子类行为符合父类预期

3.4 Interface Segregation Principle (ISP)

  • •接口最小化：客户端只依赖需要的方法
  • •避免胖接口：拆分大接口为小接口
  • •角色接口：根据客户端需求定义接口

3.5 Dependency Inversion Principle (DIP)

  • •依赖抽象：高层和低层都依赖抽象
  • •稳定抽象：抽象不应频繁变化
  • •控制反转：由容器管理依赖关系

4. 设计模式审查

检查是否正确应用或滥用设计模式：

  • •创建型：单例、工厂、建造者、原型
  • •结构型：适配器、装饰器、代理、外观
  • •行为型：策略、观察者、模板方法、责任链

5. 性能审查

  • •算法复杂度：时间和空间复杂度
  • •数据库查询：N+1问题，索引使用
  • •缓存策略：合理使用缓存
  • •资源管理：及时释放资源
  • •并发处理：线程安全，避免死锁

6. 安全性审查

  • •输入验证：所有外部输入都要验证
  • •SQL注入：使用参数化查询
  • •XSS防护：输出转义
  • •认证授权：权限检查完整
  • •敏感数据：加密存储，不硬编码
  • •依赖安全：检查第三方库漏洞

7. 测试覆盖审查

  • •单元测试：核心逻辑测试覆盖
  • •集成测试：模块间协作测试
  • •边界测试：异常情况处理
  • •测试可读性：测试作为文档
  • •测试独立性：测试间不相互依赖

8. 代码规范审查

  • •语言规范：遵循语言最佳实践
  • •项目规范：符合团队约定
  • •格式一致：缩进、空格、换行
  • •导入顺序：标准库、第三方、本地

Review Output Format

审查报告应包含以下部分：

📊 概览

  • •文件/模块名称
  • •代码行数
  • •复杂度评分
  • •整体评级：优秀/良好/一般/需改进/严重问题

🔴 严重问题 (Critical)

  • •安全漏洞
  • •架构违背
  • •性能瓶颈

🟡 重要建议 (Major)

  • •SOLID原则违背
  • •Clean Code问题
  • •设计改进

🟢 优化建议 (Minor)

  • •命名优化
  • •代码简化
  • •注释补充

✅ 优点

  • •做得好的地方
  • •最佳实践应用

📝 具体修改建议

对每个问题，提供：

  1. •问题描述：违背了什么原则
  2. •当前代码：有问题的代码片段
  3. •改进方案：具体如何修改
  4. •理由说明：为什么这样改进

📈 代码质量指标

  • •可维护性: ⭐⭐⭐⭐☆ 4/5
  • •可读性: ⭐⭐⭐☆☆ 3/5
  • •可测试性: ⭐⭐⭐⭐⭐ 5/5
  • •性能: ⭐⭐⭐⭐☆ 4/5
  • •安全性: ⭐⭐⭐☆☆ 3/5

🎯 优先级建议

按优先级排序修改建议：

  1. •优先：安全问题
  2. •高：架构问题
  3. •中：代码质量
  4. •低：风格优化

Implementation Instructions

当 /code-review 被调用时：

  1. •

    确定审查范围

    • •如果指定了文件/目录，审查该范围
    • •如果未指定，询问用户要审查的代码
    • •支持审查 git diff 的变更
  2. •

    读取代码

    • •使用 Read 工具读取文件内容
    • •如果是目录，使用 Glob 找到所有代码文件
    • •识别编程语言，应用对应规范
  3. •

    多维度分析

    • •按照上述8个审查框架逐一检查
    • •标记问题位置（文件:行号）
    • •评估严重程度
  4. •

    生成报告

    • •使用上述输出格式
    • •提供具体、可操作的建议
    • •包含代码示例
  5. •

    运行单元测试

    • •自动检测测试框架（pytest, unittest, jest, mocha等）
    • •运行与审查代码相关的测试
    • •如果是Python项目，优先使用 pytest 或 python -m unittest
    • •如果是JavaScript/TypeScript项目，使用 npm test 或 yarn test
    • •报告测试结果：通过/失败/覆盖率
    • •如果有测试失败，在报告中标注相关问题
  6. •

    交互式改进

    • •询问用户是否需要自动修复某些问题
    • •提供多个改进方案供选择
    • •解释每个建议的权衡
    • •如果修复后，重新运行测试验证

Examples

示例1：审查单个文件

bash
/code-review backend/server.py

示例2：审查目录

bash
/code-review backend/

示例3：审查最近提交

bash
/code-review --git-diff

示例4：聚焦特定原则

bash
/code-review backend/server.py --focus=SOLID

Best Practices

  1. •客观公正：基于原则，不带偏见
  2. •建设性：提供解决方案，不只是批评
  3. •优先级：先解决严重问题
  4. •权衡：说明不同方案的利弊
  5. •上下文：考虑项目实际情况
  6. •教育性：解释原则，帮助理解

Notes

  • •代码审查要全面但不苛刻
  • •考虑团队规范和项目阶段
  • •平衡理想与现实
  • •鼓励渐进式改进
  • •认可好的实践