我一直想知道大型Web应用程序是如何构建的！我发现了秘密的秘密，这成为了我的热情。在经历了大规模使用微前端的优势和痛苦之后，我决定记录下这段旅程并分享一些“最佳实践”。这是设计遵循微前端模式的应用程序时最佳实践的免费练习列表。应检查每个“规则”，并根据您的特定用例评估其优点/缺陷。微前端之间的零耦合为了实现这种架构的好处，应该尽可能避免意外耦合；这将释放微前端模式必须提供的灵活性和可扩展性，并允许部分升级或未来完全重用应用程序。写信用未来的证据替换您的应用程序。每个微前端都应该能够在隔离或容器应用程序中呈现。所需数据应由每个微前端加载，避免数据瀑布。做?：可以在不影响其他微前端的情况下交换共享库。加载渲染所需的所有数据。不要?：在不同的微前端之间进行集中存储/共享数据。共享积极开发的库。独立的代码库每个微前端都应该有自己的代码库，选择的版本控制不应该对项目的开发或部署方式产生任何影响。将所有项目都放在一个单独的或单独的存储库中是很好的。做?：使用单一代码库monorepos。使用单个回购协议。每个微前端都应该独立部署每个微前端都有自己的CI/CD管道，并且能够部署到生产环境而无需依赖其他微前端。一个应该避免的常见反模式是“hell'sdeploymentqueue”，其中不同的微前端紧密耦合，需要以特定顺序部署以避免破坏应用程序。做?：有一个单独的CI/CD管道。按需发布。不要?：制定发布时间表。具有允许以前版本的增量/顺序部署。微前端应该独立测试由于需要单独的微前端并在容器应用程序内部呈现，因此对整个解决方案也使用单元测试和集成测试来测试它们是有意义的。做?：对每个单独呈现的微前端进行单元和集成测试。作为端到端测试的一部分，在容器应用程序中运行微前端渲染的集成测试。微前端应该版本化当一个新的微前端部署到生产环境时，以前的版本不应该被删除，新版本应该用语义版本或类似的版本号来标记。由容器应用程序决定使用（管理）哪个特定微前端或始终使用哪个特定版本（Evergreen）。DO?：使用语义版本控制。使用特定版本或“最新”。不要?：需要在全球范围内部署更改版本。删除之前的版本。最小通信微前端之间的通信应该尽可能少和简单，尽可能避免全局状态和特定于框架的解决方案。如果两个或多个微前端共享大量消息以提供它们的最小功能，则它们可能耦合得太紧，并且它们可能共享足够相似的目的，因此应该考虑将它们集成为一个。做?：保持消息小而简单。尽可能避免有状态和通信框架。不要?：股东。有不必要的交流。CSS应该是一个微前端的CSS不应影响其他微前端。做?：为你的CSS定义范围。使用CSS-IN-JS或命名法库，如CSS模块。不要?：使用全局CSS。最终提案做?：尝试创建自治团队。尝试围绕业务功能安排微前端。可重用性是一个很好的“副作用”，而不是目标。不要?：不要因为它是“新”的而强加这种架构风格。您不需要多个JavaScript框架。您不需要“微前端框架”。微前端不必是“微”的。原文链接：https://medium.com/swlh/rules-of-micro-frontends-7b96c10dde9
