为什么我选择了企业级中后台组件库

近期在做团队组件库的方案建设与推广,关于为什么没有使用当前市面上大热的 Antd 等组件库而是选择企业级组件库的一些思考 🤔

我们面临的问题

团队近来的发展迅猛,前端的队伍从开始的 1-2 人发展到目前数十人的规模,业务上也从原来的两个产品变成多条产品线共同发展发力,今年是团队与公司都很关键的一年。

但,在团队与业务都快速扩张的背景下我们却遇到了和其他每一个团队都曾遇到的问题 — 前端工程化

工程化的缺失使得之前团队规模还小的时候在遇到重复的组件与开发任务的时候选择更倾向于单兵作战的解决手头上的问题,于是重复的开发和复制粘贴后稍加修改解决了之前面临的大部分问题。

但是现在团队与业务规模的扩张使得我们面临的问题不再是简单的复制粘贴与单兵作战所能解决的问题,「体验一致性」、「规模化的业务 UI」、「最佳模式」、「未来会产生的需求」等已经急待解决。

「体验一致性」

团队发展至今已经初具规模且分布在全部各个办事处均有研发同学,也连带着各个业务线背后的设计资源与 产品、测试 同学对业务视角不同的思考和诉求。

在业务中彼此配合和需要协作沟通确认的体验与细节占据了很大一部分细节问题,从整个公司层面急需一个完善的中后台业务设计体系出来统一整个产品矩阵的体验,也引出了前端团队统一各个业务线的体验的诉求。

同时统一的体验与组件还可以反过来可以使产品与设计同学更多的参考现有的组件,对每一处必须的修改与拓展有明确的价值,从而约束那些过多的 “创意”。

「规模化的业务 UI」

随着公司业务的扩张,前端的研发任务已经不单单是原先的 1-2 个中后台与 BFF 的同学一起联调发布页面这么简单的任务这么简单。

我们在业务上面临更多的大客户定制诉求与拓展的 【私有化】、【国际化】、【业务多元化发展】的诉求,从原先的单一产品线发展到不同的产品诉求在团队中都有高优先级的诉求。在业务发展的同时也对前端团队的需求吞吐能力有了更高的要求。

在此背景下大量的需求需要通过各种方法提高整体研发同学的效率与需求吞吐率解决,一套经过公司业务沉淀的组件库可以大大的减少目前前端团队对业务组件重复研发的问题和快速帮助研发提升研发效率。

规模化业务的另一大问题是有大量相似或重复的业务场景,例如列表与表格,通过不断的业务精炼与拆解,大量的业务诉求其实可以被抽象成模块与最佳实践。

在规模化的背景与快速迭代的需求下,不断沉淀的企业级组件库对前端的研发同学提供有力的支撑。

未来的需求

业务在加速发展的过程中不仅仅是业务迭代速度与业务开发量上去了,而是从根本上由原来的 「稳定的产品迭代」 变成现在加速的「产品研发与扩张」

在原来可以一期期迭代中完成的诉求现在变得需要团队以 「发展」的视角去审视当前的需求和团队的协作配合。

例如一个项目启动的时候如何做到中后台的「自适应布局」、一件换肤完成「产品色」的替换、支持「私有化部署」、快速便捷的支持「国际化」

这些现阶段还没有提出的需求或许不会影响到当前前端同学的研发进度,但如果没有发展的眼光应对这些「未来的需求」就会导致最后真的需求来的时候投入更多的研发资源与更差的迭代体验感。

主动的审视这些未来可能产生的需求是前端研发素质的体现,同时良好的团队合作和与 PD 及时的沟通会让每一次参与开发的同学对未来产品的迭代有更清晰的认知与规划。

选择

面对团队与业务在发展的过程中出现的问题我们足以分析之后似乎我们面临的问题已经逐渐清晰了。

最终在对比市面上多套企业级中后台组件的方案中选择 Fusion 作为现阶段团队在工程化上踏出的第一步☝️ 原因有下:

  • 开箱即用的基础组件
  • 完善的业务组件研发 & 发布 流程
  • 配套独立站点与文档使得组件落地的成本降到很低
  • block 的引入使得业务上最佳模式与沉淀有了落地的方式
  • 借助 iceworks 工具低成本的完成从 0-1 的启动流程与近乎完善的使用体验
hi you can see me