今天我们不讨论哪个写法读起来更优秀，不讨论对于性能而言哪个更完美，也不讨论哪种情况下对于判断语句是常量还是变量的选择，而是单纯从最简单的角度来看一下，为什么很多优秀的项目优秀的代码，最终选择了if else语句，而不是想当然的觉得必然是switch case语句。

目录

 一、需求场景描述

二、实现阶段一 

1.  对于鱼香肉丝的判断

2. 对于酸辣土豆丝的判断

3. 对于锅包肉的判断 

4. 各种各样的菜

三、不得不选择重构

四、持续迭代的需求

1. 菜品不断减少

2. 继续减少

3. 又只剩鱼香肉丝了

4. 一个case的改造 

---

 

 一、需求场景描述

今天只说一个最直白的场景，判断条件就是一个普通的变量，一个普普通通的字符串。例如你去一家餐厅吃饭，通过判断餐厅有没有你想吃的那道菜来决定你吃什么。

而这个项目历时N年，不止一个开发人员，所以下面我将会用小A 小B 小C 小D 来描述

二、实现阶段一 

1.  对于鱼香肉丝的判断

首先来了一个需求，要求如果餐厅有鱼香肉丝，那么就吃鱼香肉丝，这次由小A来开发

// 这里是一个变量，可能由服务端返回
var food = ''; 
if (food === '鱼香肉丝') {
    // todo 
    console.log('吃鱼香肉丝');
}

 由于最初之后一个判断，所以大多数开发者直接选择一个if else语句了事

2. 对于酸辣土豆丝的判断

过去一段时间了，这个项目代码一直没有碰，来了新需求，要求添加对于酸辣土豆丝的判断，这次还是小A来开发

// 这里是一个变量，可能由服务端返回
var food = ''; 
if (food === '鱼香肉丝') {
    // todo 
    console.log('吃鱼香肉丝');
} else if (food === '酸辣土豆丝') {
    console.log('吃酸辣土豆丝');
}

这个时候，一般人还是会选择继续追加else if 的判断，能简单追加一下就解决的问题，何必大费周章呢。

3. 对于锅包肉的判断 

可能又过了一段时间，又来了新需求，老板要求添加对于锅包肉的判断，而此时，小A已经离职了，新来了程序员小B

// 这里是一个变量，可能由服务端返回
var food = ''; 
if (food === '鱼香肉丝') {
    // todo 
    console.log('吃鱼香肉丝');
} else if (food === '酸辣土豆丝') {
    console.log('吃酸辣土豆丝');
} else if (food === '锅包肉') {
    console.log('吃锅包肉');
}    

如果你是小B，你接受了公司原来老旧的代码，遇到这个需求你会选择怎么做？明明知道这里需要重构一下，采用switch case语句了，但是迫于需求时间的压力，迫于线上正在跑着的需求的压力，你会怎么做？ 

4. 各种各样的菜

假如又过去了几个月，甚至一年，我们这个food变量已经不至对于前面3个菜的判断了，而是又新添加了尖椒肉丝，水煮肉片，孜然羊肉，然后小B离职了，小C来了；

然后又是继续的家常豆腐，西红柿鸡蛋。。。。。。小鸡炖蘑菇，烤全羊，大鱼大虾，手抓饼呢？

如果你是小C，你会如何去维护这段代码？

 

三、不得不选择重构

可能这个时候，已经是小D负责开发了，小D觉得不得不重构这段难以维护的代码了，他决定采用switch的先进能力，以case为抓手，再不断梳理以往需求的基础上，评估了所需的工时，预定了可能会出现问题的场景，并且找到项目组进行立项，开始了轰轰烈烈的代码重构工作。

var foodNew = '';
switch(foodNew ) {
    case '鱼香肉丝':
        console.log('吃鱼香肉丝');
        break;
    case '酸辣土豆丝':
        console.log('吃酸辣土豆丝');
        break;
    case '西红柿炒鸡蛋'：
        console.log('吃西红柿炒鸡蛋');
        break;
    ......
    ......
    ......
    default:
        console.log('喝自来水');
}

其实可以看出，这次重构为了弥补之前的不足，付出了相当大的代码，耗费人力财力，可能小D也因此而晋升了一下。

四、持续迭代的需求

1. 菜品不断减少

如果由于某种原因，比如疫情餐厅客流量减少，菜品备货必定减少，刚开始只是减少一些，我们将不需要再做荤菜类的判断，以及判断方法体内的代码，而这个时候已经是小E负责开发了，他选择了注释掉代码

2. 继续减少

可能需求又有所变动，最近新增了某一爱好的顾客，也就新增了一道水煮鱼，而其他菜品也逐渐减少。小E决定新branch一个分支，将之前的荤菜注释掉，将后来减少的菜品也注释掉，新增的继续加一个case来维护。

3. 又只剩鱼香肉丝了

还记得2015年，我们耗费了大量的成本，将代码重构为switch case，看上去代码可读性强了，有了一个崭新的开始，但一直到了2017年，负责开发的已经变为小H了，中间又经过了小F 小G的接手，代码已经又是乱糟糟了，而且到了这个时候，浩大的switch工程只剩下一个case,就像这样：

var foodNew = '';
switch(foodNew ) {
    case '鱼香肉丝':
        console.log('吃鱼香肉丝');
        break;
}

4. 一个case的改造 

如果某一天你需要出成绩，如果某一天你的PPT没有素材了，你一定要给自己找点事情干，而这个事情还要显得很亮眼，就比如说我们通过if else 的技术栈，通过将原来繁杂的逻辑进行调优，最终使线上代码更加稳健，可读性增强。于是有了这个样子：

var food = ''; 
var eatValue = (food === '鱼香肉丝') ? '吃鱼香肉丝': '西北风';
console.log(`吃${eatValue }`);

记住，没事做的时候，没有素材的时候，就搞重构，往项目里加一个图片也叫项目升级，加两个图片那叫持续性升级，改一行代码也叫项目重构，改两行代码那叫持续性重构，改一段那是颠覆性重构。