浅谈重构中踩过的坑

作为程序员，我们常听到“重构是改善代码设计、提升可维护性的好习惯”。然而，在实际项目中，重构往往不是一帆风顺的。我曾在一家互联网公司负责一个老系统的重构，过程中遇到了不少让人“头秃”的问题。今天，我就结合自己的经历，聊聊重构中踩过的那些坑，并附上代码示例，希望能帮你少走弯路。## 什么是重构？为什么容易踩坑？重构是指在保持软件外部行为不变的前提下，调整内部结构。听起来简单，但“外部行为不变”是个大前提。现实是，很多重构一开始就破坏了现有功能，或者引入了新 bug。常见原因包括：- 对原有逻辑理解不透彻- 过度依赖“重构工具”或自动替换- 忽视测试覆盖- 一次性改动太多下面我分享两个真实案例，每个都附有可运行的 Python 代码。## 坑一：盲目“优化”代码，反而引入 bug### 背景有一次，我看到一段老代码，它用循环和条件判断来计算折扣。我觉得它太“啰嗦”，想把它改得更“Pythonic”。### 原代码python# 原代码：根据用户等级和金额计算折扣def calculate_discount(level, amount): if level == "gold": if amount > 1000: discount = 0.2 else: discount = 0.1 elif level == "silver": if amount > 500: discount = 0.15 else: discount = 0.05 else: # normal discount = 0 return amount * (1 - discount)# 测试print(calculate_discount("gold", 2000)) # 预期输出: 1600print(calculate_discount("silver", 600)) # 预期输出: 510print(calculate_discount("normal", 100)) # 预期输出: 100### 我踩的坑我嫌它不够简洁，用字典和 lambda 改成了“一行流”。结果运行后，发现某些边界条件错了。python# 错误的重构版本：过分追求简洁，丢失了边界条件def calculate_discount_bad(level, amount): # 错误：忽略了 amount 为 1000 和 500 时的边界情况 rules = { "gold": lambda a: 0.2 if a > 1000 else 0.1, "silver": lambda a: 0.15 if a > 500 else 0.05, "normal": lambda a: 0 } discount = rules[level](amount) return amount * (1 - discount)# 测试：边界条件 1000 和 500 应该分别走 else 分支，但这里没变print(calculate_discount_bad("gold", 1000)) # 原逻辑应为 0.1，这里还是 0.1，正确print(calculate_discount_bad("silver", 500)) # 原逻辑应为 0.05，这里还是 0.05，正确# 但问题出在：原代码对 amount > 1000 是严格大于，我的 lambda 也是严格大于，看起来一致# 可后来业务需求变了：要求 amount >= 1000 时用 0.2，但原代码没改，我的重构也没注意到# 实际上这个坑在于：我重构时没确认原逻辑是否真的符合业务，结果后来业务改了，但代码没同步### 教训重构不能只看代码，还要理解业务逻辑。最好先写单元测试，确保原代码的行为被覆盖。下面是一个安全的重构版本：python# 安全的重构版本：先写测试，再重构def calculate_discount_safe(level, amount): # 使用字典 + 条件函数，保留可读性 if level == "gold": discount = 0.2 if amount > 1000 else 0.1 elif level == "silver": discount = 0.15 if amount > 500 else 0.05 else: discount = 0 return amount * (1 - discount)# 验证assert calculate_discount_safe("gold", 2000) == 1600assert calculate_discount_safe("gold", 1000) == 900 # 0.1assert calculate_discount_safe("silver", 500) == 475 # 0.05print("所有测试通过")## 坑二：过度依赖“提取函数”，导致上下文混乱### 背景另一个项目里，一个函数长达 200 行，我决定提取子函数。但提取时，我漏掉了几个变量，导致逻辑出错。### 原代码（简版）python# 原代码：处理订单，计算总价和运费def process_order(order): total = 0 for item in order["items"]: total += item["price"] * item["quantity"] # 计算运费 if total > 100: shipping = 0 else: shipping = 10 # 计算折扣（假设有优惠券） coupon = order.get("coupon", 0) discount = total * coupon final = total - discount + shipping return final# 测试order = {"items": [{"price": 50, "quantity": 2}], "coupon": 0.1}print(process_order(order)) # 预期: 100 - 10 + 0 = 90### 我踩的坑我提取了calc_shipping函数，但忘了把total传进去，而是用了全局变量。python# 错误的重构版本：漏传参数，导致 shipping 计算错误def calc_shipping(): # 错误：使用了未定义的 total，Python 会报错，但更隐蔽的是如果 total 是全局变量，就会引用错误值 if total > 100: # NameError: name 'total' is not defined return 0 else: return 10def process_order_bad(order): total = 0 for item in order["items"]: total += item["price"] * item["quantity"] shipping = calc_shipping() # 这里会报错 coupon = order.get("coupon", 0) discount = total * coupon final = total - discount + shipping return final# 运行会报错：NameError### 正确做法提取函数时，一定要把依赖的变量显式传入。python# 正确的重构版本：显式传入参数def calc_shipping(total): """计算运费，总价大于100免运费""" if total > 100: return 0 else: return 10def process_order_good(order): total = 0 for item in order["items"]: total += item["price"] * item["quantity"] shipping = calc_shipping(total) # 传入 total coupon = order.get("coupon", 0) discount = total * coupon final = total - discount + shipping return final# 测试order = {"items": [{"price": 50, "quantity": 2}], "coupon": 0.1}print(process_order_good(order)) # 正确输出: 90## 总结重构不是炫技，而是为了更安全、更清晰地维护代码。在我踩过的坑中，最深的体会是：1.先理解后动手：重构前，花时间阅读原代码，理解业务逻辑和边界条件。2.测试是护身符：没有测试的重构就像走钢丝，建议先写单元测试覆盖关键路径。3.小步迭代：不要一次性改动太多，每次只重构一小块，并立即运行测试。4.警惕过度抽象：提取函数或类时，注意依赖关系，避免“隐式传参”。5.工具不是万能：IDE 的重构功能（如重命名、提取方法）很强大，但必须人工验证结果。重构就像给飞机换引擎——必须一边飞一边换。如果你没有完善的测试和严谨的步骤，很可能“坠机”。希望我的这些教训，能让你在重构之路上少一些坎坷，多一些从容。