4、重构工具链搭建：Git 分支策略 + SonarQube + IDE 自动化

说实话，很多团队做重构，代码写得挺好，但最后死在「合并冲突」和「上线回滚」上。我见过太多次了——几个人在同一个分支上改，改到后面谁都不敢动，一 merge 就是几百个冲突。

这一章，我就把我在几个中型项目里沉淀下来的工具链搭建经验拆开讲。说白了，就是三件事：分支怎么管、质量怎么卡、IDE 怎么帮你省时间。

4.1 Git 分支策略：Feature Branch + Release Branch

分支策略这东西，没有银弹。但我个人习惯用 Feature Branch + Release Branch 这套组合。为什么？因为它对重构场景特别友好。

你想想看，重构往往涉及大量文件改动，如果大家都在 develop 上直接改，冲突能改到怀疑人生。Feature Branch 把每个人的改动隔离起来，Release Branch 则负责「收口」和「稳定」。

4.1.1 分支模型总览

4.1.2 重构场景下的分支操作流程

假设你要重构一个订单模块的接口。我会这么做：

1. 从 develop 拉出 feature/refactor-order-api —— 隔离改动
2. 在 feature 分支上完成重构 —— 随便改，不影响别人
3. rebase develop —— 把最新的代码合进来，解决冲突
4. 发起 Pull Request —— 代码审查 + CI 跑测试
5. 合并到 develop —— 进入集成测试
6. 从 develop 拉出 release/v2.1.0 —— 做回归测试和 bug 修复
7. release 分支合并到 main 和 develop —— 上线

4.2 SonarQube 代码质量门禁

代码写得好不好，不能光靠人眼看。SonarQube 就是那个「不说话但很严格」的代码审查员。我一般在 CI 流程里把它设成 质量门禁（Quality Gate），不通过就不让合并。

4.2.1 核心指标与阈值

4.2.2 在 CI 中集成 SonarQube

以 GitHub Actions 为例，配置其实很简单：

name: SonarQube Scan
on:
  pull_request:
    branches: [develop, main]
jobs:
  sonar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: SonarQube Scan
        uses: sonarsource/sonarqube-scan-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
      - name: Quality Gate check
        uses: sonarsource/sonarqube-quality-gate-action@master
        timeout-minutes: 5

这个 workflow 会在每次 PR 时自动跑扫描。如果 Quality Gate 失败，PR 就不能合并。说白了，这就是一道「自动门禁」。

4.3 IDE 重构快捷键与自动化重构

工具用得溜，重构效率翻倍。我见过很多同事还在手动改方法名、手动移动类文件……其实 IDE 早就帮你准备好了。

4.3.1 IntelliJ IDEA 常用重构快捷键

4.3.2 自动化重构实战：提取方法

这是重构里最常用的操作。比如你有一段代码：

public void processOrder(Order order) {
    // 验证订单
    if (order == null || order.getItems().isEmpty()) {
        throw new IllegalArgumentException("订单无效");
    }
    // 计算总价
    double total = 0;
    for (OrderItem item : order.getItems()) {
        total += item.getPrice() * item.getQuantity();
    }
    // 保存订单
    order.setTotal(total);
    orderRepository.save(order);
}

选中「计算总价」那几行，按 Ctrl + Alt + M，输入方法名 calculateTotal，IDE 自动生成：

public void processOrder(Order order) {
    validateOrder(order);
    double total = calculateTotal(order);
    order.setTotal(total);
    orderRepository.save(order);
}

private double calculateTotal(Order order) {
    double total = 0;
    for (OrderItem item : order.getItems()) {
        total += item.getPrice() * item.getQuantity();
    }
    return total;
}

private void validateOrder(Order order) {
    if (order == null || order.getItems().isEmpty()) {
        throw new IllegalArgumentException("订单无效");
    }
}

你看，几秒钟的事。手动做的话，复制粘贴、改参数、调返回类型……至少一分钟，还容易出错。

4.3.3 自动化重构的「三不」原则

• 不改逻辑：重构只改变代码结构，不改变行为。改完跑测试，绿了才算数。
• 不一次改太多：每次只做一个重构操作。我见过有人一次提取三个方法、重命名两个类、移动五个文件……结果出问题了根本不知道是哪步引起的。
• 不跳过代码审查：IDE 自动生成的代码不一定完美。比如提取方法时，IDE 可能生成一个过长的方法名，或者参数顺序不合理。审查一下再提交。