代码简化

当代码「能用但难读」时，问题出在哪？

你可能遇到过这样的场景：功能测试全绿，但接手的同事看着深层嵌套的if-else、散落多处的重复逻辑、语义模糊的temp命名反复追问意图；代码评审时，性能关键路径之外的分支因为「写得急」留下复杂结构，后续每次调整都要先在脑子里模拟一遍执行流程。这些「不致命但影响维护效率」的复杂度，本质是代码表达方式偏离了可读性的轨道——复杂代码不会立刻出错，却会让每一次后续修改都变得昂贵。

如何让简化真正「安全且有效」？

这个技能的核心是行为零变更的简化逻辑，遵循五条铁律：

• 精确保留所有行为：输入、输出、副作用、错误处理逻辑、边界条件必须与原代码完全一致。不确定是否能保持行为时，果断停止简化。
• 遵循项目固有约定：以CLAUDE.md或现有代码风格为基准，而非套用外部规范。比如项目习惯用helper_xxx命名辅助函数，就不要改成utils_yyy。
• 优先处理「真实痛点」：重点简化深层嵌套逻辑、过长函数、重复代码块，而非追求行数减少。例如将嵌套3层的if-else拆分为is_valid_xxx和handle_xxx两个函数，比强行压缩行数更有意义。
• 分阶段验证合理性：先列出所有可能的简化方向，再逐个评估是否改变行为，最后通过「新人能否更快理解」的测试来确认效果。
• 拒绝形式化简化：如果代码已足够清晰，或即将整体重构，简化反而会造成不必要的时间消耗。

何时不该用？这些边界要明确

• 代码本身已符合项目可读性标准，无需刻意简化
• 你还没完全理解代码逻辑——先读懂再动手
• 性能关键路径上，「简化后更慢」的改动必须排除
• 模块计划整体重写，此时的简化属于无效劳动

简化代码的终极目标，是让下一个接手的人不用再花半小时逆向逻辑。这个技能帮你在不破坏功能的前提下，把「能用的代码」变成「好读的代码」。