ui-composition-obstacles

问题

松耦合模块边界的最佳范例就是基于 UI 的组合。但是为什么在过去的历史经验里，这样的模块切分的方式很难落地? 有没有什么具体的技术方案可以借鉴?

分析

这个原因是非常多方面的

按职能分工

一个人的时间和精力都是有限的。因为 UI 层要学习的技术实在太多了，一个合格的前端开发要学太多的东西了。所以为了最大化利用这些人已经学到的知识，按职能分工仍然是现下最佳的分工模式。当我们把一个团队指定为只做前端之后，他们自然会把所有和前端的工程都放到一起来。这么做是对的，但是和用 UI 组合来切分模块往往是冲突的。

为角色用户负责

为了让系统的每个角色的用户都有一个负责的团队为他们服务，经常分为 B 端系统，C 端系统，客服系统。这种划分方式显著提升了用户的满意度，因为有专门的团队为他们的目标努力。但是这也带来了系统上的耦合。比如客服系统可能要支持很多种类型的订单，光是对接这些系统，处理订单字段的新增和修改，就要忙死了。按角色用户组建专门的团队也是对的，单这往往也带来切分模块的阻力。

UI 技术的易变性

UI 三天两头都在变。Android / iOS 一直在升级自己的框架，小程序，快应用又纷至沓来。这导致 UI 层的框架没多久就过时了。

应用审核

UI 层的传统是预先打包好成一个整体，有一个发版的概念。这个发版周期就是一种耦合。更糟糕的是，无论是 iOS 应用，还是微信小程序，都要再过一道审核，这些审核都是反对动态加载新功能的，一定要静态把功能都打包好。

UI 组合很大一个被诟病的地方就是要用 lib 引用，要跟着应用打包发版，这个极大限制了每个模块团队的自主性。

微前端

广义上的微前端还包括Android热加载框架等技术。这些方案都对 UI 组合有帮助：

• https://github.com/didi/VirtualAPK
• https://github.com/umijs/qiankun
• https://github.com/berialjs/berial
• https://github.com/rajasegar/awesome-micro-frontends

微前端和微服务一样，就是为了让每个模块可以自主把握自己的发布周期。也可以更好的撇清责任边界，定位故障。 随着 UI 层技术逐渐地稳定下来，可以看到这个领域会有更多的选择，更多成熟的方案。 UI 组合技术也会随着微前端概念又一次红火起来。