大型组织的大规模前端架构( 四 ) 嗨！我想与您讨论如何在大型

7.模块化这个主题很大，可能需要另外一篇文章来讨论，但是我会尝试简短地进行探讨。
在大型组织中，巨大的代码库并非罕见。伴随着所有已知的问题，例如缓慢的CI管道，协作工作的问题，缓慢的测试等。因此，前端体系结构的大部分是决定我们希望看到独立的前端应用程序/模块的粒度。
我们现在有3种主要模型：
· Monolith一个具有单个项目和所有代码的大型存储库，所有团队都在同一时间在该存储库中一起工作。
· Monorepo许多项目，但仍然是一个大型存储库（Wiki中的monorepo）。所有团队仍在同一个存储库中工作，但项目不同。已经有机会通过仅针对特定项目运行管道，项目具有较小的测试套件等来解决一些整体方法所具有的问题。如果您选择此方法， Lerna等工具可以使您的生活变得更加轻松。
· 每个项目的回购每个项目都有自己的存储库和所有支持的内容，例如CI管道，部署等。
在所有这些模型中，项目都可以表示一个独立的前端应用程序，页面，独立的前端模块等。这取决于您决定拆分前端应用程序的粒度。在大多数情况下，此拆分应与所需的组织结构和人员管理保持同步。
在决定如何拆分应用程序之后，第二个大话题是如何将这些部分连接在一起（如果您决定拆分应用程序）。
在这里，我们有以下方法：
· 构建时组成您的项目可以只是npm软件包，可以在构建时进行安装和组成。
· 服务器端合成这种方法通常包括服务器端渲染和服务器上发生的合成。像Hypernova这样的工具可以帮助更好地组织它。
· 客户端组成浏览器内项目的组成。在马丁·福勒（Martin Fowler）的博客中，这里有一些很好的解释方法。另外，非常重要的是要提到Module Federation ，这是Webpack 5中引入的一种新方法。
· 路由组成非常简单-只是每个项目都有自己的URL ，在" Nginx级别"上，我们决定将用户重定向到何处。（对不起，这样的解释，但我认为这将是最容易理解的）
正如我之前说过的，要以这么小的格式涵盖这个主题非常困难，但是我希望您至少能找到一些有趣的想法，并自己深入研究这些主题。
文章插图
> Modularity
概要：
我们找到了一种方法，可以通过组织存储库，将我们的项目分成更小部分（最有可能），使团队之间更加独立来使团队快乐和高效。
文章插图
> Welcome to paradise
8.测试关于前端应用程序测试的可用资源太多，因此，我将尽量不进行详细介绍（您可以轻松找到），而将重点更多地放在大型组织的问题以及我们如何解决这些问题上。
首先-每个工程师对测试技术的理解不同，还了解在哪种情况下应采用哪种技术，如何编写"好的"测试等。因此，非常准确地记录测试的所有细微差别和准则非常有意义。公司使用的级别以及每个级别的准则。
【大型组织的大规模前端架构】您想要在测试策略中拥有的可能的测试级别：
· 单元测试
· 整合测试
· 端到端测试
· … 和别的
此外，作为第二步，我们需要在公司的不同前端应用程序中统一它们，因此人们在迁移到另一个项目时将不会对如何以及如何进行测试有任何疑问。
如果您设法统一测试级别和方法，则可以自动帮助解决第二个问题-测试基础架构设置。每个项目都需要自己在本地和CI的一些测试基础架构上进行设置和配置。例如，我们决定使用Cypress ，它需要在docker映像中运行。这需要一些时间才能在本地和CI上进行设置。如果将其乘以我们拥有的项目数量，那将是一个巨大的时间。因此，解决方案-再次统一起来并为项目提供一些工具。听起来很容易，但是要花费大量的时间才能实现。
非开发时间测试在功能已经实现和部署之后，我还想尝试另一种测试应用程序的方法。是的，当然，它也是其中一部分。
在前面的部分中，我们已经提到了前端应用程序的错误和性能监视，正常运行时间监视以及来自不同位置的响应。
在网站上运行Lighthouse测试也很棒（可以包含在CI管道中）。通常可以发现性能瓶颈，可访问性问题并提高网页质量。
最后-对最重要的业务流程进行生产测试。如果直接在生产环境中运行它们，则它们最有可能会发挥最佳性能，但是当我们可以在与生产环境非常接近甚至镜像生产环境的登台/测试环境中运行此类测试时，也可以进行修改。关于此主题的文章非常好-在这里。