- 原文地址：Micro Frontends: 5 Common Mistakes to Avoid
- 原文作者：Isuri Devindi
- 译文出自：掘金翻译计划
通过避免这些错误来获得微前端的最大利益
微前端既可以使你的应用程序变得灵活和健壮，也可以成为一种消耗，阻碍你的项目发展。
而且，有许多做法可能会误导任何刚刚进入微前端的读者。
在这篇文章中，我将介绍其中一些常见的错误，以便你能尽可能地避免它们。
1. 不正确地拆分应用程序
许多开发者经常误解微前端的概念，并陷入困境。
要采用这种技术，我们应该把我们的单片机前端（微前端的对立）分解成更小的、可管理的部分。但我们应该谨慎，不要把它分得太细。
由于分割不当而可能出现的一些常见的问题有以下几点。
-
必须在微型前端团队之间 "共享 "的功能/代码增加。
-
难以跟踪 "共享 "的组件。
-
跨越微前端团队的功能/改进的依赖性，会对开发进度产生不利的影响。
-
更难单独更新、测试和部署一个组件。
最终，这将需要把所有的组件重新连接在一起，或者增加团队之间的协调，我们将很快回到一个单片机架构！
结果，我们错过了微前端的所有预期优势，并以在项目进展中产生了许多开销告终。
解决方法是什么？
这个问题有两个解决方案。
垂直可管理切片（传统）
一个解决方案是围绕垂直管理的功能切片而不是技术能力来划分团队。
这将确保自主的团队对他们的组件拥有端到端的所有权，这将使开发过程加速，扩大规模，并达到预期的效率。
独立组件（现代） 独立组件 在Web开发中是一个相当新的概念，因此，它们经常被误解。
其基本思想是这样的 -
我们正在使用为单体项目设计的技术来构建以组件为结构的应用程序和服务。
todos-s
你的版本系统并不关心它是一个组件的版本，还是一个完整的项目，还是一个面汤的配方。你的开发工具和构建工作流程--都假定是一个完整的项目（这就是为什么Storybook被广泛使用的原因--我们需要一种方法来渲染和测试特定项目背景之外的组件）。
todos-e
Bit改变了这一切，它的组件可以在一个工作区中一起开发和组成，同时仍然保持完全独立。它们是独立开发和独立版本的（与传统的VSC不同，Bit理解 "组件"）。
由于Bit是关于独立组件的--它是任何种类的微架构的明显选择。
2. 没有现成的设计系统
当我们通过整合一系列的组件来开发一个应用程序时，有一个明确定义的、统一的设计系统在所有的组件中实施是至关重要的。
缺乏设计系统会导致几个不可避免的问题。
1. 由于降低了可发现性而导致的代码重复。
将代码分割到不同的团队中会降低代码的可发现性。如果事先没有正确规划设计系统，每个团队最终会在整个应用程序的不同组件中重复相同的功能。
由于代码重复而发生的开销：
-
时间会浪费在重新实现现有的组件上。
-
增加了漏掉一个实例的风险，或者误解了两个类似组件之间的区别。
-
一个特定组件设计的改变必须在多个团队中更多不同的地方进行改变。
-
更难跟踪和修复bug。
2.不一致：
当各团队对每个组件的设计意见不一致时，用户将在应用程序的不同部分体验到不一致的情况。
一个特定元素的升级必须在它所利用的每个不同的组件中实现。因此，我们很有可能会错过一些部分的升级，这又导致了用户体验的不一致。
3.更难跟踪微前端之间的通信。
在一个应用程序中，微前端需要相互沟通，以改变、刷新或触发应用程序的某个部分的行动。
如果不对通信的接口实施明确的基本规则，随着应用程序的发展，这些连接将更难跟踪和维护。
2. 不一致：
当团队对每个组件的设计意见不一致时，用户将在应用程序的不同部分体验到不一致。
一个特定元素的升级必须在它所利用的每个不同的组件中实现。因此，我们很有可能会错过一些部分的升级，这又会导致用户体验的不一致。
3. 更难跟踪微前端之间的通信：
在一个应用程序中，微前端需要相互通信，以改变、刷新或触发应用程序的某个部分的动作。
如果不对通信的接口实施明确的基本规则，随着应用程序的发展，这些连接将更难跟踪和维护。
因此，在开始实施微前端之前，最好开发一个适当的设计系统，使代码库和团队的自主性得以实现，这样，应用程序就不会最终变得混乱。
3. 糟糕的代码共享方法
当几个团队在不同的前端部分工作时，一些组件必然会出现在多个Micro Frontends中。实现这些共享组件的最好方法是通过跨团队共享组件来重用它们，而不是通过重新实现来重复代码。
然而，除非你使用Monorepo，否则以NPM包的形式共享这些组件会产生很多问题。
-
很难测试一个共享组件与特定微前端中其他组件的兼容性。
-
很难跟踪不同微前端中使用的共享组件的版本。在整个系统中处理不同的版本可能会导致整个应用程序的冲突和错误。
-
很难整合共享组件的新版本（更新）。
-
很难管理每个组件的CI/CD生命周期。
使用Bit的解决方案
这样的麻烦可以通过使用除Bit外的其他方式轻松避免。每一个用Bit开发的独立组件 也 会作为一个标准的Node包发布，并自动生成package.json。
有了Bit，我们不需要手动跟踪每个组件的依赖关系，因为它可以根据我们的源代码自动为每个组件创建一个依赖关系图，包括使用的版本。
由于一个组件的所有版本都可以在比特平台上使用，各团队可以在他们的工作区将共享的组件升级到新的版本，以自己的节奏。因此，每个团队可以独立和持续地发布变化和更新。
4. 不正确地确定基础和集成方法。
当涉及到微前端时，另一个常见的错误是考虑到你为项目设置基础的方式。
在决定分割应用程序的方式和最后的集成方式时，彻底思考你的应用程序的结构和你的团队的能力。
决定基础
有时候，我们最终会选择错误的基础，或者降低开发的敏捷性。
-
使用应用程序外壳作为基础是我们通常使用的微前端的一种方法。使用shell方法，有一个应用shell，它组成了不同的微前端。如果你采用这种方法，你必须通过识别正确的划分来设置适当的通信方式，通常是通过URL参数。
-
分割成多个微应用程序是划分微前端的另一种方法。然而，共享代码和优化捆绑可能成为一个重要的瓶颈，除非进行适当的管理。
-
使用独立组件是另一种方法，它能独特地解决这个问题。它有一个学习曲线，对这个概念的理解，以及使用像比特这样的平台来管理组件共享。
决定集成方式
Micro Frontends可以在构建时或运行时进行集成。通常情况下，我们选择运行时集成而不是构建时，原因如下。
-
由于组件的版本问题，构建时集成可能导致同步问题。
-
在构建时集成中，你必须重新编译和发布整个应用程序以发布单个组件的变化。
-
如果懒惰加载没有被正确配置，最终的捆绑包大小可能会变大。
因此，你必须考虑到这些问题，并使用比特等平台来管理它们。
5. 尝试图镜像微服务
微服务影响微前端，这已经不是什么秘密了。然而，这两者之间存在着明显的差异，我们需要注意这一点。
-
微服务是分布式的，使用不同的编程语言、工具、技术&，等等，这是最适合建立健壮性的。然而，这并不完全适用于微前端，我们必须发展一致性，要求类似的技术、工具和实践。
-
微服务不鼓励共享，而是赞成更多的自主性。然而，对于微前端来说，重用对于一致性和减少影响性能的包的大小至关重要。
-
微服务定义了独立的状态管理、存储以实现隔离。对于微前端，虽然我们可以决定某种程度的自主性，但最终，这些都将作为一个单一的应用程序被终端用户使用。因此，不可能完全隔离，因为微前端必须依赖浏览器中的共享资源，如浏览器存储、历史API、URL参数等等。
结论
如果实施得当，微前端架构是一种很好的技术，可以在开发团队之间建立明确的界限，同时确保适当的耦合和凝聚力水平。
牢记要仔细了解你的团队的能力和规模，并在跳入执行之前拟定一个明确的设计计划
我希望这篇文章中给出的信息能让你免于麻烦，并指导你完成一个没有麻烦的、愉快的开发体验。
