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

嗨！我想与您讨论如何在大型组织中管理前端架构。在我看来，关于该主题的文章不多，并且解释得不好。
在本文中，大型组织是指前端工程师的人数开始超过15人且该公司至少具有多个前端项目的公司。
我不想讨论在这样的大公司中常见的管理问题或业务领域问题，但让我们只关注Frontend体系结构。
如今，前端架构涉及的领域太多，因此，我建议将其分为以下几部分：
文章插图
> Frontend Architecture scheme
1.可视代码在我看来，让我们从最简单的主题开始，它是我们应用程序的可视代码。
最可能是因为我们希望在同一家公司开发多个前端应用程序，所以我们希望它们具有：
· 品牌认知度
· 相同的UI / UX
为此，我们需要一个设计系统。设计团队必须提出设计系统，并在以后的所有产品设计中遵循这些设计准则。即使这已经是一个非常复杂的任务，并且需要设计团队，工程师和产品之间进行大量讨论和协调。
从前端的角度来看，我们需要提供一种工具来在工程师之间实施和共享此设计系统。为此，一个好的解决方案是创建npm软件包，该软件包将由Storybook或其他类似工具直观地呈现。我认为，拥有专用的Web资源（带有URL）以及有关如何使用此软件包的文档非常重要。该Web资源将由前端工程师和设计师使用，并且可以作为他们之间对话的重要参考。
文章插图
> Visual Code
概要：
此时，我们在包装和交互式文档中提供了一个设计系统及其表示。我们确实在所有前端应用程序中共享并采用了此软件包。
2.代码结构让我们谈谈日常工程。我们确实实现了新功能，修复了错误，并在需要时重构了代码。我们确实关心我们的代码库，试图使其变得更好并易于理解。但是，当我们开始在公司中没有1个，不是2个，而是数十个大小项目时，会发生什么？通常，人们会围绕一些项目进行分组，并且仅开始与这组项目一起工作。由于我们的人性和有限的时间，通常，我们不能在一个时期内处理超过2–3–5个项目。因此，自然而然地，我们开始受到这些影响。顺便说一句，感谢美国宇航局提供的如此惊人的照片让我类比analog
文章插图
> Groups of influences
但是，我们开始有越来越多的案例，当人们进行跨团队协作时，需要检查彼此的代码和解决方案，甚至在其他应用程序中也要修复一些错误，或者在某个外部应用程序（对于他们的小组来说是外部的）中添加他们需要的东西。影响力）。坏消息是，这一过程正在几乎不受控制的大公司中发生。好消息-我们可以帮助改善它。
怎么样？正确。通过为公司中的所有项目提供相同的代码结构，编码和结构准则。
让我们更深入地了解代码结构的含义：
· 项目中的文件夹结构当工程师第一次进入新项目时-与项目中的文件夹结构相同，他们知道所有内容都对导航和搜索有很大帮助。
· 配置文件或支持文件，如package.json ， .gitignore ， .editorconfig ， webpack.config等文件。在每个项目中，它们应始终位于同一位置。如果需要，将它们连接到测试配置文件或CI文件。
· 文件类型的固定位置如果相同文件类型的位置始终遵循相同的结构，则效果也很好。例如，如果component文件夹始终有一个style.css文件：
/Component--/Component.tsx--/style.css--/index.ts
· 组件内部结构文件内部的结构应该相同：导入，导出的顺序，公共功能的位置，类型等。在每种类型的文件中，您都应该知道期望的内容。
· 编码约定通常，我会说编码约定是一个非常广泛的部分，但是在这里我只想包含一些不适合其余部分的内容，例如; 。或不 ; 和类似。
在实践中，相同的代码结构和项目工具集紧密结合在一起，相互帮助。通过工具集，我指的是CLI工具（项目自举，调试，测试等）， IDE扩展等。我们将在下一节中讨论工具集主题。
文章插图
> Code structure
概要：
在应用了本节并采用它之后，我们应该使组织中的所有项目都具有相同的文件夹结构，命名准则，文件结构等。理想情况下，每个开发人员都可以跳入任何其他项目，而不会在这里完全迷失方向。这种"完全丢失"也与项目内部使用的技术堆栈紧密相关，因此让我们来谈谈它。