设计非常大的(JavaScript)应用程序
非常大的 JS 应用 = 很多开发者 + 大型代码库
如何处理很多开发者?
同理心
什么是 ==高级工程师==?没有初级工程师的高级工程师团队就是工程师团队
- 成为高级工程师意味着我能够解决几乎所有别人可能抛给我的问题。
- 让初级工程师最终成为高级工程师。
高级工程师的下一步是什么?
- 高级: “我知道我会如何解决这个问题”,因为我知道我会如何解决它,我也可以教别人怎么做。
- 下一个层次: “我知道别人会如何解决这个问题”
良好的编程模型
人们如何编写软件,例如 react/redux, npm。这里有一个影响所有大型 JS 应用的模型 - 代码分割。
- 人们必须考虑打包什么以及何时加载
- ==基于路由的代码分割==
- 但是,如果这还不够呢?
- 懒加载我们网站的每一个组件
- Google 是怎么做的?通过渲染逻辑和应用逻辑进行分割。==简单地在服务器端渲染一个页面,然后实际渲染的内容触发下载相关的应用程序包。== Google 不做同构渲染 - 没有双重渲染
如何处理大型代码库?
==代码可移除性/可删除性==
例如,CSS 在代码可移除性方面表现不佳
- 一个大的 CSS 文件。里面有这个选择器。谁真的知道它是否仍然 与您的应用程序中的任何内容匹配?所以,您最终只是把它留在那里。
- 因此,人们创建了 CSS-in-JS
==不惜一切代价避免应用程序的中央配置==
- 坏例子
- 中央路由配置
- 中央 webpack.config.js
- 好例子
- 去中心化的 package.json
避免中央导入问题:路由器导入组件 A、B 和 C
- 为了解决这个问题,做 ==“增强”而不是“导入”==
- 然而,开发者仍然必须决定何时增强,何时导入。由于这可能导致非常糟糕的情况,我们使“增强”成为非法,没人可以使用它——只有一个例外:生成的代码。
避免基础包的垃圾堆
- 例如,基础包绝不应包含 UI 代码
- 通过禁止依赖测试解决此问题
- ==最直接的方法必须是正确的方法;否则添加一个测试以确保正确的方法。==
小心抽象
我们必须变得善于找到正确的抽象:同理心和经验 -> 正确的抽象