几个业务场景中的重构示例
申请程序依赖
在这种场景中，首先还是业务的复杂度决定了代码的复杂度。首先咱们来看一个在前端和 node 都有可能呈现的一个简略的例子：
咱们有 A, B, C, D 四个申请获取数据的函数（函数本人实现），C 依赖 B 的后果，D 依赖 ABC 的后果，最终输入 D 的后果。
谬误示例
尽管这个代码是成心写成这样的，不过的确也有在一些初学者身上看到过。这份代码还是能正确给出后果的，然而写法俊俏，回调天堂。如果起初人不进行重构，还有申请依赖，得持续回调嵌套。性能太差，没有思考 A 和 B 实际上是能够并发的。
这里介绍了一下最原始的 callback … 两头大家能够去回顾一下 整个 ES2015+，callback (async.js) –> Promise –> generator + co –> async + await 的进化过程。其实是从原生的语法层面一直去简化和加强咱们对于异步的控制能力。
上面间接给目前阶段原生提供的终极计划：基于 Promise + async/await
正确示例
咱们从新思考了一下下面的问题，理分明了逻辑程序的依赖。并且用最新的语法。
应用 Promise.all 联合 async/await 的模式，思考了并发和串行，写法简洁，达到了在示例要求下的最快计划。解决了有限嵌套的问题。这是追随语言进化自身带给咱们能够进行的优化。
但又不仅仅如此。咱们将问题进行归类 将 B，C 有依赖程序的申请，抽离出独自的函数。让他们去解决本身的逻辑。这个点咱们稍后再提。
折磨人的 if else
可能存在上面一些问题
1、过多的嵌套
2、逻辑解决冗余
3、没有做好进攻编程（错误处理
间接来一个代码例子，这是一个获取背景色彩的办法，然而随着业务的一直变动，背景色彩的起源越来越多，在一些业务人员的解决下可能是这样的：
谬误示例
置信你在读下面的代码的时候是极为苦楚的，想要高深莫测的晓得最终会进入哪个分支，根本不可能。于是基于上面两个准则
- 正当的抽取成函数
- 谬误优先返回
有了一个根底版本的重构：
正确示例
能够看到整个逻辑，通过了从新梳理。拆分成了三个函数，子办法别离去解决对应层级的逻辑，由一个主办法负责调度。整体都变得高深莫测了。
当然，在咱们基于下面的准则进行重构之后，这个代码有没有问题呢？当然有。能够看到咱们这三个函数，都依赖了全局变量。函数自身就不纯了。如果是全局的问题，还是不易于排查。
咱们能够将其批改为纯函数，让这一份代码易于了解和测试。
以一个函数的批改为示例：咱们将 全局变量变成了参数，只须要在调用的时候，将全局变量传入即可，然而这样，咱们失去了一个纯函数。
为什么会在这里特别强调这个点呢，其实在函数式编程中的一个最根底的问题那就是纯函数。只有这样输入输出才是可被观测的，一个输出肯定会有一个输入。也只有通过这样的形式，能力让零碎中非纯的函数越来越少。让代码变得更易于测试。
当然作为咱们如果以重构的角度去思考的话，咱们还须要关注到这个点：
这里的逻辑会将会 最初一个被匹配到的数据，设置为 bgColor。（咱们都晓得 find indexOf 等根本都是从前匹配。）是否真的是业务的需要呢？
能够看到将业务代码写好 / 重构的过程中其实也是对业务逻辑和业务了解的再一次晋升。
不论是抽取成函数还是谬误优先返回的设计，这其实也都是能够解决这样一个问题：能在不去读懂全局的状况下，理解某一个区域的细节逻辑，也就做到了让代码易于了解和批改。
… 这里的代码即使是通过这样的重构后，仍然有能够思考进一步优化的空间，比方函数与参数的命名，残缺的测试用例等等，受限于文章篇幅，暂不开展阐明。
一些代码中可能存在的其余问题
- 逻辑耦合在视图层。
- a ===‘a’&& b =‘b’&& c=‘c’&& d ===‘d’?
…
:null
- 组件复用，函数复用，不封装，代码反复。
- 函数性能不繁多，一个函数解决太多职责。且这些职责没有任何关联，然而都耦合在同一个区块内。
- 参数列表凌乱，有做好进攻编程，不处理错误（接口谬误，超时，反复提交等等
- 魔法数字，魔法字符串，且没阐明。
- 蹩脚数据结构 / 蹩脚命名（其实下面的具体代码示例也存在）
对于优化代码的思维筹备
首先来说一下为什么会说须要优化代码？
- 技术谋求。
- 公司要求，线上有零碎在用。有用户在用，不写好出问题实际上苦的还是本人。
- 团队合作，我不好好写，团队成员其他人也不好好写，恶性循环苦的还是本人。
- 疾速迭代。零碎须要一直的减少新性能。必须要写好代码能力做到。
- 其他人的认识，怕他人感觉本人技术能力差… xxxx…
那么就会有上面这些要求：
- 易于了解零碎的架构
- 易于了解零碎的生命周期与执行流程
- 易于了解每一个函数的作用
- 易于了解函数之间是如何调用与传递的（输入输出）
- 易于了解变量的含意，表达式的含意。
- 易于扩大…
最终实际上又回到了写进去的代码应该是 整洁的代码，要使代码易于了解 / 批改 / 测试。（这里其实大部分时候，都隐含了一个人员合作的条件在外面，所以，既要写好代码，又不能适度封装，让团队其余成员看不懂（当然如果的确有些人教训不够，那么是他本身的问题，须要他本人去增强。））
一些倡议
- 更加清晰的去理解业务，去思考可能的变动。思考和设计分明再入手。
- 看一些开源我的项目与业界最佳实际，明确什么样的是好代码，什么样的是不好的代码。
- 建设明确代码尽管是给计算机运行的，但最终还是人看的。不仅仅是没有 bug 就行了，这样的心智模型。
- 建设业务与代码品质等同重要的思考模型。防止因为工夫导致的不得不这么写的代码。
- 明确 code review 自身可能能发现和指出来一些问题，但最终的落实还的靠本人，不能变成模式，而是须要交融成本身的思考。
- 应用谬误优先准则。尽可能的让出错的先返回，这样前面就会失去洁净的代码。（写代码的时候，不仅仅正向，反向的判断也须要思考）
- 正当的拆分成独立的函数。明确输入输出，错误处理等在函数外部的解决。（比方在一些场景中的确会存在大量逻辑判断，首先就要思考在判断外部的语句是否能被归类与拆分进来）
- 对于多种状态的判断与组合，能够应用 组合状态表（map 表）状态机等模式
- 学习设计模式与重构等相干常识。
- 重构！！只有你感觉这个中央有问题了，那就不要等到当前。当前往往就是再也不。
完结
说到这可能会有一种戛然而止的感觉。在这一篇文章外面，咱们首先以两个优化代码的具体实例为引子，让大家明确了一些业务代码的优化思路。在之后从列举了一些其余可能呈现的谬误，以及是优化代码的思维筹备和理论指导。其实都是心愿大家可能在业务中去发现问题，再去思考如何解决问题，因为说了那么多，到底能不把代码写好，还是得靠本人。
作者：三省吾身
欢送关注我的微信公众号「码农解围」，分享 Python、Java、大数据、机器学习、人工智能等技术，关注码农技术晋升•职场解围•思维跃迁，20 万 + 码农成长充电第一站，陪有幻想的你一起成长