如果你在工作中遇到问题、在面试中遇到疑惑、在前端路上遇到了阻碍，都可以加入我们前端有道 Family，我会竭尽全力为大家答疑解惑，让我们共同努力，一同成长。

在产品快速迭代的中，由于追求开发速度，我们往往忽略代码的可读性与扩展性，不合理的使用条件判断会使我们的程序复杂度大大提升，同时也会使代码的可读性急速下降，后期维护难度也大大提高，真的让人脑壳疼。比如下方示例：

如果你接手这样一段代码，相信大家和我的心情是一样的：

本文归纳以下几种优化场景，希望对大家有所帮助。

• 单个if语句优化
• if/else语句优化
• 单个if多条件优化
• 多个else if分支优化

优化前

优化后

这种写法就比较清晰，简洁，好读！

另外如果遇到有很多的语句，但是执行的功能函数却是一致的情况，我们可以用”逻辑与“或者”逻辑或“来把他们合并成一个表达式。如果我们这些彼此独立的条件判断可以被视为同一次检查的场景时，一次检查的意图明显在可读性上优于多次的条件检查。我们来看一段代码片段:

我们可以通过合并逻辑，将上面代码修改为如下：

可以说在项目中遇到频率是最高，通常可以这两种策略优化

• 排非策略
• 三元运算符

比如用户登录场景，如果用户名和密码输入框为空，那么我们就提示用户”用户名和密码不能为空”；如果有值，就执行登录的操作。

优化前

优化后

表单提交时，需要提前排除那些提交不规范的内容，通常情况下，表单提交遇到不符合我们要求大于我们提交成功的情形，排非策略是个很不错的选择。

示例一

示例二

三元运算符相比来说，只需一行语句，代码简练精炼。

优化前

优化后

多个通常是一个糟糕的选择，它导致设计复杂，代码可读性差，并且可能导致重构困难。

我们经常遇到多个条件判断代码，随着逻辑复杂性的增加，的代码将变得越来越肿。

看一下逻辑绘制为流程图

从上面的流程图可以看出，不同条件分支的代码具有很高的耦合度。先前的条件判断将影响后续的代码流，并且此类代码在后续开发中难以维护。我们可以通过、和来优化代码。

看一下逻辑绘制为流程图

流程图显然更简单。而且，不同的条件分支之间没有嵌套，并且它们彼此独立。逻辑很清楚。

虽然语句在逻辑上确实比语句简单，但是代码本身也有点多。

其实我们对象枚举，将条件与特定操作相关联的键值。

流程图：

这种方式消除了所有条件语句，并使用键值对象存储条件和操作之间的关系。当我们需要根据条件执行代码时，我们不再需要使用或语句来处理相应的动作，我们只需从中提取相应的函数handleType并执行它即可。

实际上我们还可以通过来进一步的优化我们的代码。

对比的话，具有许多优点

• 对象的键只能是字符串或符号，而的键可以是任何类型的值。
• 我们可以使用属性轻松获取的键/值对的数量，而对象的键/值对的数量只能手动确定。
• 具有极快的查找速度。

上面的例子可以优化如下：

如果我们遇到多层复杂条件，语句优势就更明显了！

对于上述如此复杂的场景，是否可以通过来进行优化？

其实我们只需要将不同的判断语句连接成一个字符串，以便我们可以将条件和操作以键值格式关联在一起。

瞬间简单明了很多，有木有～～～

• if-else重构优化
• if-else逻辑判断优化
• How to Use if-else
• Javascript条件语句优化策略
• 深入浅出代码优化﹣if/else