祝大家有美好的一天。 今天，我想和您谈谈优化。 它是什么，为什么需要它，最重要的是，如何确保它随后不会痛苦地痛苦。
首先，我们将了解一般的优化以及JS中的优化。 因此，优化是根据某些定量特征的改进。 JS自身确定了四个定量特征：
代码量 -公认的是，编写的代码行越少，生产率越高，效果越好。 我的看法从根本上是不同的，因为通过编写一行代码，您可以创建这样的内存泄漏或永久循环，浏览器就会死掉。
速度（性能）是所谓的计算复杂性，即解析器执行指令所需执行的动作数。
建立速度 -毫无疑问，如果没有Webpack或Gulp之类的构建器，现在几乎所有项目都无法做到，因此此特性显示了项目构建器设置的正确性。 相信我，当服务器比咖啡研磨机更智能时，它变得非常重要。
代码可重用性 -此特性显示了可复用功能，组件，模块的体系结构的构建情况。
更详细地考虑每个类别，我们将分析其包括的特征以及所依赖的特征。
代码量：
- 配音 在不同的地方写了多少相同类型的代码；
- 留言 代码中的注释很好，但是我遇到的项目中注释多于代码。
- 缺乏统一性。 此类问题的一个很好的例子是类似的函数，这些函数根据某些属性而有细微差别。
- 无效代码的存在。 在项目中经常有调试功能或根本不使用的功能。
表现：
- 使用浏览器缓存机制；
- 根据将在其中执行代码的环境进行代码优化；
- 存在内存泄漏；
- 使用网络工作者；
- 使用对DOM树元素的引用；
- 使用全局变量；
- 递归调用的存在；
- 简化数学计算。
建立速度：
- 外部依赖项的数量；
- 代码转换。 这是指块的数量及其大小，css转换，文件粘合，图形优化等等。
代码重用：
如前几篇文章所述，要更改某些内容，您需要确定起点并弄清一切情况有多糟。 从哪里开始这样一个庞大的过程？ 从最简单的事情开始：加快组装速度并减少项目中多余的时间。 您问为什么值得从此开始？ 由于它们彼此依赖。 减少代码量将提高构建的构建速度，从而提高生产率。
优化构建时间不可避免地向我们介绍了“冷”构建的概念-这是一个项目从头开始到所有依赖项都受到影响并完全重新编译代码的过程。 不要与Rebild混淆-这是在不拉扯外部依赖关系和其他内容的情况下重建客户端代码。
提高构建速度将有助于：
- 使用现代的汇编程序。 技术并不会停滞不前，如果您拥有第一个Webpack，那么当您移至第四个Webpack时，您将会发现令人欣喜的增长已经无所作为。
- 摆脱所有死亡的成瘾。 开发人员时不时地试图在硫酸罐的底部找到真相，却忘了自己做实验后清理。我的同事曾经问过：“请使用package.json编写的依赖项，而不是在代码中任何地方导入的依赖项放入捆绑包中捆绑包？” 是的，它们将不会包含在程序集本身中，但包装将放气。 问题是，为什么？
- 根据您的需要将装配体分为几个轮廓。 至少两个：prod和dev。 例子：代码混淆。 在产品上，这是强制性的，因为重量更轻=加载速度更快，但是在开发中，混淆只会干扰并花费构建时间进行不必要的操作；
- 各个组装步骤的并行化；
- 使用可以缓存的npm客户端。
加快重建和“冷”构建速度将需要删去不必要的注释和无效的代码段。 但是，如果您有一个庞大的项目并且无法自己检查该怎么办？ 在这种情况下，代码分析器可以提供帮助。
我个人定期使用SonarQube ，不是最好的，但很灵活。 如果有的话，可以教授该项目的功能。 他不时地做着至少站立，至少跌倒的事情，但像任何乐器一样，他必须能够使用它，并且不要忘记对自己的言论持怀疑态度。 尽管存在所有缺点，但他还是努力应对死代码，注释，复制粘贴和小东西（例如缺乏严格的比较）的搜索。
SonarQube与ESlint / TSLint / Prettier和其他类似软件之间的根本区别在于，它可以检查代码的质量，隔离配音和计算的复杂性，并提供必要更改的建议。 类似物仅检查代码中的错误，语法和格式。
在实践中，我遇到了codacy ，这是一项具有免费和付费订阅的优质服务。 如果您需要在侧面检查某些东西，而不必在家中部署此“收割机”，这将很有用。 它具有直观的界面，详细的代码错误提示等等。
在本文中，我将不涉及设置构建，块和其余部分的主题，因为这完全取决于项目和已安装的构建器的需求。 也许我会在其他文章中对此进行讨论。
完成的操作有助于加快组装速度-利润，但是接下来呢？ 由于分析人员可以找到代码配音，因此将其放在单独的模块或组件中将很有用，从而增加了代码重用性。
我们只有一个部分没碰过-代码本身的速度。 所有讨厌的单词重构都要求这种提高生产力的机制。 让我们仔细看看重构时值得做什么和不值得做什么。
生活规则：如果可行，请不要触摸它，它不应在此过程中为您提供指导。 IT的第一个规则：做一个备份，然后您将对自己表示感谢。 在前端，进行任何更改之前，请进行测试，以免将来丢失功能。 然后问问自己-如何确定加载时间和内存泄漏？
这将对DevTool有所帮助。 它不仅会显示内存泄漏，告诉您页面加载时间，动画的缩编，而且如果您幸运的话，它还会为您进行审核，但这并不准确。 DevTools还具有不错的功能，例如限制下载速度，这将使您可以预测Internet不良时的页面加载速度。
我们能够找出问题所在，现在让我们解决它们！
首先，我们将使用浏览器缓存机制来减少加载时间。 浏览器可以缓存所有内容，随后向用户提供缓存中的数据。 没有人从您那里获得本地存储和会话存储。 它们使您可以存储一些数据，这些数据有助于在后续下载期间加快SPA的速度并减少不必要的服务器请求。
认为有必要根据将在其中执行代码的环境来优化代码，但是如实践所示，它会消耗大量的时间和精力，而不会带来明显的增长。 我建议仅将此作为建议。
明智的做法是消除所有内存泄漏。 我不会专注于此，我想每个人都知道如何消除它们，如果没有，那就谷歌搜索。
我们的另一个助手是网络工作者。 Web Worker是浏览器拥有的线程，可用于执行JS代码而不会阻塞事件循环。 Web worker可以执行繁重而冗长的计算任务，而不会阻塞用户界面流。 实际上，当使用它们时，计算是并行执行的。 摆在我们面前的是真正的多线程。 网络工作者有以下三种类型：
- 专用工作者-专用Web工作者的实例由主流程创建。 只有流程本身可以与它们交换数据。
- 共享工作程序（共享工作程序）-可以通过与该工作程序具有相同来源的任何进程（例如，不同的浏览器选项卡，iframe和其他共享工作程序）来访问共享工作程序。
- 服务工作者是使用源和路径注册的事件驱动的工作者。 他们可以通过拦截和修改导航命令和资源请求以及缓存可以非常精确地控制的数据来控制链接到的网页。 所有这些为我们提供了出色的工具，可以在特定情况下（例如，在网络不可用时）控制应用程序的行为。
如何与他们合作可以在Internet上轻松找到。
我们已经弄清楚了方法和第三方问题，现在我建议谈谈代码本身。
首先，尝试摆脱对DOM树的直接调用，因为这是一项耗时的操作。 假设您在代码中不断地操纵某种对象。 无需通过引用来使用此对象，而是不断拉出DOM树来搜索此元素并使用它，我们在代码中实现了缓存模式。
第二步是摆脱全局变量。 ES6给了我们人类一个很棒的发明，叫做块变量（简单来说，就是从var到let和const的变量声明）。
最后，最美味。 不幸的是，在这里并不是每个人都有足够的经验来理解细微差别。 我反对使用递归函数。 是的，它们减少了书面代码的数量，但是这并非一帆风顺：通常，此类递归函数没有退出条件，只是将它们遗忘了。 正如谚语中的“您可以用锤子砸手指，但这不是锤子的问题，而是手指的所有者”或关于猫的笑话：递归功能还不错，您需要能够烹饪它们。
尽管拥有现代前端应用程序的所有功能，但您也不应忘记基础知识。 浪费和不合理性的一个明显例子是在数组的开头添加了新元素。 谁知道，他知道，而谁不知道，现在我要说。 每个人都知道数组元素具有自己的索引，当我们要在其开头添加新的数组元素时，操作序列如下：
- 数组长度的定义
- 每个元素的编号。
- 每个数组元素的移位
- 将新项目插入数组
- 重新索引数组元素。
总结：
现在是时候四舍五入了，对于那些熟悉备忘录格式的人，请保留步骤列表，通过这些步骤，您可以了解现在处于优化的哪个阶段以及下一步要做什么：
- 我们确定多少东西是好/坏，删除指标。
- 我们删去了所有不必要的内容：未使用的依赖项，无效的代码，不必要的注释。
- 我们定制并加快装配时间，为轮廓配置不同的轮廓。
- 我们分析代码并确定我们将优化和重写的部分。
- 我们正在编写测试以防止功能丧失。
- 我们开始重构，摆脱全局变量，内存泄漏，配音代码和其他垃圾，不要忘记缓存。
- 我们简化了计算的复杂性，并将一切可能交给网络工作者。
一切都不像乍看起来那样复杂。 您的顺序可能与我的顺序有所不同，仅是因为您有自己的头在肩膀上。 您将添加新项目，或者减少新项目的数量，但是列表的基础将相似。 我特别描述了该划分，以便可以将该活动与主要工作并行进行。 通常，客户不准备为返工付款，同意吗？
最后。
我相信您，并且您会成功。 你认为我天真吗？ 我想您会感到惊讶，但是既然您找到了这篇文章，请仔细阅读它，这意味着（我对您有个好消息）您拥有大脑，并且您正在尝试开发它们。 祝您在优化战线这一艰巨的任务中取得成功！