阿里巴巴：服务化管理 7000+ 个项目组件资产

前端早早聊大会，与掘金联合举办。加 codingdreamer 进大会技术群，赢在新的起跑线。

第二十八届|前端 WebGL 专场，2021 年要不要押宝 WebGL 弯道超车，6-26 全天直播，9 位讲师(阿里云/蚂蚁/美团/小米等)，报名上车? )：

所有往期都有全程录播，上手年票一次性解锁全部

正文如下

一、自我介绍

大家好，我是游鹿，我来自阿里巴巴业务平台事业-体验技术-Fusion 中后台，现在是 Fusion 组件体系的负责人。自 18 年加入阿里巴巴开始，一直专注于中后台领域的设计师-前端工作协同，主要是前端研发效能的提升。聚焦组件的 DPl 设计、无障碍化、国际化、跨端研发等等。

今天我会主要从三个方面进行分享，分别是：前端提效发展史、前端标准规范、物料管理服务化。

二、前端提效发展史

今天的主题是“如何借服务化的系统管理团队的组件资产”，在聊“如何”之前，我们先看一下阿里是怎么走这条路的。

总结一下阿里这么多年中后台的发展，我个人把他们分为 4 点：统一的技术栈、统一技术组件、物料的推广、物料的共享：

• 1.首先统一技术栈：大家应该都知道，阿里前端的技术体系都是 React 的，没有 Vue 没有 Angular，这个就是一个统一的技术栈。
• 2.统一基础组件：阿里有淘宝、天猫、盒马、供应链、飞猪、支付宝等等 BU，实际上这么多 BU 在中后台方向上只有两个库，一个是 Fusion 一个是 Antd，除此之外没有其他人或团队重新再做一遍这些底层设施建设。
• 3.统一物料托管：技术组件的统一，只能解决基础部分的问题，比如 Button、Input。但是有一些业务属性明显、在小范围内具有普遍性的组件，例如银行卡号输入器，它虽然不适合作为一个公共的基础组件，但是适合作为业务组件，供业务团队使用。有业务就一定会有业务组件，这些业务组件是需要（也可以）被统一、体系化管理的，而不是让每个团队都再自己去做重复的工程化处理。这是物料托管方面要解决的问题。
• 4.最后一步是物料的共享，当物料生态发展到一定蓬勃发展到一定程度之后，其实一定程度上来说，就不应该有新的物料出现了，一切新的需求，都可以用现有的物料去实现。所以说在这种情况下，完全可以考虑说跨团队的共享，大概是这样的一条路。

统一组件库

我们重点从统一基础组件库开始说，先看为什么要统一。其实为了避免重复造轮子，节省业务精力。对业务本身而言，花费大量的时间来构建底层基础设施并不是一件好事，而且前端领域的底层基础设施都大同小异，不同团队重复构建造成了极大的资源浪费。

我们在这一点上主要看下，阿里是如何做到“使用一套库就可以解决几乎所有 BU 的需求的”。这里主要介绍Fusion，它在初期的核心能力主要是功能 + 换肤，你可以理解为它提供了两个包：

• 一个是骨架包就是基础组件，它包含了比如说 Button、Table 这种组件；
• 一个是皮肤包，它包含了不同的 CSS 样式。

也就是说每个业务用的骨架是一样，但是用的皮肤包是不同的，通过皮肤包 + 骨架组件的组合，用户就能得到一个适合当前 BU 的一套组件体系。我们也提供了平台化的服务，让各个 BU 的设计师、开发者可以直接在网站上进行个性化的组件配置，来生产符合业务诉求的皮肤包，配置化能力包括边、角、线、颜色、阴影等基础配置，包括各个组件的细节配置等。

这个是比较核心两个点，当然除此之外还有其他的能力，比如说一键生成对应的 Sketch 物料，供设计师直接使用等。

这个是一个 1.0 版本的架构图，这套能力的最底层依赖于设计理论的抽象，基于设计方案，抽象出两套骨架组件 —— PC 端和移动端，现在 PC 端是 React 技术栈，移动端是 Rax 技术栈，这套组件体系是整个 Fusion 的核心，我们把它叫做骨架组件，再往上一层是主题配置服务，主要供设计师进行操作。

提供一个视频供大家了解这个在线配置的过程。比如说颜色边角、阴影、线条等等，这个是比较统一的设计，设计上都是规范化的设计，可以配置这些公共的样式之外，还可以配一些组件的样式。比如说我单独对 Button 进行设计，把它的边角从直角风格改成圆角风格，在这个平台上都是可以做到的。刚才提到说这套平台的能力依赖底层设计抽象，也就是说它其实是有限的，但这种有限在中后台这个场景下其实完全是够用的。

按照视频这么一通操作下来，它最终会产出一个 npm 格式的主题包。这个包会记录所有样式信息，把这个主题包的样式资源引入业务项目，再访问页面，可以看到页面样式发生了变化，这个就是 Fusion 换肤核心能力的演示，也是 1 套组件库，支撑阿里这么多 BU 的基础。

解释一下原理，换肤能力用到的是 Sass（Sass、Less 都有这些能力）。Fusion 提供的「骨架组件」包括“JS 逻辑”部分，和“Sass 样式体”部分，「定制化皮肤包」包括了“Sass 变量” 部分。我们把“Sass 样式体”和“Sass 变量”进行编译，编译出一份浏览器可以解析访问的样式文件 CSS 文件，业务项目引入 JS、CSS 两份文件，最终满足不同 BU 设计体系的诉求。

基本上在 4 年前，Fusion 就已经具备这个能力了，它不是一成不变的，我们在这些的基础上不断推陈出新，持续迭代，陆续支持了一些其他功能：

• 可访性：主要是对一些访问 Web 页面有障碍的人士，例如盲人等做了一些提升，支持屏幕阅读器等。主要是遵循了 W3C 的一些规范，对组件本身进行优化。
• 国际化：组件在国际化方面能力也有了比较大的提升，主要表现在比较良好地支持了 RTL（right to left）模式。 在一些阿拉伯国家，它阅读顺序是从右到左的。
• CSS Variable：同时在今年的时候支持了 CSS Variable 在线换肤能力，借助浏览器的能力，用 CSS 变量去进行换肤，把离线配置改为在线切换。
• 一码多端能力：它指的是开发一次，它在 PC & H5 上都可以看，并且 H5 版本的体验又是接近原生的体验。因为 Fusion 主要服务的是中后台，虽说大家上班的时候还是用电脑比较多，比如说商品的入库，商品的上架，下架商品信息填写等，一般可能电脑端更方便，但是在一些特殊场景下也会有 H5 的需求。比如说盒马的员工在操作一些商品上下架的时候，使用收集、POS 机等移动设备更多。

Fusion1.0 版本里的换肤能力是需要 Sass 配合的，而浏览器其实不识别 Sass 语法，所以才需要通过编译生成 CSS 文件。而 CSS 变量完全没有这个顾虑，它就是浏览器识别的，就是 W3C 规范认可的语法。所以说我们只需要把样式部分换掉，从一份完整的 CSS 文件换成两份 CSS 文件，一份是样式体，一份是 CSS 变量的定义文件，即可。这一可以满足在线配置的需求，同时 CSS 变量的效率更高，速度更快。

从题目可以看出“Sass 体系升级为支持 CSS 变量体系”，也就是说 Fusion 本身仍然需要 Sass 体系，CSS 变量体系并不能完全取代 Sass（用户可以摆脱 Sass）。主要原因是 Sass 的一些能力目前是 CSS 变量不具备的。

• 我们在支持 CSS 变量中遇到的第一个挑战就是改动一定要小，我们不希望要重构，目的也不是要把开发环境的所有 Sass 代码换成 CSS，因此我们最终定的方案是只通过脚本改变产出。因为用户只关心他用到的这些文件，比如我们之前其实就用到给他提供了 CSS 甚至还提供了 Sass、Less（当然从统一阿里生态的角度考虑我们不推荐用 Less）。因此，基础组件库的开发仍然采用 Sass 变量方案，只是在打包阶段，通过脚本产生一份 Sass 变量到 CSS 变量的映射，用这份映射与代码进行编译，产出带 CSS 变量的新文件。
• 遇到第二个问题，用脚本编译的话会遇到这样问题，就是 CSS 变量和 Sass 变量虽然都是变量，但实际上他们掌控的范围是不一样的，CSS 变量能力更局限。举个例子来说，CSS 变量更准确的名字应当是“自定义属性”，也就是说它的定位其实是跟 background、color、font 这些是差不多的，它并不能改变类名，比如说 .next-button 这种类名它其实改变不了的，所以说在掌控范围上，他是没有办法做到的，这是一个坑点。
• 第三点挑战点就是函数方法，Sass 有很多 CSS 根本不具备的函数，不存在的函数还比较好解决，有一个坑点是同名函数，例如 rgba() 方法，在 CSS 中，它认为 rgba(#000, 0.5) 是不合法的，CSS 的特性就是不合法也不会报错，最多就是不生效。而 Sass 可以把它正确地识别为透明度为 0.5 的黑色。这也是他们的一个差别。
• 最后在改造过程中其实会有一些涉及到数学计算的部分，Sass 的数学计算基本可以对应 CSS 原生的 calc() 有一些坑点介绍给大家：
  • calc() 的加减运算符前后要保留一个空格，否则是无效的，但是有一些地方很容易忽略，比如说 calc() 前不允许有负号，-calc(1px) 需要写成 calc(0px - 1px)；
  • calc() 内若有具体值，需写清楚单位例如 px ，不写单位在大多数css属性里是不合法的（line-height除外）。

这边列举一些有意思的小点跟大家分享，大家有兴趣想了解更多细节知识点，可以参考知乎文章，这里有支持运行时 CSS 变量换肤的整个改造过程 《✨FusionNext 可配置能力从 Sass 体系升级为支持 Css Variable》。

现在阿里内部保守估计的话，有 7000+ 个项目都在使用 Fusion，然后覆盖了 300 多个团队，这个只是比较保守的一个统计，实际上应该比这些要更多一些的。可以看到上面图中有 4 张图，他们每个团队的风格其实是不一样的，但是用的其实都是一套库，这也就是统一基础组件。

物料托管

前端提效发展史第三个是物料的托管，物料托管是什么、为什么要有物料托管？对于业务来说，光有基础组件是不够的，每个团队都有一些业务属性很强的组件，比如说金融团队可能需要有货币汇率转化的组件，这对于菜鸟的仓储团队来说是根本不必要的，所以说每个团队都会在统一的基础组件的基础上，再建设一套自己的业务组件库，这是在小范围内的提效方案，这一方案肯定是对的。

但从集团层面上看，我们能为业务团队做些什么，能够让他们更好的去维护这套组件呢？所以第三点物料托管这条路其实是一个顶层基础设施建设的扩展，我们希望提供一些这样的顶层的基础服务，达到让物料可以健康迭代的目的。

• 保证组件资产的健康迭代：业务组件需要有 Demo 示例、API 文档、常见问题等，不能只有开发者知道怎么用；
• 所有资产的可查、可用：新同学加入后可以通过平台，快速熟悉现有资产、加速新人上手速度；
• 其他类型资产的沉淀使用：区块、业务组件、模板等（例如纯净的初始项目，而不是新项目来了去 Copy 老项目再删改）；
• 等等其他问题…...

这些都是属于底层的技术能力建设，为了避免重复的人员投入，我们在刚才 Fusion 的架构基础上，又增加了一套叫做物料托管的能力，以保证物料健康迭代、可查可用、类型全面等。

物料共享

第 4 点是物料共享，这也是我们现在正在走的路。当用户已经用上了物料托管能力，他按照规定的格式，使用了统一的工具开发、发布了物料，在公共的平台上能看到找到物料，甚至还能按照团队进行分类管理。当这些物料都在同一个平台上之后，我们其实可以做更多的事情，比如说物料的共享，跨团队的共享。

物料的共享不是指拿来就能用，举个例子饿了么商家团队收到一个需求，要做商品的管理系统，可能要包含商品的上架，下架信息填写等等。这些功能可能已经在淘宝、飞猪团队都有过一份实现了，逻辑都是类似的，增删改查。其实这个适合饿了么的商家同学完全可以站在前人的肩膀上，当他发现别的团队已经做了这些功能的时候，他可以把物料拿过来，调整细节，快速复用上线。

因为物料共享的前提其实是中后台领域的特点，就是说设计规范统一和前端逻辑高度相似，因为中后台都是增删改查表格表单布局，如果我们把生态建设得足够充分了，除了刚才说的跨团队之间的建设可能会快一点，那么后面甚至说可能都不需要设计师和前端了，PD 就完全可以在现有的生态体系里面挑一些他想用的，我们把能力建设的全面一些，在搭建平台上直接可以让 PD 去调整参数，就能发布上线。

这个是我们正在努力的方向，按照这一方向，我们把它分成了三个服务，本地服务、在线标准服务、生态服务，这三个服务分别负责了不同的阶段，这个可以说是现在的服务化系统，是我们管理团队组建资产的大概结构。

总结

这是阿里巴巴中后台提效的路线，相信方法论是一致的，这条路对于规模没有阿里这么大的公司也是通用的。提炼两点个人认为比较关键的节点，与各位分享，分别是「规范统一」和「平台建设」。

三、前端标准规范

规范的体系

上图为包含关系，从面到点为：规范的体系 > 中后台规范 > 业务组件规范，本次分享也按照这个路径从面到点的简单介绍。

一个可能比较全面的前端标准规范都包含哪些内容？简单梳理了一下，参考上图。

• 编码规约，语句结尾是否要有分号，最后一行是否要换行，缩进是 4 个还是 2 个空格等。当然也有一些很好用的工具例如 Prettier、ESLint 等来帮助我们做这些事情，用这些工具插件的前提也是要有规范，这个是编码规约。
• 工程规约，例如用户如何提交代码，是 Git 还是 SVN，提交的格式是什么，commit 信息如何来写，中文还是英文，修复 BUG 是不是要带着 issue 地址，以什么格式来提交等。
• 文档规约，文档应该怎么写？ChangLog 怎么写？
• 根据业务属性的不同，还有 JS Bridge 规范（H5 页面与各个 APP 端的能力调用）UserAgent 规范（如何识别我到底是在淘宝，是在 iOS 的淘宝还是安卓的淘宝）。
• 中后台物料规范（可能是阿里特有）。
• 中后台大家描述协议（可能是阿里特有）。

这种前端的标准规范，每个团队可能有自己的规范内容，比如说你团队可能就不需要 JS Bridge 规范的，那就不放进来。有些团队可能希望把前端和后端的这种 API 规范也放进来，那就放进来。上述规范都属于前端规范体系，这种一定范围内的约定是提效的基础，也是前端规模化、体系化的必要前提。

中后台规范

今天确实是要讲一个比较关键的点，就是中后台物料规范，我们新增的这些物料规范都是前端的规范体系，这种一定范围内的约定，是物料托管、流通的基础，也是前端要想做成规模化体系化的前提。阿里巴巴有太多的中后台了，天猫有中后台，淘宝有中后台、供应链有中后台、盒马有中后台、饿了么有中后台...... 每个中后台又都是类似的，「中后台规范」的统一，是阿里集团各中后台研发平台可沟通、对话的基础。

阿里的中后台规范解决了哪些问题，都有哪些内容？物料托管、物料共享都离不开物料，物料是构成页面的可复用单元，按照粒度的不同可分为：基础组件、业务组件、区块、模板，按照研发模式的不同又可以分为：ProCode 物料和 LowCode 物料。

规范主要从内容定义和结构划分上对物料进行了详细的描述：

• 划分元素：阿里的中后台物料规范中，对前端常用的结构进行了划分，定义了一些常见术语例如业务组件、区块、模板等；
• 源码结构：每一种物料类型都有源码结构的定义。一般指通过传统前端开发方式下，一些文件结构、目录规范等；
• 低代码结构：每一种物料类型都有低代码结构的定义，一般指一套 Schema 描述规范。

页面结构元素划分示意图。

业务组件规范

以“业务组件”为切入点，简单介绍源码 & 搭建的规范现状。

在将业务组件的源码规范之前，补充一个知识点，标准的分级。参考 W3C 的规范指定，标准分为三类：

• A：强制规范，必须实现；
• AA：推荐规范，推荐实现；
• AAA：参考规范，根据业务场景实际诉求实现。

在业务组件层面，比如「目录规范」、「API 规范」等都是 A 级标准，必须实现；「国际化规范」「主题切换规范」都是 AA 级标准，推荐实现，但不强制。而「无障碍规范」、「转 sketch 设计稿规范」、「跨端规范」等都是 AAA 标准，根据业务需求实现。这些规范不是实现的越多越好，是需要参考业务实际的，如果业务不需要就没必要耗费开发精力去实现。

围绕两个 A 类规范展开说明：

• 目录规范：阿里巴巴的业务组件源码的目录规范如上图，他要求必须有构建产物的结构（build/lib）、必须有文档说明（README.md）、必须有可预览的 demo 等。这个结构可以大家作为参考。
• API 规范：如图列举一些 API 规范。

这些是业务组件的源码结构规范，规范统一的好处在于说，淘系的同学开发的组件，饿了么的同学可以直接拿来使用，因为组件规范统一，它完全可以匹配所有 BU 的开发环境，而且组件的使用习惯完全是一致的，名字不会有任何冲突，也不会使用起来完全不会有不舒适的感觉。

除了源码规范之外，阿里的前端中后台规范，还包括了搭建规范，搭建不是今天的讲述重点，如果有想要发展自己搭建体系的公司的话，可以参考一下。

业务组件的规范分了三种：

• 基础信息（A）：描述组件的基础信息；通常包含包信息、组件名称、标题、描述等；
• 属性描述信息（A）：描述组件属性信息；通常包含参数、说明、类型、默认值 4 项内容；
• 能力配置/体验增强（A/AA）：推荐用于优化搭建产品编辑体验，定制编辑能力的配置信息。

总结

其实前端的标准规范是像法律一样的，它是发展变化的，符合大多数人利益的。各位在建设自己团队规范的时候，可以参考一下这些意见：

• 首先标准规范是一定要有的，但是不用说非得一口气补充完，它是可以慢慢细化的，例如中后台标准就是后面加入的。
• 标准要考虑现有的业务实际。举个例子，假如团队内项目在用 Vue 开发，那就不要强行改成 React，要考虑自己团队的业务实际。做需求时以业务为有限，做技术不能为了升级而升级。
• 最后一点就是标准的落地是需要工具来保证的，也就是下一章节的物料管理服务化。

四、物料管理服务化

背景和收益

上一章说的规范们，只是一个软性的约束，怎么样能让大家都遵循规范呢？最好的方式是通过工具，在阿里体系下是如何做这个工具，为什么是它是现在的形态呢？

• 建设底层设施，有助规范落地：一套体系化、直接可用的服务，有助于规范更好的落地，否则规范就只是一句空谈；
• 集团统一管理，数据驱动研发提效：搭建集团前端统一服务，可以从全局上把握集团物料的状态。所有的物料生产数据、消费数据等等，对数据进行分析可以驱动物料升级与研发提效，反哺业务。

最佳实践

视频给大家演示一下现在的成果：

1. 创建物料（本地服务）：创建一个物料的仓库，选择仓库的属性例如是 React 或者 Rax；选择物料类型，比如说业务组件，区块模板等。然后进行一些信息的设定，得到一个初始化的工程，接着在这个工程里进行开发。
2. 发布物料（本地服务）：发布其实就是 npm 发布，发布完了之后。
3. 同步物料（本地服务、物料标准服务）：我们需要把刚才发布的物料与团队进行关联。关联后可以在平台上，自己的团队下，看到刚发布的组件。参考视频，可以看到一个体系化的页面，用来维护本团队的所有物料。
4. 挑选物料（生态服务）：在自己团队物料的根据地上，你既可以使用自己的物料，也可以在物料市场去挑选别人开发的物料。比如我搜索 HelloWorld 这个组件，看到红色这版觉得很喜欢，我就可以把它加到自己的物料体系中，这一把它作为自己团队物料的一部分去使用它。
5. 使用物料（物料标准服务、生态服务）：在页面上查看文档、通过 iceworks 工具等，一键安装到本地项目进行使用。

这个就是完整的一个演示的过程。

如何打造

整个前端组件化的目的是为了提效，发展到后续其实就是基于物料的提效，物料的管理自然也变成了提效的一部分。

• 对于没有计划、精力打造自己的物料管理服务的团队，推荐直接使用阿里已经对外开放的物料管理能力 —— fusion.design
• 对于计划打造，或者想了解背后原理的同学可以参考上图架构。总体上是提供了两类能力，一类是平台化的 SaaS 服务，用户可以直接在平台上创建、维护自己的团队页面；一类是 SDK 能力，提供了各种开放API，供有实力、有诉求的团队引用使用。

五、回顾总结

跟大家回顾总结一下今天的分享，主要是如图三块内容。

六、广告时间

现在是广告时间，让我们一起来建设完善这套服务化系统，创造更多可能吧~ ?

团队介绍

阿里巴巴业务平台事业部的体验技术团队，一个热爱技术，致力于用技术赋能商业，勇于迎接挑战的大前端团队~ ?知乎专栏。

我们对接的业务：交易、商品、会员、评价、店铺。简而言之就是电商体系大闭环的核心业务平台。除了能让千万消费者使用你开发的交易页面买买买之外，你还有机会让千万开发使用你提供的开源库开发出更多有趣的产品，想要知道天猫、淘宝入驻的千万商家店铺页面是怎样用搭建的方式就能快速上线的，想知道双十一背后交易链路是怎样承受住超大流量的，来就对了~

同时，我们还拥有多个开源产品及其活跃的社区：

• Fusion：企业级中后台UI的解决方案；
• ARMS： 应用实时监控服务；
• BizCharts：企业中后台的可视化解决方案。

你可能认识的同学

• 梓骞：体验技术团队的大家长 了解更多；
• 秦粤：Node 社区红人，布道师 了解更多；
• 戊子(荣先乾)： 阿里巴巴设计中台&业务平台前端中台技术负责人了解更多；
• 六猴：深耕前端安全体系多年 了解更多；
• 风月：一个从中医药大学毕业的女前端，现负责数据服务团队 了解更多；
• 潕量(钱陈)： Fusion Design 团队负责人 了解更多。

等你来哦

• 业务平台事业部-前端技术专家-杭州；
• 我们团队长年招聘 P6/P7/P8 岗位的前端、客户端同学，期待与热爱技术的你一起迎接未来的挑战，用技术让商业创新更简单！！
• 简历投递地址： youlu.zgy@alibaba-inc.com。

书籍推荐

《惊呆了！哲学这么好》哲学入门书，像字典一样解释了不少哲学名词，配图巧妙，还可以 Get 不少画图小技巧~

别忘了第二十八届|前端 WebGL 专场，2021 年要不要押宝 WebGL 弯道超车，6-26 全天直播，9 位讲师(阿里云/蚂蚁/美团/小米等)，点我上车? (报名地址)：

所有往期都有全程录播，可以购买年票一次性解锁全部

?更多活动

点赞，Mark 一下。