浅谈大型组织中前端管理架构

前端，现代前端分工变得越来越细致，页面制作、JavaScript框架设计、组件插件、交互设计、工程化脚手架等，项目中前端的占比也越来越高，继而出现了BFF (Back-end for Front-end 服务于前端的后端)，这一切的助力离不开各大浏览器厂商的厮杀。

周末来跟大家分享大型组织中（前端工程师的人数开始超过15人）前端管理架构，主要涉及的是团队协作，如何让团队运作更加高效规范。本文不讨论大公司中常见的管理问题或业务领域问题，而只关注前端的协作架构。

如今，前端架构涉及的领域太多，一下是供参考的架构，后面将基于此架构进行展开介绍：

1、Visual Code

从最简单的主题开始，这是前端开发最常用的代码编辑器，当然不排斥使用其他的，但还是建议最好统一代码编辑器。

在同一家公司开发多个前端应用程序，个人觉得还应该具备一定的设计及品牌意识，希望团队成员开发出来的应用具备以下两点：

• 品牌认知度
• 相同的 UI/UX

为此，需要制定一个设计规范，这里的设计规范主要是从VI的角度出发。此规范由设计团队提出，并在所有将来的产品设计中遵循这些设计准则。即使这是一个非常复杂的任务，需要设计团队、研发团队和产品之间进行大量讨论和协调。

从前端的角度来看，可以将设计规范制作成脚手架，脚手架将设计规范的原则生成基础主题（样式、专用的Web资源、文档等），这样在项目实施过程中就可以共享此设计规范。

2、代码结构

接下来谈谈日常编码，确实实现了新功能、修复了bug，如果需要的话重构代码。需要关注代码库，试图让代码变得友好和容易理解。但是，当团队开始有不是1个、也不是2个，而是几十个大小项目时，会发生什么呢？

常见的方式是以项目分组，并开始只与这组项目一起工作。由于人的本性和有限的时间，通常不能在一段时间内兼顾多于2-5个项目。尽管如此，项目开始之后会遇到越来越多的情况，跨团队协作需要检查彼此的代码和实现方案，甚至在其他应用程序中也要修复一些错误，或者在某个外部应用程序中添加新的紧急需求）。这种情况的避免就需要项目编码规范，统一代码结构、编码规范等，这些规范最好的方式是变成工具脚手架。

• 项目中的文件夹结构

  开发人员第一次进入新项目时，与他开发过的项目中文件夹结构相同，对于理解代码、熟悉项目，快速进入研发进程有很大的帮助。

• 配置或依赖文件的

  文件，如 package.json、 .gitignore、 .editorconfig、 webpack.config等每一个项目应该总是在同一个地方。如果需要，将它们连接到测试配置文件或CI文件。

• 文件类型的固定位置

  如果相同文件类型的位置始终遵循相同的结构，则有助于理解。例如，如果组件文件夹中始终有一个 style.scss文件：

   /Component
--/Component.tsx
--/style.scss
--/index.ts
复制代码

• 组件内部结构：文件内部的结构应相同：导入、导出的顺序、公共功能的位置、类型等。在每种类型的文件中，都应该知道期望的内容。

• 命名规范：这包括文件夹、文件、变量、函数、类、类型等的名称

• 编码约定：总的来说，编码约定是一个非常宽泛的部分，最好团队成员能够达成一个一致的规范。

在实践中，相同的代码结构和项目工具集非常紧密地结合在一起，有利于开发效率。这里所说的工具集是指 CLI工具（项目启动、检测、测试等）、IDE扩展等等。

3、技术栈

与上一节类似，团队在组织的各个项目中拥有统一的技术栈，有助于开发效率及质量的提升。

在前端项目中，技术堆栈的组件可以是：构建该项目所基于的框架、主要语言、样式预处理器、数据层、状态管理、测试、代码整理、构建系统等。

当然，所有规则中都有例外。有时某些技术非常适合某些特定项目，即使这些技术不属于团队熟悉的技术栈。但是，每当有脱离现有团队技术栈的想法时，都应该三思而后行，因为更换技术栈的成本非常高，需要衡量成本及带来的价值。

这里提及一些通用技术堆栈，就目前可以适合大多数项目：

• Vue
• React
• Typescript
• Apollo
• Styled Components
• React Router
• Jest
• Cypress
• Create React App

在为公司定义技术栈并达成共识之后，还有其他非常重要的内容。

首先，需要写下来的技术栈的文档。这些文档应该在工程师之间方便且容易地共享，因此他们始终可以相互链接并维护。

其次，应该再次使用已定义的技术栈来写下并共享文档，以及如何启动和引导新项目的方式。

4、工具

现在，几乎在所有地方都使用了一些其他工具：规范、构建应用程序、CI、组件生成器等等。因此，这就是为什么能确定是否可以为项目选择正确的工具的原因至关重要。好的工具还是不好的工具（或者根本没有工具），就像自动化测试与手动测试之间的比较一样。

在前面谈到了技术栈和代码结构，并提到需要编写大量文档来使项目成员关注维护它们。但是正确的工具集可以有机会按照团队规范进行自动化。

例如，编码风格，则可以为项目提供 linting工具集，该工具集默认情况下遵循这些规则。如果具有定义的技术栈，那么良好的CLI工具将提供机会，使用技术栈中的特定技术来引导新项目。

来看看工具可以覆盖前端体系结构的哪些部分：

• 代码风格和结构：如之前所讨论的，可以通过工具轻松实现自动化

• 项目自举：无需提出新的项目结构，手动安装所有需要的软件包等。

• 组件生成：大多数情况下，应用程序中的某些组件甚至都不包含单个文件，因此文件创建、链接或者导入它们会花费一些时间，因此需要自动化。

• 启动和构建：当然，最显而易见的要自动化的事情是如何构建或启动应用程序。

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

• 依赖关系管理：现在大约80％的代码之间是有依赖关系。因此，需要让他们保持最新版本，并且要在大型公司中进行管理并非易事。

• 跨项目的依赖关系：很可能项目不是孤立地工作，可能依赖于其他项目，，因此可能需要一些工具来简化链接它们的过程，并结合多个项目（例如 Bit等）等等。

• CI：CI是日常工具集的重要组成部分，自动化和统一对团队协作是一项非常有益的工作。

如果不想开发自己的新工具集，可以尝试 NX工具集。同样，Babel也提供了类似的解决方案。借助工具提高效率，是一个很好的起点。

每个项目都是相同的，并由统一工具集维护和管理。每个项目都可以以相同的方式启动和构建。新的组件在相同的位置使用相同的命名准则生成。

5、生产部署

通常，在前端体系结构的这一部分中，前端小伙伴最不用担心。也许是因为它在大多数情况下与编码本身无关，可能并不那么令人兴奋，但同样重要。

在生产中，通常需要注意以下事项：

• Google Analytics（分析）：各种不同的跟踪事件，例如Google Analytics（分析），Segment，HotJar等。

• 状态监视：这包括诸如运行状况检查之类的内容，甚至可以在生产中运行测试，错误报告（例如 Sentry）等。

*** 性能**：这与上一项相似，项目需要注重性能。包括测量响应时间、加载时间等。（可以使用 Lighthouse）

• A/B测试：各种A/B测试解决方案或功能标记。

• 缓存：诸如 Varnish和 Cloudflare之类的工具。

所有这些都可以在公司的前端应用程序中统一，这将简化开发人员的工作。

6、开发迭代

CLI工具

当接触前端CLI工具时，已有部分内容在“工具”部分讨论了开发经验。统一工具是开发人员日常工作的重要组成部分。

API

好的API设计是改善开发人员体验和开发速度的第二件事，关于API设计可以参阅《 9个REST API设计的基本准则》。通常，为前端工程师在本地提供API并不是一件容易的事：这可能包括他们不熟悉的安装工具或框架。配置各种服务器环境等需要花费大量的时间。在这种情况下，Docker是个不错的选择，作为前端开发人员也有必要掌握简单的使用。有兴趣的话可以参阅《 面向WEB开发人员的Docker》

CI

CI是第三大部分。大部分公司已经有现成的一些CI工具作为前端工具 （例如Circle CI，Concourse CI或任何其他工具）。如果不是，则应统一。

特定项目的CI配置应该是该项目团队的一部分。这给CI带来了稳定的机会，因为有些人对CI感兴趣，每天都要使用它，并且具有修复，配置和改进它的能力和技能。

但是，并非所有工作都应由团队完成。对于前端应用程序，存在相当特定的一堆工作，如脚手架。

演示环境

最后是验证实现的功能。在开发人员完成所有工作并实施之后，几乎总是需要某种方式来检查其外观和功能，并将其与其他开发人员、设计师或测试人员共享演示环境。对于此类需求，它可以通过提供的URL在特定PR的应用程序的临时部署版本。

演示环境加快了不同团队与人员之间的沟通，这是必须具备的。但是，临时部署的版本应尽可能接近生产环境，因为它也是检查某些表面错误或BUG的好工具。

如果前端应用程序构建和部署流程是统一的，则可以轻松地将其添加到项目中并自动进行。同样，诸如 Kubernetes和 Helm之类的工具或类似工具也可以在开发中提供很大帮助。

7、模块化

这个话题非常大，可能需要一篇单独的文章来讨论，这里简单介绍一下。

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

现在有三种主要的模式:

• Monolith：一个大的存储库包含一个项目和所有的代码，所有的团队同时在这个存储库中工作。

• Monorepo：很多项目，但仍然有一个很大的存储库(在wiki中是monorepo)。所有的团队仍然使用相同的存储库，但是使用的是不同的项目。我们已经有机会修复一些问题了，我们采用的是单一的方法，只针对特定的项目运行管道，项目有更小的测试套件等等。如果你选择了这种方法，像Lerna这样的工具可以让你的生活更简单。

• Repo per project：每个项目都有自己的存储库和所有支持的东西，比如CI管道、部署等。

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

决定如何分割应用程序后的第二大主题是如何将这些部分连接在一起(如果你决定分割应用程序)。

这里我们有以下方法:

• Build-time composition：项目可以只是npm软件包，可以在构建期间安装和组成。
• Server-side composition：通常包括服务器端渲染和服务器上发生的合成。像Hypernova这样的工具可以帮助更好地组织它。
• Client-side composition：浏览器内部项目的组成。非常重要的是要提到 Module Federation，这是 Webpack 5中引入的一种新方法。
• Route composition：超级简单——每个项目都有自己的URL，在 Nginx层级上决定把用户重定向到哪里。

8、测试

关于前端应用程序的测试，有很多可用的资源，这里不深入细节，而是更多地关注大型组织的问题以及如何解决它们。

第一步——每个工程师对测试技术的理解是不同的，以及在什么情况下应用哪种技术，如何编写“好的”测试用例等等。所以非常有必要记录下公司所使用的测试标准的所有细微差别和指导方针，以及每个标准的指导方针。

测试方案中可能需要制定的测试级别:

• 单元测试
• 整体测试
• 端到端测试
• 其他的

此外，第二步，需要在公司的不同前端应用程序中统一它们，这样在参与其他项目时不会对如何以及如何进行测试有任何疑问。

如果设法统一了测试级别和方法，就可以自动帮助解决第二个问题——测试基础设施设置。每个项目都需要在本地和CI上设置和配置一些测试基础设施。例如，使用 Cypress，它需要在docker镜像中运行。这需要一些时间在本地和CI上进行设置。如果把这个数字乘以我们所拥有的项目数量，那将是非常巨大的时间。因此，解决方案——再次统一并为项目提供一些工具。听起来很简单，但却需要大量的时间去实现。

非开发时间测试

再谈一谈在已实施和部署的应用之后需要做的测试，这类测试是为了更好的改善应用。

在前面的部分中，已经提到了前端应用程序的错误和性能监视，正常运行时间监视以及来自不同位置的响应。

在网站上运行Lighthouse测试是个不错的方法（可以包含在CI管道中）。通常可以发现性能瓶颈、可访问性问题并提高性能。

最后，对最重要的业务流程进行生产测试，就需要模拟一个和生产环境接近的测试环境，这样有助于发现运行时的问题并快速进行改善。可以使用Docker，制作一个接近生产环境的镜像。

完