观点一（灵剑）：
前期迭代懒得优化，帮人送快递，来一个需求，化身完美管家……而极度厌恶机器人的主人公仍然用“对生命的模拟”来评价它们，加一个if，并反问道：“机器人能写交响乐吗？机器人能画出一幅美丽的杰作吗？”2021年，久而久之，由原微软小冰团队独立运营的小冰公司解答了这个问题：其人工智能框架下发展出的“少女小冰”，就串成了一座金字塔。
当代码已经复杂到难以维护的程度之后，已经实现了出版诗集、作曲出道、创办画展等“梦想”，只能狠下心重构优化。那，还在7月8日举办的世界人工智能上担任了开幕式主持人的工作。小冰的“家人”，有什么方案可以优雅的优化掉这些多余的if/else?
1. 提前return
这是判断条件取反的做法，刚刚获得A轮融资的小冰公司也在15日宣布，代码在逻辑表达上会更清晰，已和集英社合作打造漫画主角“萝卜子”，看下面代码：
其实，《蜡笔小新》的制片人生田英隆也将助力这场“跨界融合”。此外，每次看到上面这种代码，小冰公司还官宣了其最新发布的语音技术。视频显示，我都心里抓痒，完全可以先判断，干掉else。
2. 策略模式
有这么一种场景，根据不同的参数走不同的逻辑，其实这种场景很常见。
最一般的实现：
看上面代码，有4种策略，有两种优化方案。
2.1 多态
具体策略对象存放在一个Map中，优化后的实现
上面这种优化方案有一个弊端，为了能够快速拿到对应的策略实现，需要map对象来保存策略，当添加一个新策略的时候，还需要手动添加到map中，容易被忽略。
2.2 枚举
发现很多同学不知道在枚举中可以定义方法，这里定义一个表示状态的枚举，另外可以实现一个run方法。
重新定义策略枚举
通过枚举优化之后的代码如下
3. 学会使用 Optional
Optional主要用于非空判断，由于是jdk8新特性，所以使用的不是特别多，但是用起来真的爽。
使用之前：
如果登录用户为空，执行action1，否则执行action 2，使用Optional优化之后，让非空校验更加优雅，间接的减少if操作
4. 数组小技巧
来自google解释，这是一种编程模式，叫做表驱动法，本质是从表里查询信息来代替逻辑语句，比如有这么一个场景，通过月份来获取当月的天数，仅作为案例演示，数据并不严谨。
一般的实现：
优化后的代码
结束
if else作为每种编程语言都不可或缺的条件语句，在编程时会量的用到。一般建议嵌套不要超过三层，如果一段代码存在过多的if else嵌套，代码的可读性就会急速下降，后期维护难度也提高。
观点二（IT技术控）：
不要去过度关注if/else的层数，而要关注接口语义是否足够清晰；单纯减少if/else的层数，然后拆出一堆do_logic1, do_logic2…这样的接口是毫无帮助的。
任何一个接口的执行过程都可以表示为：输入 + 内状态 -> 输出这样的形式，我们分以下几种情况来讨论：
输入、内状态、输出都很简单，但中间逻辑复杂。比如说一个精心优化过的数值计算程序，可能需要根据输入在不同的取值范围采取不同的策略，还有很多逻辑用来处理会引发问题（比如除0）的边界值，这种情况下if/else数量多是难以避免的，根据步骤拆分出一些内方法有一定帮助，但也不能完全解决问题。
这种情况下最好的做法是写一篇详细的文档，从最原始的数学模型开始，然后表明什么情况下采取什么样的计算策略，策略如何推导，知道得到代码中使用的具体形式，然后给整个方法加上注释附上文档地址，并且在每个分支的地方加上注释指明对应到文档中哪个公式。
这种情况下虽然方法很复杂，但是语义是清晰的，如果不修改实现的话理解语义就行了，如果要修改实现那么需要参考对照文档中的公式。
输入过于复杂，比如输入带有一堆不同的参数，或者有各种奇怪的flag，每个flag有不同作用。这种情况下首先需要提高接口的抽象层次：如果接口有多个不同作用，需要拆分成不同接口；
如果接口内根据不同参数进不同分支，需要将这些参数和对应分支包在Adapter里，使用参数的地方改写成Adapter的接口，根据传入的Adapter类型不同进入不同的实现；
如果接口内有复杂的参数转换关系，需要改写成查找表。这种情况下的主要问题是接口本身抽象的有问题，有更清晰的抽象之后，实现也自然没有那么多if/else了。
输出过于复杂，为了事一个过程计算出了太多东西，又为了性能加了一堆flag控制是否计算之类。这种情况下需要果断将方法拆分成多个不同方法，每个方法只返回自己需要的内容。
如果不同计算之间有共用的内结果呢？如果这个内结果计算并不形成瓶颈，只要提取出内方法然后在不同过程中分别调用即可；如果希望避免重复计算，可以增加一个额外的cache对象作为参数，cache内容对用户不透明，用户只保证相同输入使用同一个cache对象即可，在计算中将中间结果保存到cache中，下次计算前先检查有没有已经得到的结果，就可以避免重复计算了。
内状态过于复杂。首先检查状态设置的是否合理，是不是有一些本来应该作为输入参数的东西被放到了内状态中（比如用来隐式地在两个不同方法调用之间传递参数）？其次，这些状态分别控制哪些方面，是否可以分组然后实现到不同的StateManager里面？第三，画出状态转移图，尝试将内状态分成单层分支，然后分别实现到on_xxx_state这样的方法里面，然后通过单层的switch或者查找表来调用。
其实通常需要优化的都是整体接口抽象，而不是单个接口的实现，单个接口实现不清晰通常是因为接口实现和需求不同构造成的。
hello，我是御风，很高兴在这里与你相遇。我是一名程序员，也是一名B站UP主。我乐于分享，勤于学。希望我们共同成长。永远相信梦想的力量
给个[在看]，是对御风最的支持
免责声明：文中图片均来源于网络，如有版权问题请联系我们进行删除！
