#一、中台概念
一线业务方快速发现市场和增长点，获知竞争对手。而组织内部的中台能给一线提供强大的技术能力支持，让他们专注于业务，取得业务结果。
而作为前端开发者的我们就是其中的中台之一，我们需要给一线业务方提供强大的技术能力支持，而这种技术支持对技术的要求是随着业务方的带来的业务越来越复杂，要求越来越高也变得越来越高，难度也越来越大，相关的技术解决方案也是不断地在发展。而本文介绍的是前端组件框架领域的发展。
#二、前端能力中台化萌芽
能力沉淀
简单回顾前端发展史，如下图所示：
前端中台能力萌芽
回顾整个发展过程,有一条线索是明确的: 前端工程师在复用和透出越来越强大的能力,为业务前端工程开发提效。
其实隐约有点中台化的味道，但是现在遍地开花的各种组件库能够满足多变的业务方诉求吗？答案是否定的？因为已经说了是多变的业务方，不管是小公司还是大公司，如果业务方的要求是多变的，要求的页面在视觉上有着多样性的要求，那么单纯使用一套ui组件库往往是满足不了需求的。要么是需求方面变更，让甲方改需求，改成比较统一的ui样式，以便降低页面开发的复杂度，使得可以使用一套统一的ui组件库来完成开发。如果能这样自然最好，但是往往是不能的，那么此时就只能有前端工程师自己来想办法了。面对这样的问题，有下面两种解决方案：
独立维护：视觉样式和业界各种库的差异都太大，所以维护一套专属的组件库，来满足公司业务的多样性需求。
优点：还原度高、修改便捷
缺点：需要前端与设计师专职维护、大量重复劳动（重复造轮子，可以使用现有的一些轮子进行修改，但是造轮子肯定是无法避免的。对能力要求更高）
定制现有：找到业界一个六七成相似的库，修改它的默认样式
优点：人力成本可控，沉淀复用
缺点：还原度不足，难以修改
如果是大公司，技术能力比较强、人力也比较足，一般都会有开发自己的框架还有ui组件库，以及专职人员维护，来满足公司的多样性需求。但是对于很多没有这样ui组件库的公司，应该怎么来有效的解决这个问题。可能很多是采用定制现有这种方式，但是种方式看起来省时省力,可是实际操作起来体验却不那么尽如人意。举两个例子。
上图是一个库提供的样式修改方式。提供可视化的站点进行修改,体验很好,动动鼠标就可以把组件库样式修改掉。缺点就是只能改颜色。从之前的 4 个业务方系统可以看出,不同业务方的视觉差异并不仅仅是颜色的差异。只能改颜色,业务方是绝对不可能接受。
这是另外一个库提供的样式定制的方式。它对外暴露了许多的变量, 通过修改webpack.config.js 的 sass-loader/less-loader 配置进行。这种修改方式的问题在于组件样式修改的工作落在了前端身上,而样式的最终决定权在业务方设计师手上。所以前端工程师在修改完样式以后,需要反复和设计师Review还原度的问题。
所以独立维护和定制现有各有优缺点,并没有任何一方出现压倒性优势。最后就出现内部组件库遍地开花,技术栈林立,技术沉淀难以复用。
高可配置ui框架的发展与代表——Fusion Desigin
当时其实在中台思想的指导下,有些组件库的开发者就尝试把组件能力进一步透出,使得“定制现有“这条路更好走,让业务方不用把开发资源投入到基础组件库的开发上来。这个最初的想法就是Fusion Design 起点。
Fusion Desigin 是阿里开源的前端可配置组件库，由阿里工作人员维护，并且未这套组件库打造了一个配置平台。二者结合就是一个组件库工厂，可以生产各种各样的组件库。
Fusion Desigin的特点如下：
为业务方的在页面视觉多样性的需提供了很好的解决方案，前端工程师不用去投入开发组件库和调整还原度
解决设计师和前端工作协同的问题
一般一个项目的上线流程基本都要经历：评审、设计、开发、测试。其中设计师和前端工作协同主要是涉及设计、开发、测试三个流程
设计：设计规范（设计师对整个产品在视觉规范上面的定义），视觉设计（绘制视觉稿），标注稿（产出标注搞给到前端）
前端一般都会有一套组件库；但是组件库可能和自己业务线的品牌并不是对应的（比如阿里橙、天空蓝，基本每类业务线都会有个自己的品牌），所以第一步需要在组件层面做UI的定制组，然后是业务逻辑的开发。
测试：最常见的就是设计师和前端坐在一起两天专门做UI还原度review；业务逻辑测试是必做流程不多说。
问题一：重复工作
1. 其中上面标红色的部分是各个业务线的的重复工作：
2. 比如中后台UI的交互都是确定的
3. 比如设计规范都可以在一个基础上做继承和扩展
4. 比如标注可以通过插件统一进行规范，而视觉还原、还原度review这部分设计师最关心的部分，但是做完了设计稿只是第一步，还是要找前端对真实的页面再去调整。
问题二：协同问题
.1. 使用的工具不同对概念的认知不同
2. 设计前端对阴影的理解不同设计师的理想和前端的现实问题之间的差别
3. 每隔一段时间品牌就会升级一次，基础 UI 翻新，带来了较大的工作量
4. 设计师间约定的规范没有很好的落实，已经设计好的设计稿大家共享不便。
已经开发好的组件、模块在团队内没有形成很好的共享、复用。
使用Fusion解决这部分问题：
写在前面——特点：简而言之就是ui设计师通过平台设计、定制一套设计组件库，前端工程师使用这套组件库进行开发，前端工程师可以不用再关系还原度问题，专心业务逻辑开发，后期测试也不用与ui设计师反复进行review。
Fusion工作流：
评审、设计（在平台进行视觉设计）、开发、逻辑测试
项目上线流程：
1. 设计师更加方便做设计
2. 前端只需关注业务逻辑
通过抽象骨架 DPL -> 通过平台定制产出定制好UI的组件、模板 -> 流入设计师的工具里面直接拖拽使用 -> 前端直接使用定制好的组件（不需关注组件UI）
设计师使用的同一套规范的组件，产出的设计稿都是同一套规范。（这里使用sketch插件名字叫FusionCool)
前端不需要关注组件 UI 还原度。（还原度有问题 = 设计在平台UI定制的问题）
让设计和前端不需要再做从0~1的事情
让模块模板得以沉淀复用
设计端使用 sketch 插件（FusionCool）在 sketch 既能设计页面，又能沉淀已经设计完成的模板开发端使用
开发工具 （Iceworks）在项目中既能使用现成的模块，又能沉淀已经开发完成的模块
那未来在Fusion 模块模板达到极度丰富后，使用可以方便的找到各个领域的模块模板来使用，不需要从0开始搭建。
相关工具和平台：
1. 开发者工具 Iceworks
2. 设计师工具FusionCool
#总结
关于前端中后台能力的发展，以及相关ui框架的发展就介绍到这里了。需要强调的一点是任何技术的发展都是来源于现实的需求，前端从原生的js 、html、css可以发展到现在层出不穷的框架、ui组件库都是需求的推动。单纯使用原生技术对于前端各种复杂的业务需求已经不是一个有效的解决方案了。
其中本文介绍的fusion design ——可配置ui组件库就是解决中后台业务方对页面可视化的个性化需求等问题产出的。如果大家感兴趣的可以去了解学习以下，推荐前端工程师和ui设计师去了解和学习。
对前端工程师的建议：对css(3)一定要非常熟悉、css相关预处理语言学习、webpack自动化构建工具了解和学习。
