那个800行的if-else

去年接手了一个运费计算模块，核心方法叫calculateShippingFee，800来行，里面是几十个if-else分支——按地区、按商品类型、按会员等级、按促销活动组合出几十种计费规则。注释几乎没有，变量的命名风格从驼峰到下划线到拼音缩写应有尽有。

这种代码我改一次怕一次——牵一发而动全身，改A地区的规则可能影响B地区的计费。我一直想把它重构成策略模式，但面对800行的分支逻辑，光梳理出所有策略类就让人望而却步。

后来AI工具用得多了，我想着能不能让AI帮我做这个重构。以下是整个过程和翻过的车。

第一步：让AI识别策略分支

我把calculateShippingFee方法和它依赖的几个辅助方法一起丢给AI，让它识别出所有独立的计费策略。这个环节AI做得相当好。

// 原始代码的典型片段（脱敏处理）
if ("EAST".equals(region) && weight <= 5) {
    fee = baseFee * 0.9;
} else if ("EAST".equals(region) && weight > 5) {
    fee = baseFee * 0.9 + (weight - 5) * stepFee;
} else if ("WEST".equals(region) && "FRAGILE".equals(productType)) {
    fee = baseFee * 1.5 + insuranceFee;
} else if ("WEST".equals(region) && !"FRAGILE".equals(productType)) {
    fee = baseFee * 1.2;
}
// ... 还有七八十个这样的分支

AI在几十秒内就整理出了所有分支的策略矩阵，我人工核对了一遍，准确率大概95%。漏掉的几个是隐式条件——比如某个分支里调用了checkHolidaySeason()，但没有显式判断节假日，逻辑藏在方法内部。

第二步：AI生成策略接口和实现类——问题开始出现

AI给出的重构方案很标准：定义ShippingStrategy接口，每个计费规则一个实现类，用工厂模式根据条件选择策略。

接口定义AI写得没问题：

public interface ShippingStrategy {
    BigDecimal calculate(ShippingContext context);
    boolean supports(ShippingContext context);
}

但到具体实现类的时候就出状况了。我举个例子：华东地区普通商品5公斤以内的计费规则，原始代码里有个隐蔽逻辑——VIP会员在此基础上再打95折。这个逻辑不在calculateShippingFee方法里，而是在调用方的一个回调里处理的。

AI完全不知道这个回调的存在，生成的策略类里漏掉了VIP折扣。如果我直接用了AI的代码上线，VIP客户的运费就多收了5%。

这不是AI的错，是它看不到调用链的全貌。但问题在于，AI不会主动告诉你"我可能漏了什么"，它只会自信地给出看起来完整的代码。

第三步：我的防线——逐策略类人工核对

意识到这个风险后，我换了个工作方式：不让AI一次性生成所有策略类，而是我一个一个来。我选定一个分支，让AI生成对应的策略实现，然后我逐行对照原始代码验证。

这个过程中我发现AI的另一个问题——它倾向于"美化"代码。比如原始代码里有个处理偏远地区的逻辑：

// 原始代码
if (isRemoteArea(zipCode) && orderAmount < 99) {
    fee += remoteSurcharge;
    if (remoteSurcharge > 50) {
        log.warn("high remote surcharge: " + remoteSurcharge + " for order " + orderId);
    }
}

AI重构后变成了：

if (context.isRemote() && context.getOrderAmount().compareTo(FREE_THRESHOLD) < 0) {
    BigDecimal surcharge = remoteAreaCalculator.calculate(context);
    context.addFee(surcharge);
    auditLogger.recordHighSurcharge(context.getOrderId(), surcharge, THRESHOLD_50);
}

看着更优雅对吧？命名清晰了，魔法数字提取成了常量，日志也规范了。但问题出在auditLogger——我们项目用的是logback，没有这个类，AI凭空造了个依赖。而且FREE_THRESHOLD这个常量是99，它提取了，但THRESHOLD_50这个50它也提取了——这两个值是不同业务含义的阈值，放在同一个地方反而增加了理解成本。

总结下来就是：AI做重构会带入自己认为"更好"的写法，但有些"优化"在你的项目上下文里并不成立。

真正有价值的地方

撇开上述问题，AI在这个重构任务里确实有不可替代的价值。

分支覆盖率分析。我把重构后的策略类全部列出来，AI帮我对照原始代码验证每个分支是否有对应的策略覆盖。人工做这个要一整天，AI几分钟。

测试用例生成。每个策略类独立出来后，AI可以快速生成一组覆盖正常路径和边界条件的测试。虽然仍然需要人工审查（Mockito的坑上一篇讲过了），但比从零开始写快太多了。

文档生成。重构完之后，每个策略类对应的业务规则是什么，AI能帮你生成一份清晰的说明。这对后续接手的人很有用。

经验总结

用AI辅助遗留代码重构，我给自己定了三条规矩：

绝不让AI一次性重构超过3个策略类。小块小块来，每块重构完跑一遍全量测试，确认没引入回归再继续。AI给的"一口气全重构"的方案看起来很爽，但出了问题你都不知道从哪开始排查。

AI生成的所有条件判断必须逐行核验。它可能会遗漏条件、合并不该合并的分支、或者"优化"掉一些看起来不合理但实际有业务含义的逻辑。别偷这个懒。

重构前后跑同一组测试用例。这看起来是废话，但实际执行中很容易因为"策略类拆完了肯定没问题"的心态而跳过。我犯过这个错，代价是一个周末加班。

代码重构这件事，AI是个好帮手但不是替你思考的人。它能把机械性的整理工作做得又快又好，但业务理解、架构决策、风险判断——这些还得靠对系统最熟悉的人来做。以上就是我在真实项目里用AI重构策略模式的全记录，希望对同样面对遗留代码的同学有用。