跳到主要内容

设计非常大的(JavaScript)应用程序

非常大的 JS 应用 = 很多开发者 + 大型代码库

如何处理很多开发者?

同理心

什么是 ==高级工程师==?没有初级工程师的高级工程师团队就是工程师团队

  1. 成为高级工程师意味着我能够解决几乎所有别人可能抛给我的问题。
  2. 让初级工程师最终成为高级工程师。

高级工程师的下一步是什么?

  1. 高级: “我知道我会如何解决这个问题”,因为我知道我会如何解决它,我也可以教别人怎么做。
  2. 下一个层次: “我知道别人会如何解决这个问题”

良好的编程模型

人们如何编写软件,例如 react/redux, npm。这里有一个影响所有大型 JS 应用的模型 - 代码分割。

  1. 人们必须考虑打包什么以及何时加载
  2. ==基于路由的代码分割==
  3. 但是,如果这还不够呢?
    1. 懒加载我们网站的每一个组件
    2. Google 是怎么做的?通过渲染逻辑和应用逻辑进行分割。==简单地在服务器端渲染一个页面,然后实际渲染的内容触发下载相关的应用程序包。== Google 不做同构渲染 - 没有双重渲染

如何处理大型代码库?

==代码可移除性/可删除性==

例如,CSS 在代码可移除性方面表现不佳

  1. 一个大的 CSS 文件。里面有这个选择器。谁真的知道它是否仍然与您的应用程序中的任何内容匹配?所以,您最终只是把它留在那里。
  2. 因此,人们创建了 CSS-in-JS

==不惜一切代价避免应用程序的中央配置==

  1. 坏例子
    1. 中央路由配置
    2. 中央 webpack.config.js
  2. 好例子
    1. 去中心化的 package.json

避免中央导入问题:路由器导入组件 A、B 和 C

  1. 为了解决这个问题,做 ==“增强”而不是“导入”==
  2. 然而,开发者仍然必须决定何时增强,何时导入。由于这可能导致非常糟糕的情况,我们使“增强”成为非法,没人可以使用它——只有一个例外:生成的代码。

避免基础包的垃圾堆

  1. 例如,基础包绝不应包含 UI 代码
  2. 通过禁止依赖测试解决此问题
  3. ==最直接的方法必须是正确的方法;否则添加一个测试以确保正确的方法。==

小心抽象

我们必须变得善于找到正确的抽象:同理心和经验 -> 正确的抽象

References: