这几年在公司经历了随着业务扩张，公司运营后台从小型应用逐步发展为巨石应用（团建四个披萨喂不饱），从巨石应用到拆分成十几个应用的微前端项目，再到后续持续优化的过程。将大佬 Michael Geers 的见解和自己的经历相结合，写出来一些笔记和心得供大家参考。
什么是微前端
每个从零开始的项目，一开始少数几个人一起开发全新的项目有非常棒的体验。但是随着功能不断丰富，项目规模越来越大，团队成员越来越多，某一个人不再了解系统的每个边界，复杂度的上升使得对系统一部分的修改产生意想不到的效果，团队内的沟通也更加烦琐。《人月神话》中描述了这一点，在达到某个临界点后，为团队新增开发人员并不能提高生产力。
这种情况下会将项目划分为多个部分，如水平划分为前端、后端、运维、测试团队。而微前端更近一步将前端垂直划分为不同的产品前端团队，每个团队以页面或片段的形式构建自己的用户界面，并消除对其他前端团队之间的依赖。可以自主决策而不必与其他团队协商，来优化功能开发、简化前端升级、专注业务。
微前端技术并不是某一项具体的技术，而是一种组织和架构的方式。
微前端的意义
微前端的关键和意义，在于实现团队自治。
- 团队可以在各自的专业领域自主工作
- 团队可以选择最适合手头工作的技术栈
- 应用程序之间的耦合是松散的，只是在前端将页面或片段进行集成（
路由、组合和通信）
为什么不构建一个大型的 React 应用让每个团队负责其中的不同部分？团队之间的沟通是非常昂贵的，非常昂贵。当想要改一段别人的代码的时候，即使只是一个工具库，也必须通知所有人，等待反馈，参与的人越多，处理起来越麻烦。 微前端的目标是无共享架构，更倾向于接受冗余以支持更多的自主权和更快的迭代速度。
微前端的一大特点是各团队可以自由地选择技术栈，但这一点非常争议。这使得开发人员从一个团队切换到另一个团队，或者交流最佳实践都变得更加困难。“可以选择”并不意味着必须选择不同的技术栈，实际上使用相同的技术既可以保证更少的沟通开销，也能够自主升级版本。
这样还可以节省前期成本，因为你只需要实现一次基本的应用程序设置，包括目录结构、错误报告、表单处理或者是构建流程。
合理时机
什么时候应该考虑微前端？当团队人数少于 7 人（管理半径），团队成员之间沟通很顺畅，使用微前端没有什么价值。当超过 10 人，不可避免考虑团队的拆分，这时微前端是一个非常值得考虑的选项。
在经典的软件项目中，会将一些中心组件交由一个专门的基础设施团队负责。但在实践中，这些水平划分的团队间会产生很多摩擦。非产品的团队没有动力让共享服务变得比实际需要的更好，将基础设施责任分配到产品团队有助于保持对客户价值的关注。
