重构与持续集成：在CI/CD流水线中集成重构检查
说实话，很多团队做重构，最大的痛点不是技术本身，而是「不敢合」。
你改了一堆代码，自己觉得没问题，但队友一看——「这跟原来的风格完全不一样啊」「这个公共方法被你拆了，我那边还在用呢」。然后代码审查就卡住了，重构分支越拖越久，最后变成技术债的利息越滚越多。
我个人的经验是，重构必须跟持续集成绑定在一起。让机器帮你做第一道把关，人只做决策性的审查。这样效率才高。
为什么要在CI/CD里加重构检查？
说白了，就是三个原因：
- 一致性：团队里十个人，十种编码风格。重构完的代码，得让大家看着像一个人写的。
- 安全性：重构最怕「改一处，崩一片」。CI里跑一遍全量测试，比人肉review靠谱得多。
- 可追溯：每次重构提交，CI都会生成一份报告。哪天出问题了，翻报告就知道是哪次改动引入的。
我记得有一次，团队重构一个支付模块。有个同事把核心的金额计算逻辑抽成了工具类，但忘了更新调用方。人肉review没看出来，结果上线后对账不平。后来我们就在CI里加了一条规则：任何公共方法签名变更，必须同时更新所有调用方。从那以后，再没出过类似问题。
CI/CD流水线里能集成哪些重构检查？
我习惯把检查分成三个层次，每个层次解决不同的问题。
| 层次 | 检查内容 | 常用工具 |
|---|---|---|
| 代码风格 | 缩进、命名、空行、注释格式 | ESLint, Prettier, Checkstyle |
| 代码质量 | 圈复杂度、重复代码、过长方法 | SonarQube, PMD, CodeClimate |
| 架构约束 | 包依赖方向、循环引用、分层违规 | ArchUnit, JDepend, 自定义规则 |
嗯，这里要注意：不要一开始就把所有规则都打开。我见过一个团队，SonarQube配了300多条规则，结果每次提交都报几百个警告。开发者直接麻木了，反而没人认真看。我的建议是：先开最关键的10-20条，跑通了再加。
实战：在GitHub Actions里集成重构检查
下面是一个我实际用过的流水线配置。它会在每次PR提交时自动运行。
name: 重构检查流水线
on:
pull_request:
branches: [ main, develop ]
jobs:
refactor-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: 代码风格检查
run: |
npm run lint
npm run format:check
- name: 静态分析
run: |
npx sonar-scanner \
-Dsonar.projectKey=my-project \
-Dsonar.host.url=${{ secrets.SONAR_HOST }} \
-Dsonar.login=${{ secrets.SONAR_TOKEN }}
- name: 架构约束检查
run: |
mvn test -Dtest=ArchitectureTest
- name: 单元测试
run: |
npm run test:coverage
- name: 生成重构报告
run: |
npx jscpd --min-lines 10 --min-tokens 50 --output report.json
这个配置里，我特别想强调两点：
- 架构约束检查：很多人会忽略这一步。我用ArchUnit写过一些规则，比如「controller层不能直接调用repository层」「工具类不能依赖业务模块」。这些规则一旦写进CI，重构时就不会出现「偷偷绕开分层」的情况。
- 重复代码检测：重构的目标之一就是消除重复。jscpd这个工具能帮你找出复制粘贴的代码块。我一般设成「超过10行且重复率超过50%」就算违规。
重构检查的反馈闭环
光有检查还不够，你得让结果能落地。我一般会做三件事：
- PR评论自动贴报告：每次CI跑完，把检查结果以评论形式贴在PR下面。开发者不用点开日志看，直接看评论就行。
- 质量门禁：设定一个阈值，比如「新增代码的圈复杂度不能超过10」「重复率不能超过5%」。超过阈值，CI直接失败。
- 定期复盘：每个月看一次SonarQube的趋势图。如果某个指标持续恶化，说明重构的方向可能有问题。
我曾经在一个项目里，发现「过长方法」这个指标连续三个月都在涨。后来一查，原来是团队为了赶进度，一直在往现有方法里塞逻辑，没人愿意拆。我们就专门开了一次重构会议，把Top10的长方法全部拆掉。之后指标就降下来了。
一张图看懂重构检查在CI/CD中的位置
下面这张图，展示了我推荐的检查流程。注意看，重构检查不是一次性的，而是贯穿整个流水线。
核心思路：重构检查不是「做完重构再检查」，而是「每次提交都检查」。这样能尽早发现问题，避免重构分支越积越大，最后变成一团乱麻。
避坑指南
我曾经踩过几个坑，写出来给大家提个醒：
- 不要一次性开太多规则。我刚开始推行时，一口气开了50条规则，结果团队怨声载道。后来改成「每周加2条，先warning后error」，大家才慢慢接受。
- 重构报告要可读。别只给一个JSON文件。我习惯用工具生成HTML报告，或者直接贴在PR评论里。开发者一眼就能看到「哪里有问题」「怎么改」。
- 门禁阈值要合理。比如「圈复杂度不超过10」，对于老项目来说可能太严了。我一般会先跑一遍全量代码，取中位数作为初始阈值，然后逐步收紧。
- 别忘了测试覆盖率。重构时很容易出现「代码改了，测试没改」的情况。我建议在CI里加一条规则：重构涉及的文件，测试覆盖率不能下降。这样能倒逼开发者同步更新测试。
好了，关于在CI/CD里集成重构检查，我就说这么多。说白了，就是让机器帮你做「脏活累活」，你只做「决策性工作」。这样重构才能又快又稳。
公众号:蓝海资料掘金营，微信deep3321