引言：復(fù)雜度的代價遠(yuǎn)比你想象得大

在 Java 后端系統(tǒng)演進(jìn)過程中，代碼復(fù)雜度是影響可維護(hù)性、穩(wěn)定性和迭代效率的核心因素。然而，復(fù)雜度往往被忽視，直到一次“小改動”引發(fā)線上事故，才被重新審視。

本文以“復(fù)雜度戰(zhàn)爭”為主題，系統(tǒng)性地探討如何識別、評估和治理代碼中的復(fù)雜性。本文不會停留在抽象原則，而是結(jié)合真實案例、Java 代碼示例和可落地的工程實踐，讓你了解你應(yīng)用的代碼復(fù)雜度，以及一個優(yōu)秀的開發(fā)同學(xué)應(yīng)該做到的避免代碼”腐爛“的最佳實踐。

讓我們以一些代碼案例引入今天的話題。（文中代碼案例皆為模擬案例）

案例一：圈復(fù)雜度過高導(dǎo)致大事故

在某一個大促開始的日子，訂單創(chuàng)建接口在高峰期響應(yīng)時間飆升，錯誤率突破 XX%。 緊急回滾？沒有最近的發(fā)布記錄。 最終排查日志發(fā)現(xiàn)，數(shù)據(jù)庫連接池被耗盡，而根源竟是一次兩周前的“微小優(yōu)化”。

開發(fā)同學(xué)為了支持一個新的促銷規(guī)則，在 OrderService.createOrder() 方法中加了這么一段邏輯：

if (user.isVip() && order.getTotalAmount().compareTo(BigDecimal.valueOf(100)) > 0) {
    try {
        Discount discount = promotionClient.getDiscount(order);
        if (discount != null && discount.isValid()) {
            order.setFinalPrice(order.getTotalAmount().subtract(discount.getValue()));
        } else {
            order.setFinalPrice(order.getTotalAmount());
        }
    } catch (Exception e) {
        // 靜默失敗，使用原價（開發(fā)本意是防崩）
        order.setFinalPrice(order.getTotalAmount());
    }
}

問題來了：這個 catch (Exception e) 不僅吞掉了業(yè)務(wù)異常，還捕獲了 數(shù)據(jù)庫連接超時異常（SQLException），導(dǎo)致外層事務(wù)未及時中斷，線程持續(xù)等待，最終拖垮連接池。

而這個方法本身已有 350 行，嵌套層級達(dá) 6 層，圈復(fù)雜度高達(dá) 38 —— 沒有人意識到，這次“小修”成了壓垮系統(tǒng)的最后一根稻草。

這不是孤例。類似的復(fù)雜度事故，正在無數(shù)系統(tǒng)中悄然上演。

案例二：重復(fù)代碼引發(fā)的數(shù)據(jù)錯亂

支付網(wǎng)關(guān)中，簽名計算邏輯在 AlipayProcessor、WechatPayProcessor 等 7 個類中重復(fù)出現(xiàn)：

String sign = DigestUtils.md5Hex(data + secretKey).toUpperCase();

某天，安全團(tuán)隊要求升級為 SHA-256，但只改了其中 4 個實現(xiàn)類。剩下的 3 個渠道繼續(xù)用 MD5，導(dǎo)致“無效簽名”錯誤激增，影響數(shù)萬筆交易。

工具掃描顯示：重復(fù)代碼率達(dá) 12%，而這些“看起來一樣”的代碼，分散在不同模塊，無人統(tǒng)一維護(hù)。

案例三：“上帝類”無人敢動

CRM 系統(tǒng)中的 CustomerManager 類長達(dá) 2800 行，承擔(dān)著客戶創(chuàng)建、積分計算、消息推送、審計日志、緩存同步等 8 種職責(zé)。

更可怕的是，每次調(diào)用 updateCustomer()，都會觸發(fā)一連串隱式行為：

public void updateCustomer(Customer customer) {
    customerRepo.save(customer);
    
    // 更新積分（即使只是改了個電話）
    rewardService.calculateReward(customer);
    
    // 推送消息（同步阻塞）
    messageQueue.send(buildUpdateMessage(customer));
    
    // 寫審計日志
    auditLogService.log("UPDATE", customer.getId(), getCurrentUser());
    
    // 刷新緩存
    cacheService.evict("customer:" + customer.getId());
}

新來的工程師想改個字段校驗邏輯，結(jié)果測出 5 個副作用 bug。從此，這個類成了團(tuán)隊心中的“禁區(qū)”。

案例四：微服務(wù)拆分后更慢了

物流平臺將單體拆分為訂單、路由、運力三個服務(wù)后，原本本地調(diào)用 routeService.findOptimalRoute() 的耗時從 50ms 變成 350ms（含網(wǎng)絡(luò)+序列化+重試）。

而最致命的是，當(dāng)路由服務(wù)不穩(wěn)定時，訂單服務(wù)因未配置熔斷，持續(xù)重試，反向拖垮整個鏈路。

復(fù)雜度沒有消失，只是從“代碼層面”轉(zhuǎn)移到了“分布式層面”。

這些事件背后，都有一個共同敵人：失控的代碼復(fù)雜度。

它不像內(nèi)存泄漏那樣立刻崩潰系統(tǒng)，也不像權(quán)限漏洞那樣被安全掃描抓出。它潛伏在每一次“先上線再說”的妥協(xié)里，在每一個沒人敢動的類中，在每一段“還能看懂”的嵌套邏輯中，緩慢侵蝕系統(tǒng)的生命力。

而作為 Java 后端開發(fā)者，尤其是架構(gòu)師，我們必須清醒地認(rèn)識到：

系統(tǒng)的可維護(hù)性，不取決于功能多強(qiáng)大，而取決于它的復(fù)雜度是否可控。

在這場看不見硝煙的 復(fù)雜度戰(zhàn)爭 中，我們不能靠運氣取勝。我們需要工具來度量它，需要原則來約束它，更需要實戰(zhàn)策略來持續(xù)降低它。

接下來，我們將深入探討：

• 哪些指標(biāo)能真正衡量代碼復(fù)雜度？
• 如何用合理的工具發(fā)現(xiàn)系統(tǒng)中的“復(fù)雜度熱點”？
• 在日常編碼中，如何寫出高質(zhì)量、低復(fù)雜度的 Java 代碼？
• 架構(gòu)層面，又該如何從源頭控制復(fù)雜度的增長？

代碼復(fù)雜度的主流定義

當(dāng)我們說一段代碼“太復(fù)雜”時，往往是一種直覺判斷。但真正的工程實踐需要可量化、可檢測、可改進(jìn)的指標(biāo)。所謂“復(fù)雜度”，并不是指代碼行數(shù)多，而是指理解、維護(hù)、修改它的認(rèn)知成本高。

在軟件工程領(lǐng)域，已有多個被廣泛認(rèn)可的復(fù)雜度維度，它們從不同角度揭示代碼的“健康狀況”。

我們將逐一介紹這些指標(biāo)的含義和實際案例，并按照其作用粒度分為三個層次：方法級、類級、繼承結(jié)構(gòu)級，幫助你系統(tǒng)化地識別和治理復(fù)雜度。

1. 圈復(fù)雜度（Cyclomatic Complexity）

定義

由 Thomas McCabe 提出，衡量程序中獨立執(zhí)行路徑的數(shù)量。路徑越多，測試難度越大，出錯概率越高。

計算規(guī)則：每有一個 if、for、while、case、catch，復(fù)雜度 +1；else 不加分。總分>5 需關(guān)注

危害

• 路徑爆炸 → 難以覆蓋所有分支
• 異常處理易遺漏
• 修改風(fēng)險高，容易引入副作用

實際案例

public BigDecimal calculateFinalPrice(Order order, User user, boolean hasCoupon) {
    BigDecimal total = order.getItems().stream()
        .map(Item::getPrice)
        .reduce(BigDecimal.ZERO, BigDecimal::add);

    if (total.compareTo(BigDecimal.valueOf(100)) > 0) {           // +1
        if (user.isVip()) {                                       // +2
            total = total.multiply(BigDecimal.valueOf(0.9));      // VIP 9折
        } else if (hasCoupon) {                                   // +3
            total = total.subtract(BigDecimal.valueOf(10));       // 減10元
        }
    }

    try {
        Promotion promotion = promotionClient.getActivePromotion(); // +4
        if (promotion != null && promotion.isValid()) {             // +5
            total = total.subtract(promotion.getDiscount());
        }
    } catch (RemoteException e) {                                   // +6
        log.warn("Failed to fetch promotion, using base price");
    }

    return total;
}

該方法圈復(fù)雜度 = 6

雖然不算極端，但已接近警戒線（>5 需關(guān)注）。若未來增加節(jié)日折扣、地區(qū)限制等條件，極易突破 10。

改進(jìn)方向

使用策略模式或規(guī)則引擎解耦判斷邏輯，或?qū)⒋黉N計算抽象為獨立服務(wù)。

2. 嵌套深度（Nesting Depth）

定義

代碼塊的嵌套層級，如 if 中套 if，再套 for 或 try。每增加一層，理解成本呈指數(shù)上升。。推薦閾值：≤3 層，超過即應(yīng)重構(gòu)。

實際案例：“左箭頭綜合征”

public boolean processRefund(RefundRequest request) {
    if (request != null) {
        Order order = orderService.findById(request.getOrderId());
        if (order != null) {
            if (order.getStatus() == OrderStatus.PAID) {
                PaymentRecord record = paymentService.findByOrder(order);
                if (record != null) {
                    try {
                        RefundResult result = paymentGateway.refund(record);
                        if (result.isSuccess()) {
                            refundRepo.save(new Refund(record, SUCCESS));
                            return true;
                        } else {
                            log.error("Refund failed: {}", result.getMessage());
                            return false;
                        }
                    } catch (PaymentException e) {
                        log.error("Payment system error", e);
                        return false;
                    }
                } else {
                    return false;
                }
            } else {
                return false;
            }
        } else {
            return false;
        }
    } else {
        return false;
    }
}

嵌套達(dá) 6 層，閱讀需不斷“縮進(jìn)-回退”，極易漏判條件。

改進(jìn)方向

使用衛(wèi)語句（Guard Clauses）提前返回

public boolean processRefund(RefundRequest request) {
    if (request == null) return false;

    Order order = orderService.findById(request.getOrderId());
    if (order == null || order.getStatus() != OrderStatus.PAID) return false;

    PaymentRecord record = paymentService.findByOrder(order);
    if (record == null) return false;

    try {
        RefundResult result = paymentGateway.refund(record);
        if (result.isSuccess()) {
            refundRepo.save(new Refund(record, SUCCESS));
            return true;
        } else {
            log.error("Refund failed: {}", result.getMessage());
            return false;
        }
    } catch (PaymentException e) {
        log.error("Payment system error", e);
        return false;
    }
}

邏輯扁平化，可讀性顯著提升。

3. 方法長度 & 類長度

定義

• 方法長度：單個方法的代碼行數(shù)（不含空行和注釋）
• 類長度：單個類的總行數(shù)

經(jīng)驗閾值：

• 方法 ≤ 50 行
• 類 ≤ 500 行

超出即可能違反 單一職責(zé)原則（SRP）

實際案例：上帝方法

// 一個長達(dá) 320 行的 createOrder() 方法
// 包含：參數(shù)校驗、庫存扣減、價格計算、優(yōu)惠應(yīng)用、積分發(fā)放、消息推送、日志記錄、異常重試……
public Order createOrder(CreateOrderRequest request) {
    // ... 320 行混合邏輯 ...
}

• 無法單元測試所有路徑
• 任何改動都可能引發(fā)未知副作用
• 新人完全看不懂執(zhí)行流程

改進(jìn)方向

public Order createOrder(CreateOrderRequest request) {
    validateRequest(request);                    // 校驗
    InventoryResult inv = inventoryService.deduct(request); // 扣庫存
    PriceCalculation calc = priceEngine.calculate(request); // 算價
    Order order = orderRepo.save(mapToEntity(request, calc)); // 保存
    rewardService.awardPoints(order);            // 發(fā)積分
    eventPublisher.publish(new OrderCreatedEvent(order)); // 發(fā)事件
    return order;
}

每個步驟獨立，便于替換、測試、監(jiān)控。

4. 類級復(fù)雜度：CK Metrics 四大經(jīng)典指標(biāo)

在面向?qū)ο笙到y(tǒng)中，僅看行數(shù)和方法數(shù)量還不夠。我們需要更精細(xì)的指標(biāo)來評估一個類的設(shè)計質(zhì)量。以下四個指標(biāo)合稱 CK Metrics Suite（Chidamber & Kemerer），是業(yè)界公認(rèn)的類復(fù)雜度評估標(biāo)準(zhǔn)。

（1）WMC（Weighted Methods per Class）

類的方法圈復(fù)雜度加權(quán)和

• 含義：一個類中所有方法的圈復(fù)雜度之和
• 示例：若某類有 5 個方法，圈復(fù)雜度分別為 6、8、5、12、4，則 WMC = 35
• 危害：WMC 越高，表示該類整體邏輯密度大，維護(hù)和測試成本高
• 建議閾值：≤45，否則應(yīng)考慮拆分

WMC 是對“類長度”的深化 —— 它不僅看有多少方法，更關(guān)注這些方法有多復(fù)雜。

（2）CBO（Coupling Between Object Classes）

類間耦合度

• 含義：一個類所依賴的外部類的數(shù)量
• 關(guān)聯(lián)概念：你在“依賴復(fù)雜度”一節(jié)中提到的 Efferent Coupling（Ce） 本質(zhì)上就是 CBO
• 危害：CBO 高 → 耦合強(qiáng) → 變動牽一發(fā)而動全身，不利于復(fù)用
• 建議閾值：≤7

小結(jié)：CBO 和 Efferent Coupling 指標(biāo)一致，只是術(shù)語來源不同。現(xiàn)代工具如 SonarQube 使用后者，但在學(xué)術(shù)和架構(gòu)評審中，“CBO”仍是通用說法。

（3）RFC（Response for a Class）

類的響應(yīng)集

• 含義：一個類能直接或間接響應(yīng)的方法總數(shù)，包括自身方法 + 它調(diào)用的外部方法
• 示例：OrderService.create() 調(diào)用了 paymentService.pay() 和 rewardService.award()，則這兩個調(diào)用也計入 RFC
• 危害：RFC 越大，表示該類的行為影響面越廣，測試組合爆炸，理解成本上升
• 建議閾值：≤50

（4）LCOM（Lack of Cohesion in Methods）

方法間內(nèi)聚性缺失

• 含義：衡量類中方法是否共享相同的字段。如果方法分為幾組，各自操作不同的屬性，則 LCOM 高

class User {
    private String name, email;
    private int loginCount;
    // updateProfile() 只用 name/email
    // incrementLogin() 只用 loginCount
    // → LCOM 高，說明職責(zé)不聚焦
}

• 危害：LCOM 高 → 類缺乏內(nèi)聚性 → 實際上承擔(dān)了多個職責(zé) → 應(yīng)拆分
• 改進(jìn)方向：識別方法訪問的字段簇，按業(yè)務(wù)邊界進(jìn)行類拆分

5. 繼承結(jié)構(gòu)復(fù)雜度

當(dāng)系統(tǒng)使用繼承時，還需關(guān)注類層次結(jié)構(gòu)本身的復(fù)雜性。

（1）DIT（Depth of Inheritance Tree）

繼承樹深度

• 含義：從當(dāng)前類到根類的最大路徑長度
• 示例：Animal → Mammal → Dog，Dog 的 DIT = 2
• 危害：DIT 越深，行為越難預(yù)測（父類邏輯隱式傳遞），調(diào)試?yán)щy
• 建議：DIT ≤ 3，過深應(yīng)考慮改用組合

（2）NOC（Number of Children）

子類數(shù)量

• 含義：一個類的直接子類個數(shù)
• 危害：NOC 過大（如 >10）說明父類抽象不夠通用，或繼承體系設(shè)計不合理
• 改進(jìn)方向：提取共性接口，或使用策略模式替代繼承

6. 重復(fù)代碼率（Duplication）

定義

系統(tǒng)中相同或高度相似代碼塊的比例。違背 DRY（Don't Repeat Yourself）原則。

實際案例：到處復(fù)制的簽名邏輯

// 在 AlipayProcessor 中
String sign = DigestUtils.md5Hex(data + apiKey).toUpperCase();

// 在 WechatPayProcessor 中（一模一樣）
String sign = DigestUtils.md5Hex(data + apiKey).toUpperCase();

// 在 UnionpayProcessor 中（還是一樣）
String sign = DigestUtils.md5Hex(data + apiKey).toUpperCase();

改進(jìn)：提取公共服務(wù)

@Component
public class SignatureService {
    public String sign(String data, String key) {
        return DigestUtils.sha256Hex(data + key).toUpperCase();
    }
}

總結(jié)

層級	指標(biāo)	推薦閾值	主要危害
方法級	圈復(fù)雜度	≤10	路徑爆炸，難測試
	嵌套深度	≤3	可讀性差
	方法長度	≤50 行	職責(zé)不清
類級	類長度	≤500 行	上帝類風(fēng)險
	WMC	≤45	整體邏輯密度過高
	CBO / Ce	≤7	耦合高，難維護(hù)
	RFC	≤50	行為泛濫，測試難
	LCOM	值越高越差	內(nèi)聚不足，應(yīng)拆分
繼承級	DIT	≤3	行為隱式傳遞
	NOC	不宜過大	抽象不充分
重復(fù)代碼	DRY	不宜過多	不要重復(fù)自己

復(fù)雜度評估工具

要打贏復(fù)雜度戰(zhàn)爭，光靠人工 Code Review 遠(yuǎn)遠(yuǎn)不夠。我們需要一套自動化的評估體系，在開發(fā)、提交、構(gòu)建、部署的每個環(huán)節(jié)持續(xù)監(jiān)控代碼質(zhì)量。

以下是目前 Java 生態(tài)中主流的復(fù)雜度評估方案與工具框架，它們可以單獨使用，也可集成形成完整的質(zhì)量門禁體系。

1. SonarQube：行業(yè)標(biāo)準(zhǔn)的靜態(tài)分析平臺

SonarQube 是目前最廣泛使用的代碼質(zhì)量管理平臺，支持對圈復(fù)雜度、重復(fù)率、代碼壞味、測試覆蓋率等指標(biāo)進(jìn)行可視化分析和閾值控制。

核心能力：

• 自動計算每個方法的圈復(fù)雜度，并標(biāo)記 >10 的熱點
• 檢測重復(fù)代碼塊，支持跨文件識別
• 提供“技術(shù)債”估算：修復(fù)所有問題需要多少人天
• 支持 Quality Gate（質(zhì)量門禁）：CI 中斷機(jī)制

集成方式：

<!-- Maven 配置示例 -->
<plugin>
    <groupId>org.sonarsource.scanner.maven</groupId>
    <artifactId>sonar-maven-plugin</artifactId>
    <version>3.9.1.2184</version>
</plugin>

執(zhí)行掃描：

mvn sonar:sonar \ -Dsonar.projectKey=my-app \ -Dsonar.host.url=http://localhost:9000 \ -Dsonar.login=your-token

推薦規(guī)則集：

• cognitive-complexity：認(rèn)知復(fù)雜度警告
• nested-if-else-depth：嵌套深度檢測
• function-complexity：方法復(fù)雜度閾值
• duplicated-blocks：重復(fù)代碼告警

2. IntelliJ IDEA 內(nèi)置分析工具

IntelliJ 提供了強(qiáng)大的本地靜態(tài)分析功能，開發(fā)者無需離開 IDE 即可發(fā)現(xiàn)復(fù)雜度問題。

由于 IDEA 迭代很快，使用方式各位開發(fā)同學(xué)可以自行搜索，

優(yōu)點：即時反饋，適合在編碼階段預(yù)防問題。

3. PMD 與 Checkstyle：輕量級靜態(tài)檢查工具

兩者常配合使用，用于 CI/CD 流水線中的自動化檢查。

PMD 特點：

• 專注代碼結(jié)構(gòu)問題
• 內(nèi)建規(guī)則：ExcessiveMethodLength, CyclomaticComplexity, NestedIfDepth

具體使用方式不展開描述了，大家可以自行查閱。

4. ArchUnit：架構(gòu)層面的依賴約束

ArchUnit 允許你用 Java 代碼定義架構(gòu)規(guī)則，防止模塊間非法依賴。

5. GitHub Actions / Jenkins 集成：將復(fù)雜度檢查納入 CI

通過 CI 腳本自動運行分析工具，實現(xiàn)“不達(dá)標(biāo)不合并”。

GitHub Actions 示例：

name: Code Quality
on: [push, pull_request]
jobs:
  sonar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK
        uses: actions/setup-java@v3
        with:
          java-version: '17'
      - name: Run SonarQube Analysis
        run: mvn verify sonar:sonar -Dsonar.qualitygate.wait=true
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

當(dāng)質(zhì)量門禁失敗時，PR 將被阻斷，強(qiáng)制開發(fā)者先修復(fù)問題。

總結(jié)

工具	適用場景	關(guān)鍵能力
SonarQube	團(tuán)隊級質(zhì)量管控	可視化 + 質(zhì)量門禁
IntelliJ	個人開發(fā)階段	實時提示
PMD / Checkstyle	CI 自動化檢查	規(guī)則驅(qū)動
ArchUnit	架構(gòu)治理	依賴斷言
CI/CD 集成	流程卡點	強(qiáng)制合規(guī)

面向低復(fù)雜度的代碼最佳實踐

知道什么是復(fù)雜度還不夠，關(guān)鍵是如何在日常編碼中主動降低它。本著面向代碼最佳實踐的原則，嘗試總結(jié)幾條有效降低代碼復(fù)雜的 Best Practise

原則一：單一職責(zé)

一個類或方法應(yīng)該只做一件事。職責(zé)越清晰，修改影響面越小。

反例：多功能服務(wù)類

@Service
public class OrderService {
    public void createOrder() { /* 創(chuàng)建 */ }
    public void sendNotification() { /* 發(fā)送通知 */ }
    public void calculateReward() { /* 計算積分 */ }
    public void logAudit() { /* 寫審計日志 */ }
}

這個類承擔(dān)了訂單生命周期的多個角色，任何變更都可能引發(fā)副作用。

改進(jìn)：按職責(zé)拆分

@Service
public class OrderCreationService { ... }

@Service
public class OrderNotificationService { ... }

@Service
public class OrderRewardCalculationService { ... }

職責(zé)分離后，各模塊可獨立測試、演進(jìn)。

原則二：優(yōu)先組合，而非繼承

繼承容易導(dǎo)致深層類層次結(jié)構(gòu)，增加理解和維護(hù)成本。組合更靈活、更可控。

反例：繼承濫用

class BasePaymentProcessor { }
class AlipayProcessor extends BasePaymentProcessor { }
class WechatPayProcessor extends BasePaymentProcessor { }
class HybridAlipayProcessor extends AlipayProcessor { } // 多層繼承

子類隱式繼承父類行為，難以預(yù)測執(zhí)行邏輯。

改進(jìn)：使用策略模式 + 組合

public interface PaymentStrategy {
    PaymentResult pay(BigDecimal amount);
}

@Service
public class AlipayStrategy implements PaymentStrategy { ... }

@Service
public class WechatPayStrategy implements PaymentStrategy { ... }

// 組合使用
public class UnifiedPaymentService {
    private final Map<String, PaymentStrategy> strategies;

    public UnifiedPaymentService(Map<String, PaymentStrategy> strategies) {
        this.strategies = strategies;
    }

    public PaymentResult pay(String type, BigDecimal amount) {
        return strategies.get(type).pay(amount);
    }
}

解耦清晰，擴(kuò)展性強(qiáng)。

原則三：善用函數(shù)式編程減少狀態(tài)污染

Java 8 引入的 Optional 和 Stream 不僅是語法糖，更是對抗復(fù)雜度的利器。

反例：消除 null 嵌套判斷

// 傳統(tǒng)寫法：多層 if 判斷
if (user != null) {
    Cart cart = user.getCart();
    if (cart != null) {
        List<Item> items = cart.getItems();
        if (items != null && !items.isEmpty()) {
            return items.stream().map(Item::getPrice).reduce(BigDecimal::add).orElse(ZERO);
        }
    }
}
return ZERO;

改進(jìn)：改為 Optional 鏈?zhǔn)秸{(diào)用

return Optional.ofNullable(user)
    .map(User::getCart)
    .map(Cart::getItems)
    .filter(items -> !items.isEmpty())
    .flatMap(items -> items.stream().map(Item::getPrice).reduce(BigDecimal::add))
    .orElse(ZERO);

邏輯扁平化，無嵌套，可讀性顯著提升。

原則四：設(shè)計模式不是炫技，而是解耦武器

合理使用設(shè)計模式可以有效分解復(fù)雜邏輯，但切忌過度設(shè)計。

反例：if-else

// 反例：一堆 if-else
if ("alipay".equals(type)) {
    return alipayClient.pay(amount);
} else if ("wechat".equals(type)) {
    return wechatClient.pay(amount);
} else if ("unionpay".equals(type)) {
    return unionpayClient.pay(amount);
}

改進(jìn)： 合理的設(shè)計模式

@Component
public class PaymentRouter {
    private final Map<String, PaymentClient> clients;

    public PaymentRouter(List<PaymentClient> clientList) {
        this.clients = clientList.stream()
            .collect(Collectors.toMap(PaymentClient::getType, c -> c));
    }

    public PaymentResult pay(String type, BigDecimal amount) {
        PaymentClient client = clients.get(type);
        if (client == null) throw new UnsupportedPaymentTypeException(type);
        return client.pay(amount);
    }
}

新增支付方式只需實現(xiàn)接口并注冊 Bean，無需修改路由邏輯。

原則五：命名即文檔，好名字勝過千行注釋

變量、方法、類的命名應(yīng)準(zhǔn)確傳達(dá)其意圖，避免縮寫和模糊詞匯。

反例：含義不明的數(shù)值枚舉

public List<Order> getList(int status) { ... } // status 是什么？1 表示成功？

改進(jìn)：明確的枚舉

public List<Order> findOrdersByStatus(OrderStatus status) { ... }

再如：

// 不清楚用途
private boolean flag;

// 明確語義
private boolean isEligibleForDiscount;

清晰的命名能讓代碼自解釋，大幅降低理解成本。

原則六：防御性編程 + 清晰的錯誤處理

提前攔截非法輸入，明確異常路徑，避免靜默失敗。

正例：使用衛(wèi)語句提前返回

public Order createOrder(CreateOrderRequest request) {
    if (request == null) {
        throw new IllegalArgumentException("Request cannot be null");
    }
    if (request.getItems() == null || request.getItems().isEmpty()) {
        throw new IllegalArgumentException("Order must have items");
    }
    // 正常邏輯開始……
}

正例：異常不要被吞掉

// 錯誤做法
catch (Exception e) {
    log.warn("Ignore error"); // 靜默吞掉
}

// 正確做法
catch (PaymentTimeoutException e) {
    log.error("Payment system timeout", e);
    throw new OrderCreationFailedException("Payment failed due to timeout", e);
}

確保異常傳播路徑清晰，便于定位問題。

小結(jié)：高質(zhì)量代碼的共同特征

原則	關(guān)鍵動作	效果
單一職責(zé)	拆分類與方法	降低變更風(fēng)險
組合優(yōu)于繼承	使用接口 + 注入	提升靈活性
函數(shù)式思維	使用 Optional/Stream	減少嵌套
設(shè)計模式	策略、工廠、責(zé)任鏈	解耦復(fù)雜邏輯
清晰命名	表達(dá)業(yè)務(wù)意圖	自解釋代碼
防御性編程	提前校驗 + 明確異常	提高健壯性

這些原則不是教條，而是在長期實踐中總結(jié)出的經(jīng)驗。堅持使用，你會發(fā)現(xiàn)自己寫的代碼越來越干凈，系統(tǒng)也越來越穩(wěn)健。

總結(jié)：堅持做正確的事

我們回顧一下最初的那幾個問題：

• 一個 catch (Exception e) 真的只是“防崩”嗎？
• 一段重復(fù)的簽名邏輯，值得花幾分鐘復(fù)制粘貼嗎？
• 一個 2800 行的類，真的是“歷史原因”無法改動嗎？

答案從來都不是“代碼本身有多難”，而是我們是否愿意為系統(tǒng)的長期健康付出短期成本。

優(yōu)秀的程序員不追求炫技式的“高復(fù)雜架構(gòu)”，而是堅持寫低復(fù)雜度、高表達(dá)力的代碼。他們知道，可維護(hù)性才是系統(tǒng)最核心的非功能需求。

工具可以幫助我們發(fā)現(xiàn)問題，原則可以指導(dǎo)我們重構(gòu)代碼，但最終，守護(hù)系統(tǒng)整潔的，是每一位工程師對質(zhì)量的敬畏之心。