第2天 · AI重构代码

🎯 今日核心问题

什么样的代码适合让 AI 重构？什么样的不适合？
AI 重构和手工重构有什么本质区别？

📖 精读提纲

【一】核心概念

重构 = 在不改变外部行为的前提下改善内部结构。这是后端开发的核心工程素养之一。AI 的优势是：它见过无数代码模式，能快速识别坏味道并给出更优雅的替代方案，把你从"我知道这段代码不好但不知道怎么改"的困境中解脱出来。

【二】关键原理

AI 重构的 5 个维度：

命名优化：变量名、方法名更表达业务意图
抽取方法：把长方法拆成职责单一的小方法
消除重复：发现并提取公共逻辑
设计模式：用策略、工厂、模板方法替换 if-else 地狱
异常处理：统一异常链路，去掉 catch 住就吞掉的坏习惯

【三】实战应用（Java/Spring Boot）

Before：Controller 肥胖症

@PostMapping("/order")
public Result createOrder(@RequestBody OrderDTO dto) {
    // 参数校验
    if (dto.getUserId() == null) return Result.fail("userId不能为空");
    if (dto.getAmount() <= 0) return Result.fail("金额必须大于0");
    // 查用户
    User user = userMapper.selectById(dto.getUserId());
    if (user == null) return Result.fail("用户不存在");
    // 创建订单
    Order order = new Order();
    order.setUserId(dto.getUserId());
    order.setAmount(dto.getAmount());
    order.setStatus("PENDING");
    order.setCreateTime(LocalDateTime.now());
    orderMapper.insert(order);
    return Result.ok(order.getId());
}

让 AI 重构的 Prompt："这是一个 Spring Boot 下单接口，请按照三层架构（Controller 只做参数校验和调用 Service，Service 处理业务逻辑）重构，保持功能不变。"

After：瘦身后的 Controller

@PostMapping("/order")
public Result createOrder(@Valid @RequestBody OrderDTO dto) {
    Long orderId = orderService.createOrder(dto);
    return Result.ok(orderId);
}

消除 if-else 嵌套示例：用策略模式

告诉 AI："这段根据支付类型走不同逻辑的 if-else，请用策略模式重构，后续新增支付方式只需新增一个类。"

【四】常见误区

❌ 让 AI 一次重构太多 → 难以验证正确性，容易引入 bug
❌ 重构后不跑单测验证 → 行为可能已经偷偷改变
❌ 忽略业务语义 → AI 可能把有业务含义的变量名改成通用名
✅ 正确做法：小步重构，每次改一个点，改完跑测试

💡 今日金句

好代码不是写出来的，是重构出来的。AI 让重构的成本降低了 10 倍。

✏️ 今日练习

找一段你写过的"能跑但难看"的 Java 方法（比如一个超过 50 行的 Service 方法，或者有超过 3 层 if-else 嵌套的代码），把它贴给 ChatGPT 或 Claude，加上这句话：

"请帮我重构这段代码，保持功能不变，目标是：1）减少方法长度 2）消除嵌套 3）让命名更表达业务含义。重构后请说明每一处改动的理由。"

对比前后差异，思考哪里还能继续改进。

🔖 明日预告

明天是本章综合演练日：5 个真实的 Java 后端 AI 使用场景，每个都可以立即动手。

第2天 · 让 AI 重构代码 + 边界总结