原文：blog.bitsrc.io/micro-front…
引言：通过规避这些错误，能够让我们最大化的获得微前端的好处。
微前端可以使您的应用程序变得灵活和健壮，但也能变成一种开销，阻碍项目的发展。并且，有许多实践可能会误导刚刚进入微前端的读者。
在这篇文章中，我将介绍其中一些常见错误，以便你能够避免他们。
-
错误的拆分应用程序
很多开发者经常错误的理解微前端概念，以至于陷入困境之中。
要使用这种技术，我们应该将我们的单体前端（与微前端相对）分解为更小的、可管理的部分。，但是我们应该小心不要把它划分得太细。
由于划分不当可能出现如下的一些常见问题：
- 不得不增加微前端团队之间“共享”的功能/代码。
- 难以跟踪“共享”组件。
- 微前端团队之间的功能/改进依赖关系对开发进度产生不利影响。
- 难以单独的更新、测试和部署组件。
最终，我们需要将所有组件重新组合在一起或者增加团队之间的协调，并且回到单体架构。
结果，我们发现错过了微前端预期的所有优势，并且最终在项目进展中产生了许多开销。
解决办法是什么呢？这里有两种解决方案。
-
垂直可管理切片（传统）
按围绕垂直可管理的功能来划分团队而不是技术能力，这将确保每个团队对自己开发的组件拥有端到端的所有权，这将使开发过程按预期加速、扩展和高效。
图，将微前端分离到团队的有效方法（来源：Cam Jackson 的文章）
-
独立组件（现代）
独立组件在 Web 开发中是一个相当新的概念，因此，经常被误解。
基本思路是这样——我们使用专为单体项目设计的技术来构建由组件构成的应用程序和服务。
您的版本控制系统不会在意它是对组件、整个项目还是仅仅针对一部分进行版本控制。 您的开发工具和构建工作流程都会假设这是一个完整的项目（这就是为什么像Storybook 能够被广泛使用——我们需要一种方法来渲染和测试特定项目上下文之外的组件）。
Bit 通过在单个工作区中开发和组合在一起的组件改变了这一切，但同时仍然保持完全独立。 它们是独立开发和独立版本的（与传统的 VSC 不同，Bit 理解“组件”）。
由于 Bit 是关于独立组件的——它是任何类型的微架构的明显选择。
图，这是一个独立的源代码控制和共享的“卡片”组件。 在右侧 => 它的依赖关系图，由 Bit 自动生成。
-
没有明确的设计系统
当我们通过集成一组组件来开发应用程序时，必须在所有组件中实现一个明确定义的统一设计系统。
缺乏设计系统会导致一些不可避免的问题。
-
代码复用性的降低导致代码重复率升高
将代码拆分给不同团队会降低代码的复用性。 如果事先没有正确规划设计系统，在整个应用程序的不同组件中，每个团队最终都会有重复的功能。
- 由于代码重复而产生的开销。
- 重新实现现有组件会浪费时间。
- 增加丢失实例或误解两个相似组件之间差异的风险。
- 特定组件设计的更改必须在跨多个团队的更多样化的地方进行更改。
- 更难跟踪和修复错误。
-
设计理念不一致： 当团队对每个组件的设计理念不一致时，用户会在同一个应用程序里面遇到不一致的情况。
因此，我们很有可能会错过升级某些部分，这又会导致 UX 的不一致。
-
-
难以跟踪微前端之间的通信
在应用程序中，微前端需要相互通信来达到更改、刷新、触发应用程序中的某些操作。如果没有在通信接口上实施明确的基本规则，随着应用程序的增长，相互通信将更难跟踪和维护。
因此，在开始实施微前端之前，最好开发一个合适的设计系统，实现代码库和团队的独立，这样应用程序就不会变得混乱。
i).不正确的识别底层基础和集成方法
另一个关于微前端的常见错误是考虑为项目建立底层基础的方式。
在决定拆分应用程序以及最终集成的方式时，请彻底考虑应用程序的结构和团队的能力。
确定底层基础
有时，我们最终会拥有错误的基础或降低了开发的敏捷性。
使用应用程序shell作为底层基础是我们通常用于微前端的一种方法。在 shell 方法中，有一个应用程序 shell，它组成了不同的微前端。如果您遵循这种方法，您必须通过识别正确的划分来设置正确的通信方式，通常是通过 URL 参数。
拆分为多个微应用程序是另一种划分微前端的方法。但是，除非得到适当的管理，否则共享代码和优化包可能会成为一个重要的瓶颈。
使用独立组件是另一种解决问题的独特方法。它有一个学习曲线，一是对概念的理解，二是使用像 Bit 这样的平台来管理组件共享。
确定集成方法 微前端可以在构建时或运行时集成。 通常，由于以下原因，我们选择运行时集成而不是构建时集成。
由于组件的版本控制，构建时集成可能会导致同步问题。
在构建时集成中，您必须重新编译并发布整个应用程序以发布单个组件中的更改。
如果延迟加载没有正确配置，最终的包大小可能会变大。
因此，您将不得不考虑这些问题并使用 Bit 之类的平台来管理它们。
ii).尝试适用镜像：微服务
微服务影响微前端已不再是秘密。但是，这两者之间存在显着差异，我们需要注意这一点。
微服务是分布式的，能够使用不同编程语言、工具、技术等，最适合建立健壮性。然而，对于微前端而言，这并不完全适用，我们需要开发类似技术、工具和加强实践。
微服务不鼓励复用，而是支持单独开发。然而，对于微前端来说，通过复用减少影响性能的包大小至关重要。
微服务定义了单独的状态管理，用于隔离存储。使用微前端，虽然我们可以决定一定程度的自主，但最终，这些将成为单一的应用程序。因此，这是不可能完全隔离的，因为微前端必须依赖浏览器中的共享资源，如浏览器存储、历史 API、URL 参数等。
结论：
如果正确实施，微前端架构是一种很好的技术，可以在开发团队之间建立清晰的界限，同时确保正确的耦合和内聚水平。
请记住，在开始执行之前，请仔细了解您团队的能力和规模，并制定清晰的设计计划！
我希望本文中提供的信息能让您免于麻烦，并引导您获得轻松愉快的开发体验。
