前端能力中台化之路—Fusion Design 成长史(上)

1.浅谈中台

在开始正文内容之前,先简单聊聊“中台”这个词。

首要要说的是“中台”这个词中台非常火,从去年下半年到现在,互联网届多家知名大公司都公布组织架构调整,纷纷表示要建立各种中台。

另一方面,“中台”这个词暂时还没有一个很学术很权威的定义。笔者在知网搜索“中台”,前8页都没有看到任何一家商学院或者经管学院发表和“中台”有关的论文。

所以这里只能基于笔者自己的理解简单聊聊“中台”。

以战争做一个比喻。上图是《红海行动》中的一张剧照。其中黄景瑜饰演的狙击手和*对狙的那场现在还是印象深刻。那么我方狙击手是怎么样战胜*的呢?依靠的战士自身过硬的素质和强大的实力。虽然付出一定的代价,最终还是取得了胜利。但是, 在真实的现代化战争中,对付敌方狙击手,对狙并不是优先选项。

真实情况更像是这样的:

• 一线战斗人员 :“xxx位置发现敌人,请求火力支援。”
• 指挥部: “收到, 无人机出动”

紧接着,敌军所在的楼就被炸平了。

这个模式就是上图所示。一线作战部队,灵活且精炼,能够快速发现敌军位置。而海军、空军等为地面一线战斗人员提供强大的火力支援。快速摧毁敌军设施,杀伤有敌军生力量,最小化己方伤亡。一线业务方像特种部队一样,快速发现市场机会和增长点,获知竞争对手。而组织内的中台能都给一线提供强大的技术能力支持,让他们专注于业务,取得业务结果。

2.前端能力中台化萌芽

前端领域呢? 简单回顾前端发展史, 在最早的时代, 裸写 JS/CSS ,不依赖任何框架。

逐渐大家发现许多代码是可以复用的。久而久之,诞生了 jQuery 和 Bootstrap 这种库。其中Bootstrap可以说是集 JS 逻辑复用和 CSS 样式复用的大成者。它说展示的关于开发组件库的世界观和方法论在之后许多的组件库中都能够看到。进而进入 MVVM 时代,组件化的思想深入人心。在三大框架的加持下,组件库遍地开花。

回顾整个发展过程,有一条线索是明确的: 前端工程师在复用和透出越来越强大的能力,为业务前端工程开发提效。

其实隐约有点中台化的味道。但是现在遍地开花的各种组件库能够满足多变的业务方诉求吗？答案是否定的。问题的核心点在于业务方对于视觉样式的多样性要求。

图中从左到右,从上到下依次是菜鸟网络、供应链、阿里云、Lazada 在用的业务系统。他们的样式差异之大,业界现有的任何一套组件库都不可能同时满足。

那么在这样的现状下,问题的解法有两种选择

• 独立维护: 视觉样式和业界各种库的差异都太大,所以维护一套专属组件库
• 定制现有: 找到业界一个六七成相似的库,修改它的默认样式
  
  定制现有这种方式看起来省时省力,可是实际操作起来体验却不那么尽如人意。举两个例子。

上图是一个库提供的样式修改方式。提供可视化的站点进行修改,体验很好,动动鼠标就可以把组件库样式修改掉。缺点就是只能改颜色。从之前的 4 个业务方系统可以看出,不同业务方的视觉差异并不仅仅是颜色的差异。只能改颜色,业务方是绝对不可能接受。

这是另外一个库提供的样式定制的方式。它对外暴露了许多的变量, 通过修改webpack.config.js 的 sass-loader/less-loader 配置进行。这种修改方式的问题在于组件样式修改的工作落在了前端身上,而样式的最终决定权在业务方设计师手上。所以前端工程师在修改完样式以后,需要反复和设计师Review还原度的问题。反反复复几个来回往往就是这么个结果。

所以独立维护和定制现有各有优缺点,并没有任何一方出现压倒性优势。最后就出现内部组件库遍地开花,技术栈林立,技术沉淀难以复用。

当时其实在中台思想的指导下,有些组件库的开发者就尝试把组件能力进一步透出,使得“定制现有“这条路更好走,让业务方不用把开发资源投入到基础组件库的开发上来。这个最初的想法就是Fusion Design 起点。

本文地址：https://blog.csdn.net/sk_yi/article/details/107396834