设计非常大的（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. ==最直接的方法必须是正确的方法；否则添加一个测试以确保正确的方法。==

小心抽象​

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