重构几个业务场景的例子请求的顺序取决于在这个场景中，首先，业务的复杂度决定了代码的复杂度。首先我们看一个简单的例子，在前端和node中都有可能出现：我们有四个请求数据的函数A、B、C、D（由函数本身实现），C依赖于B的结果，而D依赖于ABC最终输出D的结果。错误示例虽然这段代码是故意写成这样的，但确实有一些初学者看到过。这段代码还是可以给出正确的结果，但是写法丑陋，回调地狱。如果后面人家不重构，还有request依赖，就得继续嵌套回调。性能太差以至于没有考虑到A和B其实是可以并发的。这里简单介绍一下最原始的callback...中间可以回顾整个ES2015+，callback(async.js)-->Promise-->generator+co-->async+await的演变过程.其实就是不断简化和增强我们从原生语法层面控制异步的能力。下面是直接为当前阶段提供的最终解决方案：基于Promise+async/await的正确例子，我们重新思考了上面的问题，理清了逻辑顺序的依赖。并使用最新的语法。使用Promise.all结合async/await的形式，兼顾了并发和序列化，写法简洁，实现了例子要求下最快的解决方案。解决了无限嵌套的问题。这是语言进化本身带给我们的一种优化。但不仅如此。我们对问题进行分类，将具有依赖顺序的B和C的请求分离到单独的函数中。让他们处理自己的逻辑。我们稍后会回到这一点。折磨人的ifelse可能会出现以下一些问题。过多的嵌套逻辑处理冗余。无防御性编程（错误处理直接自带代码示例，这是获取背景色的方法，但是随着业务的不断变化，背景色的来源越来越多，处理下可能是这样的部分业务人员：错误示例认为，上面的代码让你阅读起来极其痛苦，基本不可能一眼就知道你最终会进入哪个分支，因此，基于以下两个原则，进行合理的抽取intoafunctionerrorpriorityreturn有重构的基本版本：正确的例子可以看到整个逻辑，已经重构。拆分成三个函数，子方法分别处理对应层级的逻辑，一个主方法负责调度。整个事情一目了然。当然，我们按照上面的原则重构之后，这段代码有没有问题呢？当然有。可以看到我们三个函数都依赖全局变量。函数本身是不纯的。如果是全局问题，还是不好排查。我们可以把它修改成一个纯函数，让这段代码更容易理解和测试。以修改一个函数为例：我们把全局变量变成了一个参数，调用的时候只需要传入全局变量，但是这样，我们得到的是一个纯函数。为什么要在这里强调这一点呢？事实上，函数式编程中最基本的问题之一就是纯函数。只有这样才能观察到输入和输出，有输入必有输出。只有这样，系统中的不纯函数才能越来越少。使代码更易于测试。当然，如果我们从重构的角度去思考，还需要注意这一点：这里的逻辑会将最后匹配到的数据设置为bgColor。（我们都知道findindexOf之类的过去基本匹配）真的是业务需求吗？可以看出，编写/重构业务代码的过程其实是对业务逻辑和业务理解的又一次提升。无论是抽离成一个函数，还是错误优先返回的设计，这其实都可以解决这样一个问题：在不了解全局的情况下，了解某个区域的详细逻辑，让代码易于理解和修改。...这里的代码即使经过这样的重构，仍然还有进一步优化的空间，比如函数和参数的命名，完整的测试用例等，受限于文章篇幅，不再赘述暂时。部分代码可能存在的其他问题1、逻辑耦合在视图层。a==='a'&&b==='b'&&c==='c'&&d==='d'?
