直播加餐02｜Freewheel前端工程化的演进和最佳实践

作者回复: 你好，墨白™，你说得太对了。Web应用主要还是业务应用，Web技术最终要服务于业务。在公司环境下尤其如此，不仅要想清楚技术会带来的增益，还要评估成本和风险，能让利益相关方也买账，消除对方的疑虑。

作者回复: 你好，01，我个人认为，多人或多个团队开发同一个产品软件，在共同约定或者工程方式的成本不高的情况下，引入微前端的好处并不明显。 在微前端架构下： * 每个子应用（或称微应用）都可以作为一个黑箱，内部技术、数据、通信基本都与其他子应用相隔离，比如子应用A用JS + React 18 + Webpack开发，而B用TS + React 17 + Vite开发，甚至C用Vue开发； * 各个子应用的（软件开发）生命周期也互不影响，如子应用A每周上线两次，而B每半天上线一次； * 子应用之间的交互相对较少； * 微前端的容器提供路由、鉴权等公用的基础能力。 以上几点都是技术相关的。在技术之外，我认为微前端带来的最大收益还是，对于工作在同一个软件产品上的多个开发团队，每个团队都具有了更高的自治权。 但这个收益是好是坏，还是跟企业的内部情况相关。更高自治权会鼓励团队跑得更快，减少来自其他团队的制约；但同时也在研发整体层面带来了不确定性，一些公共的模块、代码难以收敛，可能会导致研发资源浪费。 我所在的FreeWheel引入微前端架构的一大动机是，优化跨地区/时区的多个开发团队的协作。比如北京和纽约两地的团队，在同一个项目内工作时沟通协作成本还是很高的，把各自负责的功能模块拆分成子应用后，双方都提升了开发效率。

作者回复: 你好，Jy，我完全赞同你的观点。以我所供职的公司为例，由于产品线的复杂性，加上团队是跨地区的，有大大小小近10个前端团队，开发40多个前端模块，这时微前端带来的协作优势足以抵消它的成本。