设计大型（JavaScript）应用程序

摘要：摘要

关键词：JavaScript应用程序； API； 放大；正则算法

您好，我曾经构建过非常大的JavaScript应用程序。我真的不再这样做了，所以我认为是时候回顾一下并分享我所学的知识了。昨天我在会议上喝啤酒，有人问我：“嘿，马尔特，你有什么权利，有权谈论这个话题？” 我想回答这个问题实际上是为了这次演讲的主题，尽管我通常觉得谈论自己有点奇怪。所以，我在Google构建了这个JavaScript框架。它是由照片，网站，加上，驱动器，播放，搜索引擎，所有这些网站使用。有些相当大，你可能用过一些。

幻灯片文字：我以为React很不错

此Javascript框架不是开源的。它不是开源的原因是它与React同时出现，我就像“世界真的需要另一个JS框架来选择吗？”。Google已经有了一些这样的产品——Angular和Polymer——而且感觉另一个会让人迷惑，所以我想我们还是自己留着吧。但是，除了不是开源的之外，我认为还有很多东西可以学习，值得分享我们在此过程中学到的东西。

很多人的照片

因此，让我们谈谈大型应用程序及其共同之处。当然，可能会有很多开发人员。可能有几十个甚至更多个，而这些人是有感情和人际关系问题的人，您可能必须考虑到这一点。

非常古老的建筑物的照片

即使您的团队规模不大，也许您已经从事了一段时间的工作，也许您甚至不是第一个维护它的人，但您可能并没有所有的背景信息，可能还有一些东西不太了解，您的团队中可能有些人不了解有关该应用程序的所有信息。这些是我们构建大型应用程序时必须考虑的事情。

推特上写道:一个没有初级工程师的高级工程师团队就是一个工程师团队

我想在这里做的另一件事是给大家介绍一下我们职业生涯的背景。我想我们很多人会认为自己是高级工程师。或者我们还没到那一步，但我们想成为一个。在我看来，担任高管意味着我能够解决几乎所有别人抛给我的问题。我知道我的工具，我知道我的领域。这份工作的另一个重要部分是我让初级工程师最终成为高级工程师。

幻灯片文字：初级-gt;高级-gt;？

但是发生的事情是，在某个时候，我们可能会想“下一步可能是什么？”。当我们达到该资历阶段时，下一步要做的是什么？对于我们中的某些人来说，答案可能是管理，但我认为那不是答案

对于每个人，因为不是每个人都应该成为经理，对吗？我们中的一些人真的是伟大的工程师，为什么我们一辈子都不应该这么做呢？

幻灯片文字：“我知道我将如何解决问题”

我想提出一种升级到高级水平以上的方法。我作为高级工程师谈论自己的方式是说“我知道我将如何解决问题”，并且因为我知道我将如何解决问题，所以我也可以教别人去做。

幻灯片文字：“我知道别人会如何解决这个问题”

我的理论是，下一个层次是我可以对自己说：“我知道别人会如何解决问题”。

幻灯片文字：“我可以预期API的选择和抽象如何影响其他人解决问题的方式。”

让我们更具体一点。您可以这样说：“我可以预测我正在做出的API选择或我正在引入到项目中的抽象的选择，它们如何影响其他人如何解决问题。”我认为这是一个强大的概念，可让我思考自己所做的选择如何影响应用程序。

幻灯片文字：移情的应用。

我将其称为移情应用。您正在与其他软件工程师一起思考，并且正在考虑您的工作方式以及为他们提供的API，它们如何影响他们编写软件的方式。

幻灯片文本：轻松模式下的同理心。

幸运的是，这是简单模式下的同理心。移情通常很难，但这仍然很难。但至少那些你有同情心的人，他们也是其他软件工程师。因此，虽然他们可能与你有很大的不同，但他们至少有一个共同点，那就是他们正在构建软件。当你获得更多的经验时，这种同理心确实是你可以非常擅长的。

幻灯片文字：编程模型

考虑这些主题时，我想谈一个非常重要的术语，那就是编程模型，这是我将经常使用的一个词。它代表“给定的一组API或库，框架或工具-人们在这种情况下如何编写软件”。我的演讲实际上是关于API的细微变化等，以及它们如何影响编程模型。

编程模型影响的例子:React, Preact, Redux, Date picker from npm, npm

我想举一些影响编程模型的例子：假设您有一个Angular项目，并且说“我将把它移植到React”，这显然将改变人们编写软件的方式，对吗？但是，然后您就像“啊，60KB的虚拟DOM内容，让我们切换到Preact” –这是一个与API兼容的库，它不会改变人们编写软件的方式，只是因为您做出了这种选择。然后，您可能会觉得“这真的很复杂，我应该对应用程序的工作进行协调，我将介绍Redux。” –这将改变人们编写软件的方式。然后，您得到此要求“我们需要一个日期选择器”，然后转到npm，有500个结果，您选择了一个。选择哪一个真的很重要吗？绝对不会改变您编写软件的方式。但是，触手可及的npm就是这些庞大的模块集合，它们的周围绝对改变了您编写软件的方式。当然，这些只是可能影响人们编写软件方式的一些示例。

幻灯片文字：代码拆分

现在，我想谈一谈所有大型JavaScript应用程序在将它们交付给用户时的共同点：这就是说，它们最终会变得很大，以至于您不想一次全部交付它们。为此，我们都引入了一种称为代码拆分的技术。代码拆分的意思是您为应用程序定义了一组捆绑软件。因此，您说的是“某些用户仅使用我应用程序的这一部分，某些用户使用另一部分”，因此您将捆绑在一起的捆绑在一起，只有当用户实际处理的应用程序部分被执行时，捆绑包才会下载。这是我们所有人都能做的。与许多事物一样，它是闭包编译器发明的-至少在JavaScript世界中如此。但是我认为最流行的代码拆分方法是使用webpack。而且，如果您使用的是超级棒的RollupJS，那么他们最近也添加了对此的支持。绝对是您应该做的事情，但是当您将其引入应用程序时，需要考虑一些事情，因为它确实会对编程模型产生影响。

幻灯片文字：同步-gt;异步

您曾经曾经同步过的东西现在变成了异步的。无需拆分代码，您的应用程序将变得非常简单。有一件大事。它启动后就稳定了，您可以对此进行推理，而不必等待其他事情。通过代码拆分，您有时可能会说“哦，我需要那个捆绑包”，因此您现在需要进入网络，并且必须考虑到这种情况可能发生，因此应用程序变得更加复杂。

幻灯片文字：人类

此外，我们需要人工来完成此工作，因为代码拆分需要您定义捆绑软件，并且需要您考虑何时加载捆绑软件，因此，这些人工人员，团队中的工程师现在必须做出决定。捆绑软件以及何时加载该捆绑软件。每次涉及到人员时，这显然会影响编程模型，因为他们必须考虑这些事情。

幻灯片文字：基于路由的代码拆分

有一种非常成熟的方法可以解决此问题，即在进行代码拆分时使人员摆脱混乱，这称为基于路由的代码拆分。如果您还没有使用代码拆分，那可能就是您应该首先进行的方式。路由是应用程序的基准URL结构。例如，您可能将产品页面放在`/ product /`上，而类别页面可能放在其他位置。您只需使每个路由成束，然后您的应用程序中的路由器即可了解代码拆分的情况。而且，每当用户转到一条路由时，路由器就会加载关联的捆绑软件，然后在该路由中，您会忘记现有的代码拆分。现在，您将回到编程模型，该模型几乎与为所有事物提供大量捆绑包相同。这是一种非常好的方法，而且绝对是第一步。

但是，本演讲的主题是设计非常大型的JavaScript应用程序，并且它们很快变得如此之大，以至于每个路由都无法捆绑，因为路由本身变得非常大。对于一个足够大的应用程序，我实际上有一个很好的例子。

Google搜索查询“截图101”的屏幕截图

我一直在想如何成为演讲者，然后我得到了很多不错的蓝色链接。您可以完全设想此页面非常适合单个路由束。

Google搜索查询“ weath”的屏幕截图

但是后来我想知道天气是因为加利福尼亚州的冬季寒冷，突然之间有了完全不同的模块。因此，这种看似简单的路线比我们想象的要复杂。

Google搜索查询屏幕截图“ 20 USD转换为AUD”

然后我应邀参加了这次会议，并检查了澳元兑换1美元的汇率，并且有一个复杂的货币换算器。显然，这些专用模块的数量大约增加了数千个，将它们全部捆绑在一起是不可行的，因为该捆绑包的大小只有几兆字节，用户会感到非常不满意。

幻灯片文字：组件级别的延迟加载？

因此，我们不仅可以使用基于路由的代码拆分，还必须想出一种不同的方法。基于路由的代码拆分非常好，因为您在最粗略的级别拆分了应用程序，所有后续操作都可以忽略它。由于我喜欢简单的事物，因此如何进行超细粒度而不是超粗粒度拆分。让我们考虑一下，如果我们延迟加载网站的每个组件，将会发生什么情况。从效率的角度来看，当您只考虑带宽时，这看起来确实不错。从诸如延迟的其他观点来看，这可能是非常糟糕的做法，但是当然值得考虑。

幻灯片文字：React组件静态依赖于其子组件。

但是，例如，假设您的应用程序使用React。在React组件中，静态依赖于其子组件。这意味着，如果您由于懒惰地加载孩子而停止这样做，那么它将更改您的编程模型，并且事情不会再变得如此美好。

ES6导入示例。

假设您有一个要放入搜索页面的货币转换器组件，然后导入，对不对？这是在ES6模块中执行此操作的正常方法。

可加载组件示例。

但是，如果要延迟加载，则会在使用动态导入的地方获得如下代码，这对于延迟加载ES6模块并将其包装在可加载组件中是一件很新的事情。当然有5亿种方法可以做到这一点，我不是React专家，但是所有这些都会改变您编写应用程序的方式。

幻灯片文字：静态-gt;动态

事情变得不那么好了-静态的东西现在变成了动态的，这是编程模型改变的另一个危险信号。

幻灯片文字：谁决定什么时候延迟加载？

您必须突然想知道：“谁决定什么时候延迟加载”，因为这将影响应用程序的延迟。

幻灯片文字：静态还是动态？

人类又在那儿，他们必须考虑“有静态导入，有动态导入，我什么时候使用它？”。弄错这一点真的很不好，因为一个静态导入本来应该是动态的，但突然间可能会将东西放进不应该的同一个包中。如果您有很多工程师，而且很长一段时间，这些都会出错。

幻灯片文字：分割逻辑和渲染

现在，我将讨论Google实际如何做到这一点，以及获得良好编程模型并获得良好性能的一种方法。我们要做的是获取我们的组件，然后按呈现逻辑和应用程序逻辑对它们进行拆分，就像您按该货币转换器上的按钮时所发生的那样。

幻灯片文字：仅加载逻辑（如果已渲染）

因此，现在我们有两件分开的事情，并且我们只在先前渲染组件时才为其加载应用程序逻辑。事实证明这是一个非常简单的模型，因为您可以简单地在服务器端呈现页面，然后实际呈现的内容都触发下载关联的应用程序捆绑包。由于加载是通过渲染自动触发的，因此这使人脱离了系统。

幻灯片文字：搜索结果页面上的货币转换器

这个模型看起来不错，但是确实有一些折衷。如果您知道服务器端渲染通常在React或Vue.js等框架中的工作方式，那么它们的工作就是一个称为水合的过程。水化的工作方式是，您在服务器端渲染某些东西，然后在客户端上再次渲染它，这意味着您必须加载代码以渲染页面上已经存在的东西，这在加载页面时非常浪费。代码以及执行方面。这是一堆浪费的带宽，这是一堆浪费的CPU，但这确实很棒，因为您会在客户端忽略服务器端渲染了一些东西。我们在Google使用的方法并非如此。因此，如果您设计了一个非常大的应用程序，您会考虑：是采用更复杂的超快速方法，还是采用效率较低，但如此好的编程模型的水合作用？您将必须做出此决定。

幻灯片文字：2017新年快乐

我的下一个主题是计算机科学中我最喜欢的问题-尽管我可能给它起了一个坏名字，但它并不是命名事物。这是“ 2017年假期特别问题”。谁在这里写过一些代码，现在不再需要它了，但仍在您的代码库中？ hellip;发生这种情况，我认为CSS尤为著名。您有一个很大的CSS文件。那里有这个选择器。谁真的知道那是否仍然与您的应用程序中的任何内容匹配？因此，您最终只能将其保留在那里。我认为CSS社区处于革命的最前沿，因为他们意识到这是一个问题，并创建了CSS-in-JS之类的解决方案。这样，您只有一个文件组件2017HolidaySpecialComponent，可以说“不再是2017”了，可以删除整个组件，一切一sw而就。这使得删除代码非常容易。我认为这是一个很大的主意，它不仅仅应该应用于CSS。

幻灯片文字：不惜一切代价避免中央配置

我想给出一些有关这种总体思路的示例，您希望不惜一切代价避免对应用程序进行集中配置，因为集中

剩余内容已隐藏，支付完成后下载完整资料

---

英语原文共 35 页，剩余内容已隐藏，支付完成后下载完整资料

---

资料编号：[269647]，资料为PDF文档或Word文档，PDF文档可免费转换为Word