条件逻辑简化：让代码不再「绕」

说实话，我见过太多项目死在「条件逻辑」手里。不是功能实现不了，而是代码里那些层层嵌套的 if-else，像一团乱麻，谁碰谁头疼。

我自己就踩过这个坑。几年前接手一个支付系统，核心方法里嵌套了 7 层 if-else。改一个 bug，要花半天理清逻辑。改完还不敢保证没引入新问题。那感觉，就像在雷区里跳舞。

所以今天，咱们聊聊怎么把这些「绕」的条件逻辑拆开、理顺。我总结了 6 种实用手法，每一种都在实战中救过我。

1. 分解条件表达式：把大块逻辑拆成小函数

条件表达式太长，阅读负担就重。我习惯把每个分支的逻辑提取成独立函数。这样主流程清晰，细节被封装。

举个例子，你可能会写出这样的代码：

if (date.before(SUMMER_START) || date.after(SUMMER_END)) {
    charge = quantity * winterRate + winterServiceCharge;
} else {
    charge = quantity * summerRate;
}

嗯，一眼看过去还行。但如果逻辑再复杂点呢？我建议这样拆：

if (isWinter(date)) {
    charge = winterCharge(quantity);
} else {
    charge = summerCharge(quantity);
}

function isWinter(date) {
    return date.before(SUMMER_START) || date.after(SUMMER_END);
}

function winterCharge(quantity) {
    return quantity * winterRate + winterServiceCharge;
}

function summerCharge(quantity) {
    return quantity * summerRate;
}

你看，主函数变成了「如果冬天，算冬季费用；否则算夏季费用」。读起来像自然语言。每个小函数只做一件事，测试也方便。

2. 合并条件表达式：把分散的「或」逻辑收拢

有时候，多个条件分支执行相同的操作。这时候分散写就是冗余。我建议合并它们。

比如这段代码：

if (age < 18) return "未成年人";
if (isStudent) return "未成年人";
if (unemployed) return "未成年人";

三个条件都返回同一个结果。为什么不合并？

if (age < 18 || isStudent || unemployed) {
    return "未成年人";
}

更优雅的做法是提取成一个函数：

if (isMinor(age, isStudent, unemployed)) {
    return "未成年人";
}

function isMinor(age, isStudent, unemployed) {
    return age < 18 || isStudent || unemployed;
}

这样，判断逻辑被集中管理。以后改规则，只改一个地方。

3. 以卫语句取代嵌套条件：提前返回，减少缩进

嵌套条件最大的问题，是让读者记住「当前在哪个分支里」。我见过最夸张的代码，缩进了 8 层。改起来想哭。

卫语句的思路很简单：把异常情况、边界条件提前返回。剩下的就是正常流程。

看这个例子：

function getPayAmount() {
    let result;
    if (isDead) {
        result = deadAmount();
    } else {
        if (isSeparated) {
            result = separatedAmount();
        } else {
            if (isRetired) {
                result = retiredAmount();
            } else {
                result = normalPayAmount();
            }
        }
    }
    return result;
}

三层嵌套，读起来费劲。用卫语句改一下：

function getPayAmount() {
    if (isDead) return deadAmount();
    if (isSeparated) return separatedAmount();
    if (isRetired) return retiredAmount();
    return normalPayAmount();
}

是不是清爽多了？每个条件都是「如果...就返回」。没有 else，没有嵌套。逻辑一目了然。

我曾经在一个订单处理系统里，用卫语句把 200 行的嵌套函数缩减到 80 行。bug 率直接降了一半。你想想看，这多值。

4. 以多态取代条件表达式：让对象自己决定行为

当条件判断基于对象的类型时，用多态比用 if-else 更优雅。这也是面向对象设计的精髓。

举个例子，计算不同鸟类的飞行速度：

function getSpeed(bird) {
    switch (bird.type) {
        case 'EuropeanSwallow':
            return 35;
        case 'AfricanSwallow':
            return bird.numberOfCoconuts > 0 ? 30 : 40;
        case 'NorwegianBlue':
            return bird.isNailed ? 0 : 10 + bird.voltage;
        default:
            return null;
    }
}

每次新增鸟类，都要改这个函数。容易漏，也容易引入 bug。

用多态重构后：

class Bird {
    getSpeed() { return null; }
}

class EuropeanSwallow extends Bird {
    getSpeed() { return 35; }
}

class AfricanSwallow extends Bird {
    constructor(numberOfCoconuts) {
        super();
        this.numberOfCoconuts = numberOfCoconuts;
    }
    getSpeed() {
        return this.numberOfCoconuts > 0 ? 30 : 40;
    }
}

class NorwegianBlue extends Bird {
    constructor(isNailed, voltage) {
        super();
        this.isNailed = isNailed;
        this.voltage = voltage;
    }
    getSpeed() {
        return this.isNailed ? 0 : 10 + this.voltage;
    }
}

调用方只需要 bird.getSpeed()。新增鸟类，只需新增一个子类。不改已有代码，符合开闭原则。

5. 引入特例：用对象封装「空」或「边界」情况

代码里最常见的重复，就是到处检查 null 或特殊值。比如：

if (customer === null) {
    plan = BillingPlan.basic();
} else {
    plan = customer.getPlan();
}

如果这种检查散落在各处，改起来很痛苦。我习惯引入一个「特例对象」来封装这些边界行为。

class NullCustomer extends Customer {
    getPlan() {
        return BillingPlan.basic();
    }
    // 其他方法也返回合理的默认值
}

// 使用
plan = customer.getPlan();  // 不再需要 null 检查

这个模式也叫「空对象模式」。它让调用方不再关心「是不是 null」，而是直接调用方法。特例对象会返回合理的默认值。

6. 知识体系总览

下面这张图，帮你理清这 6 种手法的关系和适用场景：

总结一下

这 6 种手法，说白了就是让条件逻辑「显式化」。把复杂的判断拆开，把重复的收拢，把嵌套的拉平，把类型相关的交给多态，把边界情况封装成特例。

我个人的经验是：不要一次性重构所有条件逻辑。挑最乱的那个函数，用一两种手法改掉。跑通测试，提交。下次再改另一个。积少成多，代码质量会慢慢提升。

记住，重构不是炫技。是为了让下一个读你代码的人（很可能就是三个月后的你自己）少掉几根头发。