在这个场景中，业务的复杂性首先决定了代码的复杂性。首先，让我们看一个简单的示例，该示例可能出现在前端和节点：
我们有四个要求A，B，C和D的请求以获取数据（函数本身实现的函数），C依赖于B，D的结果依赖ABC的结果以及输出D的结果D。
尽管此代码是故意编写的，但确实已经看到了一些初学者。该代码仍然可以正确地给出结果，但是写作方法很丑陋，地狱被称为回头。，并且他们必须继续链接。绩效太差了，没有考虑A和B实际上是同时发生的。
在这里，我介绍了最原始的回调...在中间，您可以查看整个ES2015 +，回调（async.js） - > Promise--> Generator + Co-> async +等待的进化过程。简化和增强了我们从主要语法水平控制异步的能力。
在此阶段直接提供给当前阶段的最终解决方案：基于Promise +异步/等待
我们对上述问题进行思考，并清楚地了解逻辑顺序的依赖性，并使用最新的语法。
以组合的形式，考虑了并发和串行的写作，并且在示例的要求下达到最快的解决方案非常简单。解决了无限嵌套的问题。这是遵循语言演变本身的优化。
但这不仅是这样。我们将问题与依赖关系B和C的请求进行分类，并将单独的功能撤离。让它们处理逻辑。LET稍后提及这一点。
下面可能有一些问题
直接来代码示例。这是一种获得背景颜色的方法，但是随着业务的不断变化，背景颜色的来源越来越多。在某些业务人员的处理下，可能是这样：
我相信，当您阅读上面的代码时，您会非常痛苦。基本上不可能一目了然地知道您将进入哪个分支。因此，根据以下两个原则
重建基本版本：
您可以看到整个逻辑并重新分配。拆分分为三个函数，sub -method处理相应的逻辑级别，该逻辑级别负责通过主要方法调度。。
当然，在我们重建上述原则之后，此代码是否有任何问题？当然，您可以看到这三个函数取决于全局变量。功能本身不是纯正的。如果是全局问题，则不是易于调查。
我们可以将其修改为纯函数，以便易于理解和测试。
以函数修改为例：我们已将全局变量变成参数。您只需要在呼叫时传递全局变量，但是这样，我们获得了纯粹的功能。
您为什么在这里强调这一点？实际上，功能编程中最基本的问题之一是纯函数。只能在此输入和输出中观察到，输入肯定会具有输出。仅以这种方式，系统中的非pure函数才能降低更少的。使代码更易于测试。
当然，如果我们从重建的角度思考，我们仍然需要注意这一点：
这里的逻辑将将最后一个匹配的数据设置为BGColor。（我们都知道找到索引和其他基本上是从正面匹配的。）真的是业务需求吗？
可以看出，编写业务代码/重建的过程实际上是业务逻辑和业务理解的改进。无论是绘制一个函数还是优先的错误，这实际上是一个可以解决此类问题的问题：如果您可以在不阅读全球情况的情况下了解某个区域的详细逻辑，您可以使代码易于理解和修改。
...此处的代码有一个可以考虑进一步优化的空间，即使经过这样的重建，例如命名功能和参数，完整的测试用例等，这些案例受到文章的限制，并且不会暂时解释。
首先，您为什么要说需要优化代码？
然后将有以下要求：
最后，我编写的代码实际上应该是一个干净的代码，以便代码易于理解/修改/测试（实际上，大多数情况下，人员协作的条件是隐含的，因此编写代码而不是被封装的必要条件，以便团队中的其他成员无法理解（当然，如果某些人没有足够的经验，那么这就是这样，因此，这就是我的问题需要他加强自己。）
说到这一点，可能会有一种意外的感觉。在本文中，我们首先使用两个优化代码的具体示例作为引言，以便每个人都可以理解某些业务代码的优化想法。此后，其他一些可能的错误被列出，以及优化代码的意识形态准备和理论指导。
实际上，我希望每个人都能发现业务中的问题，然后考虑如何解决问题，因为如果您说太多，就无法编写代码。必须依靠自己。
资料来源：https：//zhuanlan.zhihu.com/p/99246269