前言
今日前端早读课文章由阿里
金禅授权，由公号金禅分享。金禅，阿里巴巴前端技术专家，是集团前端委员会中后台物料生态负责人，集团低代码引擎共建小组核心成员，目前专注于前端物料生态、低代码研发领域。正文从这开始~~
“Low-Code(低代码)”最早是由Forrester提出的，在近几年又赢来了一轮爆发，钉钉6.0发布会推出了“宜搭YIDA”，年底腾讯云推出了“微搭低代码WeDa”，年百度开源了低代码研发框架“AMIS”；低代码研发平台的融资消息越来越多，仅是年3月就有5起千万级融资。
低代码的本质是什么我们知道技术的本质是将idea落地，技术面向的用户一般是开发者，而低代码或者零代码其实也是一种技术手段，但低代码面向的用户则不一定是开发者，它的目标用户是想要实现idea的任何人，低代码是实现CitizenDeveloper(全民开发者)的关键。低代码通过抽象和交互升级隐藏了很多技术细节，抹平了开发者和非开发者的知识差异，让非开发者也能亲手实现自己的idea，这就是赋能，因此低代码的本质其实是跨专业能力的赋能。
为什么低代码再次兴起低代码领域的巨头OutSystems，早在年就已经创立，Mendix创立于年，那么为什么低代码之前没火起来，最近才越来越火了呢？我认为有两方面的原因：
需求井喷互联网发展到现阶段，C端人口红利逐渐消失，野蛮生长的时代已经过去，企业必须精细化运营才能保持增长，同时越来越多的传统企业在向互联网转型，这些都带来了井喷的中后台业务需求。而中后台业务相对于前台业务有一个特点，中后台业务的UI更加模式化，更适合通过低代码搭建的方式来生产。低代码越来越被需要了，这是低代码再次兴起的原因之一。
基础技术趋于成熟任何技术都有其成长周期，低代码研发平台所需的核心技术也经过了漫长的发展趋于成熟，特别是对于前端来讲，我认为前端组件的出现和基于组件的研发链路的广泛应用为低代码的兴起提供了最底层的保障。
前面提到低代码的本质是赋能，抹平非开发者的知识差异；我们可以试想一下，在前端组件出现之前，要实现一个页面，开发者需要编写HTML、CSS代码，这个效率是很低下的(这也是前端组件出现的原因)，如果此时有一个低代码研发平台，非开发者要拖拽HTML标签、配置css来搭建一个页面，这个效率可想而知，这样的低代码研发平台也达不到赋能的目的。而前端组件的出现则大大缓解了这个问题，前端组件并不是一个纯技术的概念，而是从web应用的视角被设计出来的一系列可复用单元，非开发者也能够很容易理解组件这个概念，因此组件的出现和广泛应用为低代码能够真正实现赋能提供了保障。
我们围绕前端物料的积累从前端组件到前端物料前端组件的出现大大的提高了前端开发效率，在实际业务中，我们根据组件的复用粒度和使用方式对组件及其衍生物进行了更细的划分：
基础组件（BasicComponents）：前端领域通用的基础组件，阿里经济体前端委员会官方指定的基础组件库是FusionNext/AntD；
图表组件（ChartComponents）：前端领域通用的图表组件，有代表性的图表组件库有BizCharts；
业务组件（BusinessComponents）：业务领域内基于基础组件之上定义的组件，可能会包含特定业务域的交互或者是业务数据，对外仅暴露可配置的属性，且必须发布到公域如阿里NPM；在同一个业务域内可以流通，但不需要确保可以跨业务域复用；
布局组件（LayoutComponents）：前端领域通用的用于实现基础组件、图表组件、业务组件之间各类布局关系的组件，如三栏布局组件；
区块（Block）：一系列业务组件、布局组件等组合而成的代码片段，不对外提供可配置的属性；区块内部具备完整的内部样式、事件、生命周期管理、状态管理、数据流转机制，能独立存在和运行，通过代码片段的复制实现跨页面、跨应用的快速复用，保障功能和数据的正常；
模板（Template）：特定垂直业务领域内的业务组件、区块可组合为单个页面，或者是再配合路由组合为多个页面集，统称为模板；
上述可复用单元统称前端物料。
前端物料的演进物料开发优先？前端物料是构成前端项目(页面)的可复用单元，那么在一个前端项目的迭代周期中，我们期望的是前端同学拿到了设计稿首先就先能分辨页面的哪些部分可以用现有物料来做，哪些部分要新开发物料，所以在页面开发前先开发缺的物料，或者物料开发和组件开发由不同的人同时进行。
然而实际情况是怎么样呢？分析设计稿中哪些部分可以用现有物料来实现这部分是必要的，对于新物料的开发在很多情况下都会被忽略掉而直接进行页面的开发；前面说过，前端物料是可复用单元，但是对于一个新项目或者单个页面来说，要将页面中可能会复用的部分抽象成一个独立的物料再引入页面开发，整个流程是被拉长了的，效率反而会降低，特别是对于一些人力不足的紧急项目(在阿里很常见)来说，物料开发先于页面开发的效益是不高的。
物料开发优先除了会降低单个页面的开发效率还可能会出现新开发的物料无法在其他地方复用，因为开发者直接从设计稿抽象出新物料是未被验证可复用的，这样的话不仅降低了单个页面的开发效率，对于项目整体的研发效率也没有提高。
那么是不是一定不能物料开发优先呢？其实也不是，如果你对自己的抽象能力非常有把握，能确定新物料能够在项目中被复用，并且项目有足够的人力保障，那物料开发优先可以很好的提效，但是对于大多数情况来讲，物料渐进式演进是更好的选择。
物料渐进式演进我们在写代码的时候，遇到重复的逻辑会将其抽象成一个方法在不同的地方调用；对于前端物料也是同样的，我们可以在遇到重复界面的时候先在项目中对其进行抽象得到一个项目内可复用的模块，当遇到这个模块需要跨项目复用的时候我们再将它独立出来成为一个前端物料，这就是物料渐进式演进的过程。
基于前端物料的研发链路提效研发链路分析在一个前端项目迭代周期中跟物料相关的部分，除了物料的沉淀，物料的挑选和消费会占更大的比重，那么要如何对整体研发链路进行提效呢？我们先来分析一下整个过程中有哪些环节：
如上图所示，开发者最多会经历基础物料-团队物料-物料中心-搜索引擎-物料开发-物料沉淀-物料消费这些环节，除了搜索引擎不可控，其他环节的提效都可以算是研发链路的整体提效。
基础物料
开发者第一步就会去看看基础组件里是否有合适的，如果有的话就直接消费了，所以基础物料的丰富度、文档和品质非常重要；
团队物料
如果没有合适的基础组件，开发者会去看看团队内是否沉淀过匹配的物料，这个过程就因团队而异了，有些团队没有公共的地方沉淀物料，他们只能去团队群里问问；大一点的团队把内部沉淀的物料记录在一个语雀文档里，方便团队内部复用；再大一点的团队可能会建设自己的物料站点，将物料都放在线上站点，这样团队内部的同学可以更快地判别是否有合适的物料，也能更方便的查看物料文档，但是物料站点的搭建和维护都有不小的成本；因此物料站点也是一个可以提效的点；
物料中心
如果团队内部也没有合适的物料，开发者可以去物料中心看看，别的团队有没有沉淀类似的物料，用户从打开物料中心到找到合适的物料这个过程，都是物料中心要优化提效的点；
物料开发
如果上述过程都没有找到合适的物料，那么开发者需要自行开发一个物料出来，帮助用户快速开发物料也是一个提效的点；
物料沉淀
开发好了物料，为了方便下次复用，需要沉淀下来，帮助用户沉淀物料也是对研发链路的提效；
物料消费
物料消费也是可以提效的，例如我们把物料的API和Demo写的更加丰富、易懂，可以方便开发者更快上手，这也是对整体研发链路的提效；
提效方案丰富官方物料开发者在实现一个页面时第一个想到的就是官方物料，官方物料是由专人维护的通用精品物料，可以给业务开发提供质量保障，所以官方物料要在保证质量的前提下尽可能的覆盖更多的场景。
帮助业务自建物料体系官方物料再全也不可能覆盖所有场景，一定会有业务物料被开发出来，那么业务就会存在对业务物料的生产、管理、共享、消费整套体系建设的诉求，因此我们提供了一系列的工具和平台能力，帮助用户快速地自建自身的物料体系：
物料生产与demo托管以build-scripts为底座，通过iceworksadd