重构

副标题 / 摘要 大量 if 判断会让代码难以维护。本文通过职责拆分与多态消除条件分支。 目标读者 需要重构遗留代码的工程师 关注可维护性的团队 学习设计原则的开发者 背景 / 动机 if 分支常常是“规则塞在一起”的信号。 当规则变化时，分支会持续膨胀。 核心概念 职责拆分：让对象承担自己的规则 多态：用对象替代条件判断 空对象：避免 null 判断 实践指南 / 步骤 识别 if 判断的业务规则 为规则创建对象或策略 用空对象替代 null 分支 把规则拆成可测试单元 可运行示例 class Foo: def do(self, file): return f"process {file}" class NullFoo(Foo): def do(self, file): return "" def get_foo(repo, key): return repo.get(key, NullFoo()) if __name__ == "__main__": repo = {"a.xml": Foo()} foo = get_foo(repo, "a.xml") print(foo.do("a.xml")) 解释与原理 把“有/无对象”的判断交给对象本身（Null Object）， 可减少 if 分支并提升可读性。 ...

副标题 / 摘要 switch 往往会不断膨胀。本文用策略模式把分支逻辑拆分成可扩展的多态结构。 目标读者 需要重构条件分支的工程师 关注可维护性的团队 学习设计模式的开发者 背景 / 动机 分支逻辑一旦增长，switch 会变成维护噩梦。 多态可以把“选择逻辑”变成“可扩展结构”。 核心概念 策略模式：把算法封装为对象 开闭原则：对扩展开放，对修改关闭 多态分发：用对象替代条件分支 实践指南 / 步骤 识别 switch 的分支类型 为每个分支定义策略类 用工厂或映射选择策略 新增分支只新增类 可运行示例 class Formatter: def format(self, text): raise NotImplementedError class FailFormatter(Formatter): def format(self, text): return "error" class OkFormatter(Formatter): def format(self, text): return text + text def get_formatter(response): return {"FAIL": FailFormatter(), "OK": OkFormatter()}.get(response) if __name__ == "__main__": f = get_formatter("OK") print(f.format("hi")) 解释与原理 switch 把逻辑集中在一处，扩展时必须修改旧代码。 多态把分支拆成独立类，新增规则只需新增类。 常见问题与注意事项 小分支是否需要多态？ 不一定，只有分支频繁扩展时值得。 ...

副标题 / 摘要 遗留代码的关键不是“重写”，而是“安全改动”。本文给出处理遗留系统的实用策略。 目标读者 维护老系统的工程师 需要降低改动风险的团队 负责技术债治理的负责人 背景 / 动机 遗留代码通常缺乏测试与文档，改动风险大。 安全改动的核心是“先建立保护网”。 核心概念 保护网：测试保证行为不变 最小安全改动：小步替换 分层改造：从外围开始逐步深入 实践指南 / 步骤 先补齐关键测试 隔离高风险模块 小步重构 + 频繁验证 避免一次性重写 建立可回滚机制 可运行示例 # 用单元测试保护关键行为 def calc(x): return x * 2 def test_calc(): assert calc(3) == 6 if __name__ == "__main__": test_calc() print("ok") 解释与原理 遗留系统的最大风险是“未知依赖”。 测试是最现实的安全网，能让你在改动时知道是否破坏行为。 常见问题与注意事项 一定要先写测试吗？ 是，否则无法安全改动。 重写是不是更快？ 通常不是，重写会遗漏隐性需求。 如何确定改造顺序？ 先改动频繁、影响大的模块。 最佳实践与建议 优先建立测试覆盖 用工具测量修改影响 逐步替换而非大爆炸式重写 小结 / 结论 遗留代码需要的是安全改动与渐进式重构。 测试是所有策略的核心。 参考与延伸阅读 Working Effectively with Legacy Code Refactoring (Martin Fowler) 元信息 阅读时长：7~9 分钟 标签：遗留代码、重构、测试 SEO 关键词：Legacy Code, 重构 元描述：遗留代码的安全改动策略与实践。 行动号召（CTA） 为你的遗留模块补一个最关键的测试，这是最划算的第一步。

副标题 / 摘要 重构不是“重写”，而是持续改善代码结构。本文给出重构适用场景、触发信号与控制风险的方法。 目标读者 需要维护遗留系统的工程师 负责技术债管理的团队 关注代码质量的开发者 背景 / 动机 不重构，技术债会持续累积；盲目重构，又可能影响交付。 理解“何时重构”比“怎么重构”更重要。 核心概念 技术债：当前效率换取未来成本 重构：不改变外部行为的结构改进 触发信号：重复代码、复杂度上升、修改成本高 实践指南 / 步骤 识别高频修改区域 先补齐测试 小步重构，持续验证 避免大规模“重写” 把重构与业务迭代结合 可运行示例 # 重构前 def calc_total(items): total = 0 for name, price in items: if price > 0: total += price return total # 重构后 def calc_total(items): return sum(price for _, price in items if price > 0) 解释与原理 重构的价值在于降低未来修改成本。 如果一个模块频繁修改且修改困难，就应该优先重构。 常见问题与注意事项 重构是不是浪费时间？ 如果能降低长期成本，就不是浪费。 什么时候不该重构？ 即将下线的模块不值得投入。 如何控制风险？ 小步重构 + 测试覆盖。 最佳实践与建议 把重构纳入日常开发 优先处理“高频痛点”模块 用指标评估重构收益 小结 / 结论 重构适合在“高频修改、高复杂度”的模块中进行。 控制风险的关键是测试与小步迭代。 ...