代码异味分析器

对代码文件进行分析，识别潜在的改进点，包括代码异味（Code Smells）、设计模式应用机会以及最佳实践遵循情况。在不改变功能的前提下，提供提升可读性、可维护性和性能的具体建议。

适用场景

在以下情况下调用该能力：

• 用户请求代码分析或代码审查
• 用户希望获得提升代码质量的建议
• 用户提及“代码异味”、“重构”或“最佳实践”
• 用户希望在不改变功能的前提下优化代码结构

分析框架

1. 代码异味

识别以下常见代码异味：

• 过长方法（Long Methods）：超过 20–30 行的方法应拆分为更小的单元
• 过大类（Large Classes）：承担过多职责的类
• 重复代码（Duplicate Code）：应提取为独立函数或模块的重复逻辑块
• 复杂条件逻辑（Complex Conditionals）：深度嵌套的 if/else 语句
• 魔法数字（Magic Numbers）：缺乏说明的硬编码数值
• 无效代码（Dead Code）：未使用的变量、方法或导入语句
• 过长参数列表（Long Parameter Lists）：参数数量超过 3–4 个的方法
• 依恋情结（Feature Envy）：方法频繁访问其他类的成员，而非自身类的数据

2. 设计模式

推荐适用于当前代码结构的设计模式：

• 创建型（Creational）：Factory、Builder、Singleton、Prototype
• 结构型（Structural）：Adapter、Decorator、Facade、Composite
• 行为型（Behavioral）：Strategy、Observer、Command、State、Template Method

3. 最佳实践

检查是否符合语言特定的最佳实践：

• 命名规范（Naming Conventions）：变量、函数、类名应清晰、具描述性
• DRY 原则（Don't Repeat Yourself）：避免重复逻辑
• SOLID 原则（SOLID Principles）：单一职责、开闭原则、里氏替换、接口隔离、依赖倒置
• 错误处理（Error Handling）：合理使用异常处理机制，提供有意义的错误信息
• 文档（Documentation）：具备充分的注释与文档说明
• 可测试性（Testing）：代码是否易于编写单元测试与集成测试

4. 可读性

评估代码表达的清晰程度：

• 命名（Naming）：名称是否能自我说明其用途？
• 结构（Structure）：代码组织是否合理、层次分明？
• 注释（Comments）：复杂逻辑是否配有恰当解释？
• 格式（Formatting）：缩进与空格是否统一、规范？
• 抽象层级（Abstraction Level）：代码是否处于恰当的抽象层级，避免混杂高层逻辑与底层细节？

5. 可维护性

评估代码后续修改与扩展的难易程度：

• 耦合度（Coupling）：组件之间是否松耦合？
• 内聚性（Cohesion）：相关功能是否集中于同一模块或类中？
• 模块化（Modularity）：各部分是否可独立变更而不影响其他模块？
• 配置管理（Configuration）：硬编码值是否已外部化（如移至配置文件或环境变量）？
• 日志（Logging）：是否具备足够日志支持调试与问题追踪？

6. 性能

识别潜在的性能优化机会：

• 算法复杂度（Algorithm Complexity）：是否存在 O(n²) 替代 O(n) 的低效实现？
• 内存使用（Memory Usage）：是否存在不必要的对象创建或内存泄漏风险？
• I/O 操作（I/O Operations）：数据库查询、文件读写、网络调用是否过度或未优化？
• 缓存（Caching）：是否存在可复用计算结果的缓存机会？
• 懒加载（Lazy Loading）：高开销操作是否延迟至真正需要时再执行？

输出格式

每条建议均需包含以下要素：

问题描述

对问题或改进机会的清晰说明。

当前代码

// 展示存在问题的代码

建议改进

// 展示改进后的代码

依据说明

解释该变更为何有益。

优先级

• 高（High）：影响功能正确性、安全性或存在严重性能瓶颈的关键问题
• 中（Medium）：对可维护性与可读性有显著提升的重要改进
• 低（Low）：细微优化项或锦上添花的改进建议

分析示例

问题：承担多重职责的过长方法

优先级：高

当前代码：

function processOrder(order) {
    // Validate order
    if (!order.items || order.items.length === 0) {
        throw new Error('Order has no items');
    }
    if (!order.customer) {
        throw new Error('Customer is required');
    }

    // Calculate totals
    let subtotal = 0;
    for (const item of order.items) {
        subtotal += item.price * item.quantity;
    }
    const tax = subtotal * 0.1;
    const total = subtotal + tax;

    // Apply discount
    if (order.discountCode) {
        total = total * 0.9;
    }

    // Save to database
    db.orders.insert({
        ...order,
        subtotal,
        tax,
        total,
        createdAt: new Date(),
    });

    // Send confirmation email
    emailService.send(order.customer.email, 'Order Confirmed', total);

    return {orderId: order.id, total};
}

建议改进：

function processOrder(order) {
    validateOrder(order);
    const pricing = calculatePricing(order);
    saveOrder(order, pricing);
    sendConfirmation(order, pricing.total);
    return {orderId: order.id, total: pricing.total};
}

function validateOrder(order) {
    if (!order.items?.length) throw new Error('Order has no items');
    if (!order.customer) throw new Error('Customer is required');
}

function calculatePricing(order) {
    const subtotal = order.items.reduce((sum, item) => sum + item.price * item.quantity, 0);
    const tax = subtotal * 0.1;
    let total = subtotal + tax;

    if (order.discountCode) {
        total *= 0.9;
    }

    return {subtotal, tax, total};
}

function saveOrder(order, pricing) {
    db.orders.insert({
        ...order,
        ...pricing,
        createdAt: new Date(),
    });
}

function sendConfirmation(order, total) {
    emailService.send(order.customer.email, 'Order Confirmed', total);
}

依据说明：

• 单一职责：每个函数仅承担一项明确职责
• 可测试性：各函数可独立编写单元测试
• 可读性：主函数呈现为高层流程概览，逻辑一目了然
• 可维护性：定价逻辑的变更不会波及校验逻辑

语言特定注意事项

JavaScript / TypeScript

• 使用 const/let 替代 var
• 回调函数优先使用箭头函数
• 合理使用可选链操作符（?.）和空值合并操作符（??）
• TypeScript 中避免使用 any 类型

Python

• 遵循 PEP 8 编码风格指南
• 恰当地使用列表推导式
• 善用上下文管理器（with 语句）
• 添加类型提示以增强代码可读性与工具支持

Java

• 集合操作优先使用 Stream API
• 优先选择组合（Composition）而非继承（Inheritance）
• 使用 Optional 替代 null 值判断
• 严格遵守 Java 命名规范（如驼峰命名法）

微信小程序

• 所有 HTTP 请求统一通过 Service 层发起
• 避免在 Page data 中冗余存储数据
• 列表渲染时务必使用 wx:key
• 遵循项目中的 AGENTS.md 规范

注意事项

• 始终确保不破坏现有功能
• 尊重并适配项目既有的编码与架构约定
• 按影响范围与实施成本综合评估变更优先级
• 所提建议须具体、可操作、可落地
• 充分考虑向后兼容性（Backward Compatibility）