关于如何在大型组织中管理前端架构的相关文章不多，而且写得不好。本文所说的大型组织是指拥有15名以上前端工程师、多个前端项目的公司。我不想讨论管理问题或业务问题，这些问题在大公司很常见，我们只关注前端架构。

目前前端架构涉及的领域太多。建议分为几个部分：

前端架构解决方案

1. 可视化代码

从最简单的话题开始，我想，就是应用程序的可视化代码。 （译者注：前端是最接近用户的软件开发环节，通过创建网页或App应用向用户提供视觉信息，需要更加关注视觉效果和用户交互）

同一家公司开发了多个前端应用程序，并希望它们具有：

为了实现这一目标，需要一个由设计团队提供的设计系统，并且这些设计指南将在未来的所有产品设计中遵循。这项任务很复杂，需要设计团队、工程师和产品经理之间进行大量的讨论和协调。

从前端的角度来看，我们需要提供一个工具来实现这个设计系统，同时在工程师之间共享。一个好的解决方案是创建 npm 包，通过或类似工具可视化。我认为拥有专用的 Web 资源（带有 URL）和有关如何使用此 npm 包的文档非常重要。该网络资源将由前端工程师和设计师使用，并且可以成为他们之间的重要联系。

视觉代码

总结：至此，我们有了一个设计系统，表现为一个 npm 包和交互式文档，供所有前端应用程序共享和使用。

2. 代码结构

下面我们就来说说工程师的日常工作吧。我们必须实现新功能、修复错误，甚至重构代码。我们专注于使我们的代码美观且易于理解。但是，当公司里不是一个、不是两个、而是几十个大大小小的项目时，会发生什么呢？通常，开发人员按项目分组，并且只在相应的项目上工作。由于体力和时间有限，我们通常一次只能处理几个项目。自然地，我们开始受到这些群体的影响。

但是会有越来越多的情况，人们跨团队协作，需要检查彼此的代码和解决方案，甚至修复其他应用程序中的一些错误，或者在一些外部应用程序中添加他们需要的东西（影响是在他们的分组之外） 。坏消息是，这个过程发生在大公司中，而且几乎无法控制。好消息是，我们可以帮助改进它。

该怎么办？是的，公司的所有项目都提供相同的代码结构、编码和结构规范。

让我们深入了解一下代码结构的含义：

项目中的目录结构

当工程师第一次加入新项目时，它与现有项目具有相同的目录结构，他们知道所有相关的内容，这对链接和搜索有很大帮助。

配置或辅助文件

它们应该始终位于每个项目中的同一位置。如果有必要，也可以类比测试配置文件或CI文件（CI是持续集成，从代码提交到软件交付再到自动化过程）。常见的有：

文件类型同意的固定位置

如果相同文件类型的位置始终遵循相同的结构，也会非常方便。例如，组件目录始终有一个 .css 文件：

/Component --/Component.tsx --/style.css --/index.ts

复制代码

组件内部结构

文件内部的结构应该相同：导入和导出的顺序、公共函数的位置和类型等。在每种类型的文件中，您应该知道导出的内容。 （译者注：和是ES6的关键字，用于模块引用和对外暴露）

命名约定

包括目录、文件、变量、函数、类、类型等的名称。

编码约定

总的来说，我会说编码约定是一个非常广泛的部分，这里我只想谈谈一些我在接下来的几章中不会讨论的事情，比如是否以分号结尾（译者注，在前端js代码，末尾的分号大多数情况是可选的，但在团队工作时，最好达成一致（知乎上也有相关主题）等类似问题。

相同的代码结构和项目工具集在实践中紧密结合，互相帮助共存。我所说的工具集是指 CLI 工具（项目脚手架、语法和代码风格检查、测试等）、IDE 扩展等。我们将在下一节中讨论工具集。

代码结构

总结：掌握并使用本节内容后，我们应该让组织中的所有项目都使用相同的目录结构、命名准则、文件结构等。理想情况下，每个开发人员都可以轻松地转移到任何其他项目，而不会完全迷失方向那里。这个“彻底丧失”也与项目中使用的技术栈密切相关，我们来讨论一下。

3.技术栈

与上一节类似，我们希望在整个组织的项目之间拥有统一的技术堆栈。原因非常相似——我们希望我们的工程师能够适应公司的所有项目。

在前端项目中，技术栈的组件可以是：框架、基于项目的构建、主要编程语言、样式处理器、数据层（如）、状态管理、测试、构建系统等。

当然，所有规则都有例外。我还想说，有些技术非常适合某些项目，即使它们不属于公司范围的技术堆栈。不过，每当这个想法偏离公司的技术栈时，你就应该三思而后行，因为支持这些东西的成本非常高，所以带来的好处一定是巨大的。

我在这里要提一些通用的技术栈，它适用于当今的大多数项目（当然它只涵盖了真正的技术栈的一部分，但对于某些人来说是一个很好的起点）：

一旦我们定义并商定了公司的技术堆栈，还有两点非常重要。

我们需要在文档中写入技术信息。该文档应该易于在工程师之间共享，以便他们始终可以互相提供参考的链接。

我们应该再次编写和共享有关如何使用给定技术堆栈启动和引导新项目的文档。

技术栈

摘要：在我们实现并采用上述所有内容之后，您应该让组织中的所有项目共享相同的技术堆栈。理想情况下，所有物品之间不会有任何差异，即使有很小的差异也没关系。如果结合上一节来看，项目中的代码、目录、文件结构应该是差不多的。因此，任何项目中的链接都应该非常简单明了。

4.工具化

这个话题非常重要，我们现在到处都在使用辅助工具（开发新工具，也叫“造轮子”），比如应用构建、CI、组件生成器等。所以，为你的项目选择合适的工具至关重要，好的工具与坏的工具（或根本没有工具），就像自动化与手动测试一样。

在前面的章节中，我们只是讨论了技术栈和代码结构，并提到我们需要编写大量文档来让开发人员关注它们。但正确的工具集可以让您自动遵循公司的指导方针。

如果有指定的编码风格，你可以为人们提供工具，它会默认遵循这些规则。如果您已经定义了技术堆栈，那么一个好的 CLI 工具将为您提供一种从现有技术堆栈转移到具有这些特定技术的新项目的方法。

我们尝试讨论一下前端架构的哪些部分可以通过工具来覆盖：

代码风格和结构

我们之前讨论过，可以通过工具轻松实现自动化。

工程脚手架

您不再需要新的项目结构、手动安装所有依赖项等。

组件生成

大多数时候，应用程序中的某些组件甚至不只包含单个文件，因此创建、链接/导入文件可能需要一些时间，因此可以自动化。

启动并构建

当然，最明显的一个是自动化——应用程序的构建或启动方式。

测试

构建用于测试的应用程序并实际运行所有类型的测试（单元测试、集成测试等）的过程。

依赖管理

我们知道当今大约 80% 的代码都是依赖项。因此，我们需要不断更新，这在大公司里是不容易管理的。

跨项目依赖

我们的项目很可能不是孤立的，可能会依赖于其他项目，或者依赖于其他项目，所以我们可能需要一些工具来简化将它们关联起来的过程，在多个项目的组合中进行开发（例如Bit）等。

CI

CI是我们日常基础工具集的重要组成部分，它的自动化和统一性对团队非常有用。

如果您不想开发自己的工具集，我推荐 NX 工具集，它是最有趣的工具集之一。另外，作者也有类似的解决方案，让罗马知道一下。这些工具并不能涵盖所有内容，但它们代表了我们正在讨论的大部分内容，并且可以作为一个很好的起点。

简介：想象一下，当我们完成并采用所有章节后，我们的架构将变得多么强大。

每个项目都具有相同的结构，由统一的工具集维护和管理。每个项目都以相同的方式启动和构建。组件放置在相应的目录中并使用相同的命名准则。

但这是优点还是缺点呢？每个解决方案都有缺点。一是招聘新工程师需要时间。但是，如果一切都以非常常见的方式完成（人们已经习惯了其他现有工具）并记录下来，那么当您将其与开发生产力优势、工程师轻松使用任何代码库的机会等进行比较时。有时，这是小事。

5、生产环境

这部分前端架构通常是工程师最不关心的。可能大部分内容与编码本身无关，这可能不那么令人兴奋，但也很重要。

在生产中，我们通常需要注意以下几点：

分析

各种事件跟踪，如（网站流量、用户行为、页面链接分析平台等）、（收集、清洗和处理客户数据平台）、（行为分析和用户反馈服务，了解网站用户行为并利用热点图表、会议记录和调查等工具以获得反馈）等。

状态监控

诸如健康检查，甚至在生产环境上运行的测试，错误报告（例如：）等。

表现

这与上一项有些相似，但更注重性能。这包括响应时间估计、首屏渲染等等（相关工具：）

A/B 测试

各种A/B测试方案（A/B测试是一种产品优化方法，针对同一优化目标制定两种方案，让一部分用户使用A方案，其他用户使用B方案，并对两者的结果进行统计和比较不同方案的转化率、点击量、留存率等指标来判断不同方案的优劣并做出决策）或功能标志（标志控制在线功能的开启或关闭，通常以配置文件的形式出现）允许关闭未完成的功能，迭代开发是在主干上进行的，即使新功能没有完成，也不会影响发布，因为它对用户是关闭的，你也可以修改配置，使功能可见。功能开发完成后，可以修改配置使其功能发布可见）。

缓存

和其他工具。

所有这些都可以统一在公司的前端应用程序中，这将简化工程师的工作。例如，通过添加具有预定义初始配置的包并将这些包添加到新项目中。

发布制作的另一部分是代码预处理，例如：

这些都可以添加到前端应用程序的工具集中，这将在“工具化”部分中讨论。

生产环境

摘要： 理想情况下，所有这些都应该在初始化阶段自动添加到每个前端项目中。工程师只需在工具集中相应位置添加配置即可。

6. 开发环境CLI工具

当我们谈论前端CLI工具时，我们已经在工具部分讨论了开发经验。统一工具是工程师日常工作的很大一部分，但不是全部。

应用程序编程接口

我们要做的第二件有意义的事情是在本地使用方便的API，这可以提高开发者体验和开发速度。通常，在本地向前端工程师提供 API 并不简单：这可能包括安装他们不熟悉的工具或框架。即使安装程序已经使用容器化进行部署，这也会消耗开发人员机器上的大量计算资源（否则，请考虑制作安装程序）。这种情况下，有什么解决办法呢？ ——外部服务API。这可以是所有工程师使用的单个服务器，也可以是指向您自己的专用服务器进行呼叫的简单设置。

CI

CI是第三段。假设你的公司为前端选择了一些 CI 工具，并且仅使用这个工具（例如 CI、CI 或任何其他工具）。如果没有的话，你应该统一它。

在我看来，项目特定的 CI 配置应该是团队在进行项目时工作的一部分。这就需要每天都在使用的CI。有人对 CI 感兴趣，保持它稳定，并且有能力和技能来修复、配置和改进它。

然而，并非所有工作都应该由团队完成。对于前端应用程序，可能需要一组非常具体的工作。特别是，如果我们能够统一目录/代码结构、技术栈等，那么在你的公司工作一段时间后，你可能会在 CI 工具的各个阶段接触到这些模式，就像某种“构建块”来实现它，并为您的工程师提供从这些统一的“构建块”构建 CI 管道的可能性。

演示环境

最后，我们要验证开发的功能。工程师完成并实现所有内容后，他们几乎总是需要检查其外观和功能，并与其他工程师、设计师或其他利益相关者分享。对于此类需求，可以非常方便地为特定 PR（合并请求）提供应用程序的临时部署版本，并且还提供 URL。

应用程序临时部署

这个解决方案极大地加快了不同团队和人员之间的沟通，我认为这只是基本的必需品。但是，这个临时部署的版本应该尽可能接近生产环境，因为它还可以检查任何明显的错误或错误。

如果前端应用程序的构建和部署过程的管道是统一的，则可以轻松地将其添加到项目中并实现自动化。另外，像容器集群管理工具（ Tool，简称K8S）、Helm（K8S包管理器）这样的工具也会对自动化实施有很大的帮助。

开发环境

总结：舒适高效的开发流程，使用单一的 CI 工具和构建块，使用统一的 CLI 前端工具和演示环境创建各种 CI 管道。所有这些都应该使我们的开发过程尽可能顺利。将其乘以公司中工程师的数量，您就会明白这有多么有利。

7. 模块化

这个主题太大了，可能值得单独写一篇文章，但我将尝试简要介绍它。

在大型组织中，拥有庞大的代码库并不罕见，随之而来的是所有已知的问题，例如缓慢的 CI 管道、协作工作问题、缓慢的测试等。因此，前端架构的一个重要部分是决定我们希望看到独立的前端应用程序/模块的粒度。

我们现在主要有三种类型：

大型仓库只有一个项目包含所有代码，所有团队同时在这个仓库中工作。

有很多项目，但它仍然是一个大存储库（维基百科条目）。所有团队仍然在同一个存储库中工作，但使用不同的项目。通过采取仅针对特定项目、具有较小测试套件的项目等运行管道的方法，有机会解决其中一些问题。如果您选择这种方法，这样的工具可以让您更轻松。

每个项目一个仓库

每个项目都有自己的仓库和所有辅助文件，例如CI 、等。

在所有这些模型中，项目可能意味着独立的前端应用程序、页面、独立的前端模块等。这取决于您想要决定拆分前端应用程序的粒度。在大多数情况下，该部门应与所需的组织结构和人员管理保持同步。

当你决定拆分应用程序后，第二个大主题是如何将它们连接在一起。我们有以下方法：

正如我之前所说，在如此小的篇幅中很难涵盖这个主题，但我希望您有一些感兴趣的想法并探索这些主题。

模块化的

简介： 我们找到了一种方法，通过组织存储库、将项目分解为更小的部分（如果可能），使团队彼此更加独立，从而使团队成员保持快乐和高效。

8. 测试

有很多可用于前端应用程序测试的资源很容易找到，因此我将尽量不深入细节，而更多地关注大型组织的问题以及我们如何解决这些问题。

首先，每个工程师对测试技术、在哪种情况下应用哪种技术、如何编写“好的”测试等都有不同的理解。因此，准确记录公司测试层的所有细微差别和指南是非常有意义的用途以及每个测试层的指南。

从测试策略的角度来看，您希望进行哪些可能的测试类别：

第二步，我们需要在公司的不同前端应用程序中统一它们，以便人们在转移到不同项目时不会对如何测试以及测试什么内容产生疑问。

如果成功地统一了测试级别和方法，那么就可以自动帮助解决第二个问题——测试基础设施设置。每个项目本身都需要在本地和某些测试基础设施上进行设置和配置。例如，我们决定使用 ，它需要在容器中运行。这需要一些时间在本地和 CI 上进行设置。如果我们将其乘以我们拥有的项目数量，那就是一个巨大的时间。因此，相应的解决方案就是再次统一，为项目提供一些工具。听起来很简单，但实施起来需要很多时间。

非开发时间测试

我还想谈谈在实现和部署该功能后测试应用程序的另一种方法。监控当然是其中的一部分。

在前面的章节中，我们提到了前端应用程序的错误和性能监控、正常运行时间监控以及不同区域的响应。

在您的网站上运行测试也很好（可以包含在 CI 管道中）。更容易发现性能瓶颈、可用性问题，全面提高网页质量。

对最重要的业务流程进行最终生产测试。如果直接在生产环境中运行这些测试，它们很可能效果最佳，但是如果我们可以在非常接近生产环境甚至镜像生产环境的登台/测试环境中运行此类测试，会怎么样呢？

测试

摘要：我们有明确的测试规范，为每个前端应用程序定义了必要的测试级别。每个应用程序都有一个 CI 管道，以及一个可帮助您进行本地测试的 CLI 工具。

原文链接：