文章目录开篇本文不会讨论什么一、重构前先问这段代码到底有什么问题1. 理解成本高2. 修改成本高3. 测试成本高4. 运行风险高5. 业务变化频繁二、不是所有难看的代码都值得重构三、让 AI 先做代码影响范围分析四、判断重构收益它能解决什么问题五、判断重构风险哪些地方最容易出问题1. 行为变化风险2. 调用方兼容风险3. 数据风险4. 性能风险5. 发布和回滚风险六、没有测试的核心代码不适合直接大改七、哪些代码通常应该谨慎触碰1. 资金和支付相关代码2. 权限和安全边界3. 数据迁移和历史兼容代码4. 消息消费和异步任务5. 线上问题刚修复的代码八、重构前让 AI 比较 3 种方案九、用“重构决策表”代替凭感觉决定十、一个可以直接复用的重构前评估 Prompt十一、重构开始后如何让 AI 控制修改范围十二、我的重构前检查卡十三、总结✍创作者全栈弄潮儿²⁰²⁶ 个人主页全栈弄潮儿²⁰²⁶ 专栏地址AI 编程进阶实战开篇看到一段难维护的代码时你会不会马上想重构很多开发者的第一反应是方法太长 ↓ 类太大 ↓ 命名太乱 ↓ 赶紧拆分和重写这件事本身没有错。问题在于代码“看起来不舒服”并不等于现在就值得重构。一段代码可能确实存在设计问题但它也可能很少被调用。即将被下线。没有稳定测试。依赖复杂的历史数据。与多个系统存在隐式约定。正处于高频变更期。重构收益小于验证和回归成本。如果没有先做评估重构很容易变成一次高风险的大范围改动原本想改善结构 ↓ 顺手修改业务逻辑 ↓ 影响多个调用方 ↓ 测试无法证明没有回归 ↓ 维护成本反而更高上一篇文章我们讨论了如何让 AI 辅助写单测重点是覆盖边界而不是凑覆盖率。重构前的第一件事也不是让 AI 直接改代码而是先确认这段代码真的值得改吗如果值得应该改到什么范围这篇文章分享一套我会使用的 AI 重构前评估流程帮助你把“想重构”变成一个可以判断、可以验证、可以控制风险的工程任务。本文不会讨论什么重构前评估不是给代码打分也不是让 AI 按照某种风格把整个项目重新写一遍。本文不会认为方法超过几十行就一定需要重构。认为使用设计模式越多代码就越好。建议为了追求整洁而扩大修改范围。把 AI 的重构建议直接当成最终方案。用静态复杂度指标代替业务影响和维护成本判断。本文关注的是一套更谨慎的思路确认问题 ↓ 评估收益 ↓ 识别风险 ↓ 限定范围 ↓ 确认验证方式 ↓ 再决定是否重构一、重构前先问这段代码到底有什么问题“代码很乱”不是一个足够具体的问题。在让 AI 评估之前我会先把问题拆成几类。1. 理解成本高表现为新开发者很难找到入口。方法名和实际行为不一致。业务规则隐藏在多层条件判断中。同一个概念在不同地方使用不同名称。2. 修改成本高表现为修改一个规则需要改很多文件。一个方法承担多个完全不同的职责。相同逻辑在多个模块重复实现。调用方无法明确知道方法的副作用。3. 测试成本高表现为很难构造测试数据。必须启动大量外部依赖才能验证。一个小改动会导致大量无关测试失败。关键分支没有稳定的自动化测试。4. 运行风险高表现为异常处理不清晰。事务边界不明确。并发行为不可预测。日志和监控无法定位问题。性能已经出现可观察的瓶颈。5. 业务变化频繁表现为相关需求持续增加。当前代码已经频繁修改。多个团队都需要复用这段能力。当前结构已经阻碍新功能交付。只有先把问题说清楚AI 才能判断“重构收益”而不是单纯指出风格问题。二、不是所有难看的代码都值得重构我会把待评估代码分成四种情况。类型典型特征建议高收益高频区高频调用、频繁修改、问题持续发生优先评估重构高风险核心区资金、权限、数据一致性和核心交易小步重构先补测试低频遗留区很少调用短期没有需求通常不要主动重构即将下线区已有替代方案或明确下线计划不要投入大规模重构代码质量问题和重构优先级不是一回事。一段最丑的代码可能不是最值得改的代码。一段看起来还能工作的代码如果每天都被修改、每次修改都引发回归反而更值得优先处理。三、让 AI 先做代码影响范围分析重构前我不会先问请帮我重构这个类。我会先让 AI 分析它影响了什么。请先不要重构代码只分析下面这个类或模块的影响范围。 请输出 1. 主要职责。 2. 对外暴露的接口。 3. 直接调用方。 4. 直接依赖的模块、数据库、缓存和外部服务。 5. 可能被依赖的隐式行为。 6. 关键副作用。 7. 相关测试和配置。 8. 如果修改它最可能影响哪些功能 请区分 - 可以从代码直接确认的事实。 - 基于命名或结构的推测。 - 需要通过测试、日志或运行环境确认的内容。 不要给出重构方案。这一步的目的是先画出“影响地图”。例如AI 可能发现一个看似普通的calculatePrice()方法实际上被以下地方使用下单接口。购物车预览。订单重试任务。对账脚本。管理后台手工修复工具。如果你只看当前调用方很容易误判修改范围。四、判断重构收益它能解决什么问题重构不是为了让代码看起来更漂亮而是为了降低未来成本。可以让 AI 按收益维度分析请评估重构这段代码可能带来的收益。 请从以下角度分别说明 1. 是否降低理解成本。 2. 是否降低后续修改成本。 3. 是否减少重复逻辑。 4. 是否提高测试可行性。 5. 是否改善错误处理和可观测性。 6. 是否解决已经发生过的线上问题。 7. 是否支持近期确定的业务变化。 每项请区分 - 当前已经存在的收益。 - 可能但尚未证明的收益。 - 仅属于代码风格改善的收益。一个有价值的重构目标最好能够落到具体结果重构前 新增一个订单状态需要修改 5 个条件分支。 重构后 订单状态规则集中在一个策略模块并且每种状态都有独立测试。或者重构前 一次支付失败后无法判断是否已经扣款。 重构后 支付结果、重试状态和补偿状态有明确的状态模型。“代码更优雅”可以是附带收益但不应该是唯一目标。五、判断重构风险哪些地方最容易出问题重构风险通常不只来自代码量。我会重点检查下面这些方面。1. 行为变化风险虽然目标是“不改变行为”但重构可能意外改变默认值。条件判断顺序。异常类型。返回值为空还是抛异常。状态流转顺序。边界时间处理。2. 调用方兼容风险需要确认方法签名是否被多个模块使用。返回对象是否被外部系统依赖。是否有未被静态搜索发现的反射、脚本或配置调用。是否有历史接口兼容要求。3. 数据风险重点看数据库读写顺序。事务边界。缓存更新时机。消息发布顺序。数据迁移和历史数据兼容。4. 性能风险重构后可能出现查询次数增加。循环中调用外部服务。缓存失效。对象创建和序列化增加。批处理变成逐条处理。5. 发布和回滚风险需要确认是否可以灰度发布。是否可以通过开关控制。新旧逻辑能否并行验证。回滚代码是否会与数据库结构不兼容。是否需要补偿已经产生的数据。可以让 AI 专门做风险审查请不要提供重构代码只分析这段代码的重构风险。 请按以下类别输出 1. 行为变化。 2. 调用方兼容。 3. 数据一致性。 4. 事务和并发。 5. 性能和资源。 6. 安全和权限。 7. 发布、灰度和回滚。 每个风险请说明 - 触发条件。 - 可能后果。 - 当前是否已有测试或监控。 - 最小验证方法。 - 风险等级。六、没有测试的核心代码不适合直接大改很多重构事故的根本原因不是重构方案错误而是没有“行为保护网”。如果一段核心代码没有测试AI 无法可靠判断当前行为是否是故意的。某个奇怪分支是否承载历史兼容。哪些异常是调用方依赖的。哪些边界是产品规则而不是偶然实现。因此重构前通常有两条路径已有足够测试 ↓ 评估并小步重构或者没有足够测试 ↓ 先补行为基线测试 ↓ 再开始重构可以让 AI 先帮你建立“重构前基线测试”请根据当前代码和已有业务行为设计重构前的基线测试。 目标不是评价当前实现是否优雅而是记录重构前已经存在的可观察行为。 请覆盖 1. 正常输入和返回结果。 2. 边界输入。 3. 异常类型和错误信息。 4. 数据库、缓存、消息和外部调用。 5. 关键状态流转。 6. 已知线上问题和历史兼容行为。 先输出测试场景和风险不要生成测试代码。基线测试不代表当前行为一定正确。它只是帮助你在重构后确认哪些行为保持不变 哪些行为是有意改变 哪些行为需要重新确认七、哪些代码通常应该谨慎触碰下面这些代码不是绝对不能重构但需要更高的证据和更小的步子。1. 资金和支付相关代码重点风险重复扣款。状态不一致。超时结果未知。重试和补偿行为改变。2. 权限和安全边界重点风险权限判断顺序改变。列表和批量接口绕过校验。敏感字段暴露。内外部身份边界混淆。3. 数据迁移和历史兼容代码重点风险老数据无法读取。新旧版本不兼容。回滚失败。重复迁移或数据丢失。4. 消息消费和异步任务重点风险重复消费。顺序改变。重试次数变化。死信和补偿逻辑丢失。5. 线上问题刚修复的代码如果一段代码刚刚修复过线上事故不建议马上做大规模结构调整。更稳妥的顺序是先保留回归测试 ↓ 确认线上指标恢复 ↓ 记录当前行为和风险 ↓ 拆成小步重构八、重构前让 AI 比较 3 种方案重构不只有“改”和“不改”两个选项。通常可以比较方案 A保持现状只补测试和注释 方案 B局部重构保持接口不变 方案 C重新设计模块边界和接口可以使用下面的 Prompt请针对下面的代码问题比较三种处理方案 方案 A不改变结构只补测试、日志或注释。 方案 B局部重构保持现有对外接口不变。 方案 C重新设计模块边界和调用方式。 请从以下角度比较 1. 能解决哪些问题。 2. 不能解决哪些问题。 3. 代码影响范围。 4. 测试和验证成本。 5. 发布和回滚难度。 6. 对性能、数据和兼容性的影响。 7. 适合当前阶段的前提。 最后给出推荐方案但不要默认“结构变化最大”的方案最好。很多时候方案 A 或方案 B 才是当前最合理的选择。九、用“重构决策表”代替凭感觉决定我会把 AI 的评估结果整理成一张决策表评估项结论证据影响修改频率近三个月频繁变更提交记录重构收益较高调用范围被 6 个模块使用代码搜索兼容风险较高测试覆盖核心分支缺少测试测试报告需要先补基线线上影响最近出现数据不一致事故记录需要优先修复行为下线计划暂无产品确认可以考虑中期重构回滚能力可灰度、可开关发布配置风险可控最后形成明确结论当前不建议做大规模重构。 建议先 1. 补充核心行为测试。 2. 抽出重复的价格计算逻辑。 3. 保持现有接口和数据结构。 4. 通过灰度验证新旧结果一致。 5. 等下一次业务迭代再评估模块级重构。这比“这段代码太乱应该重写”更容易获得团队共识。十、一个可以直接复用的重构前评估 Prompt请作为一名谨慎的高级开发者帮助我评估是否应该重构下面的代码。 一、当前问题 描述为什么想重构以及已经观察到的具体问题 二、业务背景 说明代码对应的业务功能、重要程度和近期变化 三、项目上下文 填写技术栈、模块边界、数据库、缓存、消息、外部依赖和发布方式 四、代码和调用关系 填写待评估代码、调用方、被调用方和相关测试 五、变更约束 - 允许修改 - 不允许修改 - 必须保持兼容的接口 - 不能接受的数据或行为变化 请先不要写重构代码按以下顺序完成评估 1. 总结当前代码的真实职责。 2. 列出已经确认的问题。 3. 区分结构问题、行为问题和业务问题。 4. 分析重构可能带来的收益。 5. 分析行为、数据、性能、兼容、安全、发布和回滚风险。 6. 找出直接调用方、间接调用方和隐式依赖。 7. 检查现有测试是否足以保护当前行为。 8. 比较“不重构、局部重构、整体重构”三种方案。 9. 给出推荐方案和推荐前提。 10. 输出最小可行重构范围。 11. 列出重构前必须补充的测试和验证。 输出要求 - 不要把个人代码风格偏好当成重构理由。 - 项目事实、代码推断、待确认项分开输出。 - 所有风险都要说明触发条件和验证方式。 - 优先推荐可回滚、可灰度、小步迭代的方案。 - 如果当前不值得重构请明确说明“不建议重构”的理由。这份 Prompt 最重要的一句话是如果当前不值得重构请明确说明“不建议重构”的理由。让 AI 有权给出“不改”的结论评估结果反而更可信。十一、重构开始后如何让 AI 控制修改范围当决定重构后也不要直接让 AI “优化整个模块”。可以继续限定请根据已经确认的重构范围设计第一步最小修改。 要求 1. 保持对外接口不变。 2. 不改变业务规则和返回结果。 3. 不修改数据库结构。 4. 不同时处理无关代码风格问题。 5. 每次只移动或拆分一个明确职责。 6. 给出修改前后的行为对照。 7. 给出必须执行的测试。 8. 如果发现范围会扩大请先停止并列出原因。重构过程中要尽量保持小步修改 ↓ 运行测试 ↓ 查看 Diff ↓ 确认行为 ↓ 再进入下一步如果一次改动跨越太多职责就很难判断到底是哪一步引入了问题。十二、我的重构前检查卡[ ] 我能具体说清楚当前代码的问题 [ ] 我知道这段代码被谁调用 [ ] 我区分了结构问题、行为问题和业务问题 [ ] 我知道重构能带来什么实际收益 [ ] 我评估了数据、事务、并发、性能和兼容风险 [ ] 我确认了是否存在隐式调用和历史行为 [ ] 核心代码已有足够测试或已经设计基线测试 [ ] 我比较过不重构、局部重构和整体重构 [ ] 我明确了允许修改和不允许修改的范围 [ ] 我优先选择可回滚、可灰度和小步迭代方案 [ ] 我没有把代码风格偏好当成重构理由 [ ] 每一步重构后都会执行测试并检查 Diff如果无法回答“为什么现在要改”和“如何证明改对了”就不应该急着开始重构。十三、总结重构不是代码越多改得越好也不是结构变化越大越有价值。真正值得重构的代码通常具备这些特征高频修改并持续产生维护成本。结构问题已经影响需求交付。线上风险可以被明确描述。重构收益能够被验证。有测试、监控或灰度手段保护行为。需要谨慎触碰的代码通常包括资金、支付和核心交易。权限和安全边界。数据迁移和历史兼容。消息消费和异步任务。刚刚修复线上问题的关键逻辑。我会坚持这套节奏先确认问题 ↓ 再评估收益 ↓ 识别影响和风险 ↓ 补充行为测试 ↓ 比较不同方案 ↓ 小步开始重构请记住最成熟的重构判断不是知道怎么改而是知道什么时候不该改。下一篇文章我们继续解决开发工作中的另一个高频任务我如何让 AI 帮我写技术文档而不制造废话。如果这篇文章对你有帮助欢迎点赞、收藏、关注专栏。也欢迎在评论区留言你遇到过哪些“看起来应该重构但最后决定不动”的代码✍坚持原创求关注点赞收藏
尧图网络