重构

代码腐化与重构的痛点

随着业务迭代，代码库往往会逐渐积累坏味道（Code Smells）。长函数、深嵌套的条件分支、重复逻辑、魔法数字以及过大的参数列表，不仅让阅读变得困难，更让后续的扩展和维护充满风险。直接重写往往成本过高，而缺乏规范的随意修改又极易引入回归缺陷。我们需要一种结构化、可验证的方法来改善现有代码的内部结构，而不改变其外部行为。

结构化重构的工作流

这个技能将重构过程拆解为严谨的执行步骤，引导 AI 智能体按部就班地完成代码改造：

• 识别坏味道：扫描目标代码，定位长函数、死代码、过宽的变量作用域等常见质量问题，并标记具体位置。
• 选择重构模式：针对每个问题，选择合适的模式，如 Extract Method（提取方法）、Replace Magic Number with Named Constant（替换魔法数字）或 Introduce Parameter Object（引入参数对象）。
• 规划变更顺序：制定安全的执行序列。优先进行小而独立的变更，将相关操作分组，避免交错无关的修改。
• 应用重构：一次应用一种模式，保持原有的公共 API 和行为不变，并使用语言惯用结构（如 Python 的列表推导式、Rust 的模式匹配）。
• 测试验证：在每次转换后运行现有测试套件；若无测试，则生成轻量级单元测试覆盖重构路径。
• 记录变更：总结应用的重构、解决的坏味道及后续改进空间，作为提交信息或 PR 描述。

适用边界与最佳实践

重构并非万能药，在执行时需要严格遵守以下边界：

• 保持原子性：每次变更都应独立可验证且易于回滚。
• 禁止混合行为变更：绝不在同一时间进行重构与新功能开发。
• 保护公共 API：除非明确要求，否则内部结构调整不应强制调用者修改。
• 警惕边缘情况：对于生成代码（如 protobuf 桩）、供应商代码或性能关键型热路径，需谨慎处理甚至跳过。