如何通过业务组件提效？

） ，在基础组件的层面功能日趋完善，各个业务团队之间在这个层面的低级重复建设也越来越少，这是非常好的结果。但在业务组件体系的构建上，目前还呈现着百花齐放的局面，由于技术栈的不断扩充（可视化、小程序等），业务组件的开发上还存在着很多诸如工程体系混乱，开发链路不通的问题。

来到企业智能的 5 年多的时间里，经历了团队物料体系从最初的 Arale/kuma，到基于 react-component 的 UXCore/SaltUI，再到现在全面与 Fusion 融合。基础层面的变动也带来了业务组件领域的工具链的不断变化。写这篇文章，一方面记录一下自己在这方面做的一些工作和中间的思考，另一方面也希望能在社区里获得大家的一些宝贵建议，以得到一些新的启发。

一  一个业务组件要开发几遍？

1. 困境

某天，同事 A 找到我，说 TA 的业务里需要构建一个业务组件包，涵盖了 PC 端，小程序和对应的可视化组件，当时我正在做一些关于前端业务能力构建的相关工作，所以想来问下我的建议。这个问题看似是很简单，但实际分析下来却发现有很多问题。

首先，PC 的业务组件当时是使用 飞冰[3]（iceworks，阿里 GUI 构建工具） + deep 脚手架模板（deep 出自企业智能用户体验团队）的方式来开发的，好处是 可以 和 Fus ion 深度打通，发布 和同步物料到 Fusion 对应的 deep 站点都比较方便。小程序/移动端的组件，当时基于 Rax 的动态化小程序组件方案 Fusion Mobile 和 Deep Mobile 刚刚起步，业务组件的开发还没有自己的标准，唯一一套可用的是之前政务钉钉的前端团队做的 gdt-utils 来承载。

而可视化组件，则是由乐高 （ 阿里企业级可视化搭建平台 ） 团队提供的 vdev 工具链，而当时还有一个问题是，由于 PC 端基于 React 框架，而小程序/移动端则基于 Rax 框架，导致可视化开发时也无法通过初始化一个包来完成 PC 和小程序端的开发。

总结起来，开发一个涵盖三种模式的业务组件，需要适应和学习三种工具链，初始化四个包，发布四个 npm package，而后续使用中，使用者需要记住四个包名以及他们对应的使用场景，和在至少两个地方看他们的使用方法。同时在维护的阶段，PC 和 移动端相似的模型、请求、数据处理逻辑也无法得到复用，如果想要复用怎么办？不好意思，那就需要再发一个工具包在几个包之间做流转。这些都在无形中增加了开发一个业务组件的成本，同学们的精力就在这些框架、包和联调的过程中消耗掉了。

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!