code-simplification

code-simplification - 代码简化技能

技能概述

code-simplification 是一个帮助开发者简化代码复杂度的技能，在保持代码行为完全不变的前提下，提升代码的可读性、可维护性和可扩展性。适合在功能完成但代码质量欠佳、代码审查发现问题、或遇到难以理解的遗留代码时使用。

适用场景

核心功能

常见问题

代码简化会改变代码的行为吗？

不会。代码简化的核心原则就是"保持行为完全不变"。这意味着所有输入输出、错误处理、边界情况和副作用都必须保持一致。在简化过程中，建议运行现有测试套件验证，确保不引入任何行为变更。如果测试需要修改才能通过，说明可能改变了代码行为。

什么时候应该简化代码，什么时候应该重写？

当代码能正常工作但难以理解、维护时，应该简化。当代码的架构设计本身有根本性问题，或者修复成本超过重写成本时，才考虑重写。简化适合渐进式改进局部问题，重写适合解决系统性问题。大多数情况下，简化比重写更安全、成本更低。

如何避免过度简化代码？

遵循"保持平衡"原则：不要过度内联、不要合并不相关的逻辑、不要为了减少行数而牺牲可读性。如果一个辅助函数给了概念一个清晰的名字，保留它反而比内联更易读。简化后，如果代码变得更难理解或审查，说明可能过度简化了，应该回退。另一个重要原则是"作用域限定在改动范围"，避免对无关代码进行"顺便简化"。

长函数应该如何拆分？

首先理解函数的完整职责和调用关系（Chesterton's Fence 原则），然后识别函数内的独立职责块。每个拆分出的函数应该有清晰、描述性的名称，表达"做什么"而不是"怎么做"。避免一次拆分过多，建议逐步拆分并运行测试验证。拆分时还要注意是否真的简化了代码——有时两个简单函数比一个复杂函数更好，但有时为了整体一致性需要保持现有结构。

代码简化会影响性能吗？

通常不会。代码简化主要关注可读性，而非性能。极少数情况下，"更简单"的版本可能比原版略慢（例如用 Map 替代多次数组查找）。如果代码是性能关键路径，简化前应该测量性能影响。大多数业务代码的性能瓶颈不在代码结构本身，而在算法选择、I/O 操作或数据库查询，因此简化带来的可维护性收益远大于可能的微小性能损失。

代码简化时如何确保不引入 bug？

渐进式修改：每次只做一项简化，然后立即运行测试套件验证。如果测试失败，回退该修改重新考虑。充分利用现有测试作为安全网，如果缺少测试，考虑先补充测试再简化。对于关键逻辑，可以对比简化前后的输入输出是否一致。遵循"范围限定在改动"原则，避免同时修改多处代码导致难以定位问题源。