电商订单系统重构：从代码坏味道到优雅设计

1. 从泥潭到诗篇：一个订单处理系统的重构艺术之旅

作为从业十余年的老码农，我见过太多"能跑就行"的代码最终演变成难以维护的"屎山"。今天，我想通过一个电商订单处理系统的重构案例，分享如何将混乱的代码转化为优雅的设计。这个案例来自我去年主导的一个真实项目重构，过程中踩过的坑和收获的经验，或许能给你带来启发。

2. 原始代码的"坏味道"诊断

2.1 订单处理系统的初始状态

我们接手的是一个Python实现的电商订单处理模块，核心功能包括：

• 接收订单请求（JSON格式）
• 计算订单总价（含VIP折扣、优惠券、促销活动）
• 检查并扣减库存
• 处理支付
• 发送通知（邮件/短信）
• 记录订单日志

原始代码把所有逻辑塞进了一个长达80行的process_order函数，典型的"上帝对象"反模式。让我们看看这段代码的主要问题：

python复制def process_order(data):
    d = json.loads(data)
    user = d['user']
    items = d['items']
    total = 0
    for i in items:
        total += i['price'] * i['quantity']
    
    # 应用折扣（长达20行的if-elif链）
    if user['vip'] == 1:
        total = total * 0.9
    elif user['vip'] == 2:
        total = total * 0.8
    # ...更多折扣逻辑
    
    # 检查库存
    for i in items:
        stock = get_stock(i['id'])
        if stock < i['quantity']:
            return "FAIL"
    
    # 扣减库存、支付、通知等更多逻辑...

2.2 十大代码"坏味道"

1. 单一职责违反：一个函数处理解析、计算、库存、支付等所有逻辑
2. 魔法数字：0.9、0.8等折扣率直接硬编码
3. 重复迭代：对items列表进行了四次遍历（计算、检查库存、扣库存、支付）
4. 糟糕的命名：d、i等无意义变量名
5. 字符串返回状态：用"FAIL"/"SUCCESS"字符串表示结果
6. 全局状态依赖：直接操作全局库存字典
7. 紧耦合：直接调用发送邮件/短信的函数
8. 缺乏抽象：业务概念都用字典表示
9. 脆弱的条件链：折扣逻辑用长串if-elif实现
10. 混合同步/异步：日志写入文件是同步IO操作

提示：在实际审查代码时，我习惯用Checklist逐项检查这些"坏味道"。建议团队可以建立自己的代码质量检查表。

3. 重构策略与路线图

3.1 重构的五大目标

1. 可读性：代码应该像散文一样易于阅读
2. 可维护性：修改一个功能不应影响其他部分
3. 可测试性：每个组件都应该能独立测试
4. 可扩展性：新增功能不应修改现有代码
5. 性能：避免不必要的计算和IO

3.2 渐进式重构路线

我们采用小步快跑的重构策略：

1. 先建立测试安全网
2. 重命名和格式化