优秀的代码最终选择if else,还是switch case

今天我们不讨论哪个写法读起来更优秀,不讨论对于性能而言哪个更完美,也不讨论哪种情况下对于判断语句是常量还是变量的选择,而是单纯从最简单的角度来看一下,为什么很多优秀的项目优秀的代码,最终选择了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 }`);

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

猜你喜欢

转载自blog.csdn.net/xingyu_qie/article/details/128810177