免责声明
本文大部分为笔者主观观点，请适量服用
读完文章我应该能得到什么？
- 我应该在使用之前了解到的微前端的利与弊
- 我的场景是否要使用微前端架构？
Twitter口水战
19年的时候微前端概念在Twitter上引起了一场大佬们（Dan、Sean Larkin、Joelbdenning）的口水战，我在这里列举下其中的主要观点:
反对派：
- 性能问题
- UI/UE/AX一致性问题
- 可预见性设计
- 状态管理及协调
- 康威定律可能导致组织结构嵌入代码结构
- 为解决技术分歧和技术债务而引发更多的技术债务和分歧
- ...
支持派：
- 独立代码库、开发、部署
- 支持嵌入不同框架
- 提升迭代老旧项目的开发体验
- 渐进式升级重构
- ...
微前端的利与弊
一个新技术或者框架的诞生一定是为了解决一些问题。可能是开发体验相关的提高开发效率等、也可能是用户侧能感知到的优化提升等，当然它也可能带来一些新的问题。所以决定我们使用一个新技术的理由应该是它带来的价值是否大于或者远远大于它带来的问题。因此我们首先思考下微前端带来了哪些价值，以及是否它带来的价值大于或者远大于问题。
利
在支持派的观点下，思考一下微前端的利，到底能带给我们哪些好处，以及这些好处是否我们真的需要？
独立代码库、开发、部署
这个确实是微前端的一大优点，可以将大型前端系统拆分成多个子应用并且独立开发和部署，会提升整体编译和部署的效率。
支持嵌入不同框架
直观感觉上很酷，但是真的需要吗？首先技术上，前端确实有很多优秀的框架，当然可以在团队内使用多个技术栈，虽然可能会增加团队维护成本。但是真的有场景是要在一个项目上使用不同框架嘛？我们知道每一个框架都有围绕他们的生态，在一个项目上同时使用两套或者多套生态系统会大大增加项目的复杂程度、维护成本以及更多的不可知bug的出现。
提升迭代老旧项目的开发体验以及渐进式重构
笔者正是由于这个原因使用的微前端，某一天突然团队有计划要进行一个上一次提交还是在五年前的项目的迭代开发，有原页面的需求改动，也有大量新增页面的需求开发。而此时是否只能选择继续在当前工程（没有统一组件库、使用JavaScript、React 15、Webpack 1）上继续新的开发？最终笔者选择使用微前端。新页面使用统一组件库、TypeScript、react 17、webpack 5愉快地进行开发。如果没有微前端，想不到除了只能在老的项目里继续痛苦开发还能做些什么，感谢微前端。
微前端核心价值，qiankun主要贡献者写的一篇文章阐述微前端的核心价值。笔者比较认同文章里的核心价值在于 "技术栈无关" ，也确实是由于这个需求使用的微前端。但是笔者认为在一个项目里，倾向于使用同一个技术栈生态，除了一个产品本身的目的就是为了整合多个产品的情况下，想不到其他原因在一个项目中同时使用多个生态的好处，同时也会有一些弊端。
弊
性能问题
这里一般指嵌入多个微前端会导致重复依赖大型的框架，目前可以使用externals、federation，在运行时导入依赖的方式解决多个微应用公用大型框架或者资源包的问题。
UI/UE/AX一致性问题以及可预见性设计
当项目是由多个微应用组成时，这个问题确实是一个存在的问题，社区讨论使用统一组件库进行解决，笔者觉得这比较理想，本身微应用的使用可能是不同框架、或者不同技术栈，前面也提到了核心价值的技术栈无关，也就是可能大概率使用不同组件库，所以大概率可能导致UI的不一致性问题，以及进行可预见性设计等。所以对UI高要求的产品可能不会使用微前端，当让可以强行使用然后使用统一的组件库、样式库等。
状态管理及协调
这个问题single-spa及其他微前端框架是有解决方案的 ，但不建议在UI上有状态交互。
康威定律可能导致组织结构嵌入代码结构
为解决技术分歧和技术债务而引发更多的技术债务和分歧
是的，这也是很多反对者所诟病的一点，其实微前端就是允许技术分歧，对于技术债务出发点就是主张先绕过去而不是先攻克。直观上可能觉得不好，但是对于老项目及技术栈陈旧的项目进行迭代，确实能够节省人力去延长项目的寿命，也确实造成了技术债务，以及更多的技术分歧。
到这里我们基本上了解了微前端的利与弊，所以我们确实需要更加客观地平衡是否使用微前端。说白了其实各种技术都是有优劣的，业务也是多种多样的，我们开发者就是在两者之前进行平衡，很难既要又要。
我的场景是否要使用微前端
经过上面利弊分析，笔者整体上是偏向认为使用微前端架构需要非常克制的。列举一下笔者认为的场景是否要使用微前端。
可以使用：
- 老项目的重启并且要进行一些新页面的开发或者打算进行渐进式重构
老项目技术栈可能过于老旧开发体验不是很好，并且开发效率低下，可以使用微前端架构升级，可以是新的页面开发体验更好，开发效率更高。对于新老组件库注意和项目组沟通UI不一致问题是否可以接受。 - 项目的定位就是一个整合类型的系统，需要整合多个其他团队的系统
- 特别特别大的项目，需要拆分多个系统去提升开发效率。
不使用：如果没有以上的理由去使用，那么不要使用微前端。
