AI 时代,大家现在都是怎么重构老项目的?

查看 34|回复 3
作者:Paxton886   
目前有一些运行多年的 Java / Spring Boot 项目,随着业务不断迭代,逐渐积累了不少典型问题:
  • Service 越写越大,一个类几千行
  • 历史逻辑很多,不敢轻易删除
  • 模块之间耦合越来越严重
  • 重复代码比较多
  • 一些早期设计已经不太适合现在的业务
  • 单测覆盖率不高,导致重构风险比较大
  • 很多业务逻辑只有看代码甚至问老开发才能理解

    以前做这种项目的重构,基本都是人工:

    读代码 → 梳理业务 → 找问题 → 设计新结构 → 小范围修改 → 测试 → 再继续改

    现在 Codex 、Claude Code 这类 Coding Agent 已经可以直接理解和修改整个 Repo ,所以比较好奇,大家有没有真正把 AI 用到大型存量项目重构上?
    最近看到的一些思路
    比如给 Agent 配置专门的 Skill / Rules ,然后让 Agent 按类似下面的流程工作:

    扫描项目 → 分析架构和依赖 → 找 Code Smell → 生成重构 Plan → 人工确认 → 分模块修改 → 编译 / 单测 → Diff Review

    感觉相比直接跟 AI 说一句:

    「帮我重构这个项目」

    这种方式可能更可控。
    另外也看到有人使用 OpenRewrite + AI Agent,让 AI 负责分析和决策,OpenRewrite 负责 AST 级别的批量重构。
    比较想请教大家
    [ol]
  • 现在大家会让 Codex / Claude Code 直接参与老项目重构吗?
  • 有没有比较成熟的 Java / Spring Boot Refactoring Skill 、Prompt 、Rules 或 Workflow 推荐?
  • 对于几十万甚至上百万行的项目,AI 怎么建立足够完整的项目上下文?
  • AI 重构最大的坑是什么?业务逻辑误改、上下文不足,还是测试覆盖率?
  • 有没有团队已经形成「 AI Code Review → Refactoring Plan → 自动修改 → Test → Review 」这样的工程化流程?
  • AI 时代还有没有必要专门投入人力做一次“大重构”,还是更适合让 AI 在日常需求开发过程中持续渐进式重构?
    [/ol]
    目前我的感觉是:

    AI 最大的价值可能不是“帮忙写重构后的代码”,而是把过去成本很高的“理解老代码 + 找问题 + 制定重构方案 + 验证修改”这条链路大幅压缩。

    不知道大家实际用下来怎么样,有没有踩过坑或者比较成熟的实践方案?
    尤其想听听真正拿 AI 重构过生产环境 Java 老项目的经验。

    重构, AI, 存量

  • dingwen07   
    感觉关键在于这个项目有没有充足的测试用例,复杂还没有足够的测试那 AI 顶多能做到重构完之后跑起来
    有一说一,让 AI 直接整个重写和去重构哪个更好呢
    lmmlwen   
    无非是先做项目分析,我的流程和你说的其实大差不差,之不过我的`扫描项目 → 分析架构和依赖 → 找 Code Smell`直接使用 Understand-Anything 这东西
    Paxton886
    OP
      
    @dingwen07 确实,我觉得测试覆盖才是 AI 重构的基础。没有足够的测试,AI 能保证的更多是编译通过、服务能启动,但很难证明业务行为没变,尤其是历史项目里很多规则其实只存在于代码和线上数据里。至于重写还是重构,我觉得得看项目和其他模块耦合程度
    您需要登录后才可以回帖 登录 | 立即注册

    返回顶部