好的前端开发很难。扩展前端开发，使许多团队可以同时处理大型复杂产品，这变得更加困难。
在本文中，我们将描述将前端整体拆分成许多更小，更易于管理的片段所具备的优势
什么是微前端
An architectural style where independently deliverable frontend applications are composed into a greater whole
一种架构风格，其中独立的可交付前端应用程序被组合成一个更大的整体
随着业务的发展；我们将面对越来越复杂的Web应用；同时；也开始了自己团队的折腾之路；
不过大家现在都有一个清晰的目标-让自己工作更有意义；
我们现在可以清晰的看到现在的前端将整体分成了更小，更简单的组件的开发模式；这些组件或者功能区块可以独立开发，独立测试和部署；同时它们可以最终凝聚为一个产品；这是我对微前端的一个简单理解
微前端看到的一些主要表现是：
- 增量升级
- 简单，解耦的代码库
- 独立部署
增量升级
原来的开发模式下；当开始开发的时候；其实整个项目的架构以及设计模式技术方案都已经被确定了；当进行升级的时候；就会出现各种不同的阻碍；导致实现某个新的功能的时候；发现有新的技术方案可以很好地解决这个问题；但是，没办法了，老项目用的技术栈；我只能在现有的基础上进行打补丁了；
在微前端下就不一样了；我们可以不断的对自己的原子功能或者功能区块进行不同程度的升级；不但不会带来致命打击；反而在优化这部分功能代码；优化了这部分的交互； 当然，前提是你需要很明确的拆分出来这些功能模块
简单，解耦的代码库
这个优点应该比较容易看得到；每个单独的微型前端的源代码都将比单个整体前端的源代码小得多。这些较小的代码库对于开发人员来说更容易使用。尤其是，我们避免了彼此不了解的组件之间无意和不适当的耦合所导致的复杂性。只需要它做了什么；完成了什么功能,进一步阻断干扰；
独立部署
就像微服务一样，微前端的独立可部署性是关键。无论如何，每个微前端功能模块都要可进行持续交付，有明确的的迭代计划和清晰的更改记录；无论如何，它是可以进行独立部署的；不管你是什么部署方式，将这块代码拉出来，就可以打包上线；一定要做到这一定；如下图：
每个微前端都要对应到团队
无论是以页面划分的；或者功能或者更小一点原子组件划分的；微前端开发模式；一定要有相应的团队，责任很清楚的去维护相关的微前端部分；根据产品进行相关功能进行升级；这个团队对这个功能或者组件更加清楚；维护的时候更具有话语权；并且可以的话建议开发团队可以直接接入需求；进行详细的了解；
简而言之
微型前端就是将大而恐怖的东西切成更小，更易于管理的部分，然后明确地表明它们之间的依赖性。我们的技术选择，我们的代码库，我们的团队以及我们的发布流程都应该能够彼此独立地运行和发展，而无需过多的协调。
简单的写了些理解；进行了拆分就要进行整合；下片讲解怎么将微前端进行整合
