引子
最近不小心看了几篇介绍Salesforce和元数据驱动的APaaS平台相关的文章，浮想联翩，遂出此文。
Salesforce成立于1999年，首先提出了“No Software”（去软件化）和SaaS（软件即服务）理念的公司。这家靠做中小企业SaaS CRM起家的公司在这20年间业务走出了一条惊人的增长曲线，其市值从2004年上市时11亿美元跃增至1400亿美元，已经可以比肩老牌的全球企业软件巨头Oracle和SAP。Salesforce提供的APaaS平台(Force.com)提供了快速开发的条件，开发者在几个小时内就能完成应用的开发、测试、部署，并能够随时调整或更新，同时这种开发对编程能力的要求降低，可以使得开发者更关心具体业务的实现。支撑Force.com的是一套基于元数据驱动的架构体系。
以下内容是我个人从前端视角的一些思考和联想，场景暂限定在中后台领域，个人愚见，不当之处敬请斧正。
天下武功，唯快不破
作为业务技术团队，业务方总是希望我们可以快速把业务上线，让业务先跑起来，支持业务从0到1，让业务快速试错的过程中又可以快速迭代，促进业务快速发展，尤其是创新型业务，市场机会稍纵即逝，“那流淌的时间可都是金钱呐，我的旁友！”
但现实是传统的项目研发流程冗长，需求评审、交互设计&评审、技术设计、数据开发、服务端开发、前端开发、联调、测试、发布、部署一套流程下来，一个普通项目少说也得一两个月的时间，同时也让技术同学痛苦不堪，大量的开发工作，联调测试，项目倒排，身心俱疲。即使换成敏捷开发模式，研发总量并没有减少，只是拆分成更小的粒度快速迭代，虽然一定程度上解决了快速响应的问题，但短周期补丁式的开发模式，使用不当反而会让产品未来难以维护，出来混总是要还的，而且极致压榨下，团队可能会更累。再将范围缩小到中后台领域，绝大部分的页面都是非常模式化的表格、表单、详情等页面，只是复杂程度不同，设计师一般会遵循现有的范式，不会有过多的发挥在里面。
”这个需求很简单，怎么实现我不管，明天上线！“
面对曾经的这个梗，我们只能“呵呵”，但也许未来有一天，我们不用等明天，需求评审完就给你上线！甚至都不需要拉技术同学评审需求，业务方同学或产品、设计师同学自己就搞定了。
出招吧！少年
面对研发提效这个永恒的话题，作为全宇宙最能折腾的前端技术同学们这些年一直在三个方向进行探索：
pro-code: 通过一系列的工程化手段提升代码开发效率，旨在将前端研发进行工程化、标准化，流程化；
low-code: 将标准化的基础设施，通过可视化的方式进行快速组装(或通过图片、数据模型等生成)，再辅以配置化和少量代码进行功能定制、数据接入等，旨在屏蔽前端技术工程细节，减少代码，高效复用；
no-code: 无需写代码即可完成UI开发，彻底屏蔽前端技术工程底层细节，本质上还是基于标准化的基础设施，在机器干预和人工干预下，可视化、智能化完成数据和业务模型的UI表达；
pro-code
通过代码的方式来实现业务需求，是目前技术研发最常用的方式。这几年前端工程化的浪潮下，技术上的体现也多数在这个层面。从优秀的前端框架，标准化的基础物料，到各种工程化配套设施，再到研发流程系统平台，对前端研发流程的全生命周期提供了全方位的管理和支持，而且将整套工程化上云，在线完成前端应用完整的研发流程，包括近一年发展比较快的WebIDE，更是把写代码也放到了云上，随时随地，一个浏览器就可以完成开发工作。
优势：非常灵活，技术人员对代码高度掌控，对于任何定制化的需求都可以实现，不受技术平台限制；
劣势：对人要求高，专业性、开发人员数量都可能成为瓶颈；
点评：以代码为中心的软件开发仍然是劳动力密集型的活儿，开发很多精力仍然需要放在如何写好代码和环境问题上，随着技术的发展，编程语言、框架、工具、系统平台等不断的升级变化，会造成无法复用原有系统的资源，加上环境的变化和系统软件需求的变化，让软件研发无法快速应对。
low-code
当有了标准化的基础设施之后，就可以基于这些基础设施进行UI的生成和编排，对于一些稍复杂的交互和逻辑还是需要辅以少量代码。主要的方式包括可视化搭建和配置化等。拖拽组件生成UI，设置组件属性，绑定数据源，写一些交互的实现代码等，直接发布或者生成可继续二次开发的代码；配置化一般提供功能大而全的模板，开发诸多可配置的属性或接口，最终生成schema交由模板(渲染引擎)来渲染最终页面。
优势：减少代码量，大部分代码由框架自动生成，开发有一定的定制空间；
劣势：受平台的约束，只对标准化场景提效明显，非标场景反而可能降效；
点评：低代码的方式构建UI是近几年前端非常火的一个领域，国内外也出现了非常多优秀的产品，其核心是在一定的约束下快速生成(套用)模板代码的方式，以减少纯代码开发的投入和提升体验一致性和代码质量(健壮性)；
no-code
不需要写代码，通过可视化搭建直接、可视化建模、模型驱动等就可以自动或手动生成相关的UI。可视化搭建和low code一样，拖拽组件生成UI，设置组件属性，直接在线发布，比如营销活动场景页面的搭建，一些调查问卷，审批流程等的搭建。
模型驱动对服务端开发来说已经有十几年的历史了，有非常成熟的模型驱动架构(Model Driven Architecture, MDA)和模型驱动开发(Model Driven Development, MDD)的理论和实践。而对于前端来说，也就是这两年才逐渐兴起的。历史总是惊人相似，当前端开发逐渐进入软件工程时代，服务端已经解决过的问题，前端又需要来一遍，但我们至少有了前人的经验可以借鉴。
优势：完全屏蔽技术底层细节，非技术人员也可以完成开发工作；
劣势：定制能力弱，只能在特定标准化场景使用；
点评：不写代码就可以完成UI的开发，是一种比较理想化的方式，感觉不是前端程序员该干的事儿啊。没错，这种方式就是给非前端技术或非技术人员使用的，完全不需要掌握前端技能，所见即所得，这种方式对于不懂前端技术的人员有很大的吸引力。
元数据驱动
比划了半天，现在才算正式进入正题，前面更多的是论述前端UI层面如何提效开发，而下面将通过升维思考，对传统前端开发进行降维打击。让我们先了解下什么是元数据驱动开发：
元数据驱动开发，就是基于元数据对象声明式开发整个应用，围绕元数据对象创建界面、业务流程、领域服务、领域对象及物理存储表结构，围绕元数据对象进行测试（包括测试数据生成、用例管理等），围绕元数据对象进行局部个性化需求定制（包括界面、流程、服务、表结构等），围绕元数据对象进行问题定位，从而达到通过元数据对象驱动整个应用开发过程的进行。
开发的核心由代码变成了元数据，开发的工作变成了对元数据的配置和部分功能定制，而应用的大部分代码由框架直接生成，或者根本没有代码，直接解析运行模型，执行相关的业务逻辑或渲染UI。这样的模式非常挑战我们对传统软件开发的认知，也非常考验平台的技术工程能力。
基于元数据驱动亦或是基于模型驱动的核心思想就是把软件设计开发的复杂性分散在不同的层面上，在每一个层面上只关心一类问题，让整体的复杂性分散为多个层次上的简单性。最终目的就是通过架构上的分层来实现软件开发的快捷和可重用性。这种开发模式对于传统的软件开发在根本性上进行了改进。
当问题越来越复杂的时候，我们通常的做法就是在中间加一层抽象，虽然可能增加整体架构的复杂性，但对上层来说，框架会消化掉部分复杂性，而且框架还可以不断自我进化，带来的价值是巨大的。
计算机诞生之初，软件是用汇编语言进行开发，晦涩难懂，只有非常专业的计算机技术人员才能使用，而高级语言的出现屏蔽了底层的技术细节，通过一层抽象，让程序员可以用人可以理解的高级编程语言来进行软件开发。而基于元数据或模型开发，则是更高一级的抽象，不考虑具体的技术实现，而只负责描述真实世界的业务模型、流程，真实的结构和属性等，进而再由框架将模型映射为具体的技术实现。
联想到前端，随着Web业务的日益复杂和多元化，开发模式早已从页面级别发展到了前端应用级别，前端应用也变得越来越复杂，在前端开发中需要驾驭各种框架、组件库、工具、类库等，而且这些技术还在不停的更新迭代，那是不是也可以借鉴服务无端模型驱动这种思路，在中间加一层抽象，来屏蔽技术底层的差异和变化，让开发更专注于具体的业务。
以虚映实，虚实相生
再联想到前端广泛使用的React框架，也有异曲同工之妙。
React中使用的虚拟DOM，其实就是对真实渲染结构的抽象，即虚。通过这一层抽象，带来了两大好处：一是可以实现跨平台的能力，不仅仅局限于浏览器的真实DOM，也可以映射到iOS和Android原生渲染，还可以是小程序，也可以是其他各种GUI；二是虚拟DOM可以在内存中运算，进行diff等，可以大大减少操作真实DOM带来的性能消耗。
React声明式的组件化开发，也是一种抽象，亦虚。将设计好的UI划分为组件，每个组件返回一个该渲染什么的描述，React通过组件的组合来表达完整的UI，并由React来决定在某个时间点展开组件，并根据组件的渲染结果递归地把这些变更实际应用到UI树上。
其实前端开发也是某种意义上的艺术创作，“非实不足以阐发义理，非虚不足以摇曳神情，故虚实常宜相济也。”
Salesforce Lighting Platform
官网描述
Empower everyone to build apps the fast, easy, and fun way.
使所有人都能快速，轻松，有趣地构建应用程序。
The Lightning Platform delivers out-of-the-box tools and services to automate your business processes, integrate with external applications, provide responsive layouts and more. From no-code builders to pro-code tools, the Lightning Platform’s enterprise services and metadata-driven, multi-tenant cloud architecture means that you can focus on what makes your business better from the competition.
Lightning Platform提供了开箱即用的工具和服务，可将您的业务流程自动化，与外部应用程序集成，提供响应式布局适配多端等。从无代码可视化构建到专业代码工具，Lightning Platform的企业级服务和元数据驱动的多租户云架构体系意味着您可以专注于使您的企业在竞争中脱颖而出的优势。
官方示例
一起来看个官方 示例 ，这里仅截取其UI部分选段：
这下面是Salesforce官方文档中给出的一个示例，寥寥几行声明式的代码就实现了一个联系人的表单和详情展示：
- contactForm.js
import { LightningElement, api, track } from 'lwc';
export default class ContactForm extends LightningElement {
@api recordId;
@api objectApiName;
@track fields = ['Name', 'Title', 'Phone', 'Email'];
}
Copy
- contactForm.html
<template>
<lightning-card title="Contact" icon-name="standard:contact">
<lightning-record-form object-api-name={objectApiName} record-id={recordId}
fields={fields}></lightning-record-form>
</lightning-card>
</template>
Copy
- UI Result:
简单的背后其实是一整套完善的基于模型(元数据)驱动的框架，根据业务模型的描述，完全可以由框架在自动生成相关的数据存储逻辑、服务接口、UI和交互，当然生成的是标准化的UI，是特定领域下的业务沉淀。
糟了，是心动的感觉。
程序员的理想之一不就是躺着也能完成需求的开发么，而且还没有bug，性能体验一流，感觉这个小小的梦想就快要实现了呀。
曾经有过的好时光
还记得四五年前在SAP的时候，我们做的一款SaaS ERP产品Anywhere，整个应用都是围绕BO(Business Object)进行开发的，整个系统有几十个标准的BO，每个BO所有的页面(表单、列表、详情)都可以由UI Framework自动生成，甚至包括客户自定义的BO，业务前端开发只需要通过扩展的方式定制个别BO的个别字段或页面区块即可。
自定义实现完全替换BO的某个页面也是可以的，比如当时我负责的Analytics模块(功能是让用户可以通过可视化拖拽的方式完成Dashboard和Report的搭建)，其中所有的页面都是特别定制的。列表页不是表格而是卡片列表，有自定义布局、排序和分组，表单页面是个支持可视化拖拽布局的设计器，可以自由切换编辑和预览态，完全自定义的页面也可以无缝融合在整个UI Framework之下。
而BO对应的BO Framework则可以自动完成业务模型对应物理数据的增删改查和提供标准API服务，服务端同学也可以在基础之上定制部分逻辑。SAP这样的养老型外企的工程师确实还是很有创造力的，没想到当时已经有如此先进的生产力。
hpaPaaS
这里不得不提一下hpaPaaS，这个可能是未来提升开发工作幸福感的一股神秘力量。
hpaPaaS的全称是High-productivity aPaaS，即在 aPaaS基础上，提供更高级、更快速的应用开发的平台，例如提供 no-code & low-code 方式开发应用，包括可视化业务流程编排、模型驱动开发、甚至AI介入辅助开发等。
云计算领域的三大类服务：SaaS、PaaS，IaaS，相信大家已经非常熟悉了，那aPaaS又是什么呢？
Gartner对APaaS的定义是，“基于PaaS（平台即服务）的一种解决方案，支持应用程序在云端的开发、部署和运行，提供软件开发中的基础工具给用户，包括数据对象、权限管理、用户界面等”。看下图应该就明白其中关系了：
这里借用一下 @康为 同学的图，非常清晰
升维思考，降维打击
在汽车未曾出现之前，人们出行的代步工具是马匹。那时，不论是谁，包括客户和商家，想的都是“如何才能拥有(或培育)一匹更快的马?
而客户的潜在本质需求则是拥有一个更快速有效的出行代步工具。那这个代步工具必须是马吗？当然不是。
从而亨利·福特最终给人类带来了汽车。
在新的开发方式出来之前，传统的开发大都是通过代码完成，开发同学想的更多的是如何才能让代码写的更快更好？而软件研发潜在的本质需求是应用快速完成并提供服务(也就是完成业务的诉求，实现信息的流转)，一定要通过写代码完成么？可能不是。
我们可以通过升维思考来看整个应用软件的开发的生命周期，不只关注开发这个阶段，要把上游的需求定义、产品设计，下游的联调、测试、应用发布部署等串联起来，通盘考虑。不仅解决单点的效率问题，更要全链路的提效。
UIaaS，完全的UI服务化，让设计师和前端在针对具体业务定制和实施了一套UI解决方案后，不用再参与一线需求。目前几乎还没有人做到这一点。不过可视化、智能化、模型驱动等方向上的探索，让人感觉这还是个有生之年能够达到的阶段。
所以，全链路的思考软件研发的问题，或许是我们破局的一种方式。
忆往昔，峥嵘岁月
在零售通的这几年，我们也做过low-code/no-code方面的一些的探索和实践，包括
模型驱动UI开发系统- MVIP (MVIP - 基于模型驱动的可视化智能页面搭建平台)
在线代码区块组装系统- MX
人群圈选配置化系统- LIFE
以及数据可视化框架- LV
其实初心都是都是希望用更少的代码在线的方式来完成我们的开发工作，或通过可视化的方式，将前端能力服务化出去，给到非前端同学也可以构建标准中后台页面UI的能力，当然在我们业务的当下我们的定位是我们零售通工作台框架的辅助工具。
MVIP
模型驱动可视化页面搭建
从数据出发，通过数据获取、代码注解、机器干预(智能匹配)、人工干预(可视化配置和编码)等方式生产UI模型，配合标准化UI区块模板生成UI区块，通过灵活响应式可视化布局在线完成PC/H5页面开发部署或源码输出
MX
一站式在线基于代码片段拼装页面开发
通过在线的方式快捷选择区块(代码片段)，嵌入标准化模板中，组装成一张完整的页面，提供对源码在线编码(包括选择的组件区块代码)、构建、发布，一站式完成在线页面的开发；
我们也寄希望于可以通过MVIP和MX将前端能力进行服务化输出，当时给测试团队分享时画的一张图：
LIFE
基于在线schema管理的配置化系统
基于标准化的圈选指标物料，通过在线schema管理的方式完成人群圈选系统的配置化，按角色(小二、品牌商、经销商)设置不同的模板，模板中按不同的业务场景定制指标组。除了支撑前端圈选表单的构建，而且打通了后端，通过指标中的data config，后端可以自动生成指标对应的sql用于圈选人群数据查询服务。
图1：指标配置化
图2：圈选表单配置化、动态化
LV
low-code/no-code数据产品研发框架
一套完整的零售通数据产品研发框架，打通从数据资产->数据服务->数据UI生产->数据消费的全链路，其中的配置化开发部分也是期望通过low-code的方式快速完成数据产品的研发，而数据服务市场则是希望通过no-code的方式，让产品、业务人员可以便捷的消费数据，完全不需要编码。
未来已来
元数据驱动架构在Salesforce已经被证明带来了应用开发革命性的变化，在前端层面，随着前端基础框架的稳定，以及多年工程化的沉淀支撑，未来新的开发模式也必将对前端开发带来革命性的变化。
这几年国内外在不同行业领域通过低代码的方式提供软件研发服务的公司也已经越来越多，国外像OutSystems已经估值过10亿美金，年收入超过1亿美金，这是技术商业化的典型。
在国家企业信息化浪潮之下，有非常大的需求方市场，而政策之下，企业选择本土化解决方案的可能性也更大，阿里作为国内顶级的互联网平台公司，我们既可以做供给方，将我们多年在企业信息化、中后台领域方面的积累，以提供SaaS服务的方式来满足外部企业信息化的诉求，也可以做链接方(平台方)，提供hpaPaaS服务，来繁荣整个生态。
低代码平台也已经成为一片技术红海，未来是否会出现一个或多个巨头级的平台来彻底颠覆我们传统的互联网应用开发模式，并让技术产生巨大的商业价值，让我们拭目以待吧。
虽然一步到位的方式去搞一个hpaPaaS不太现实，工程量可预见应该还是比较浩大的，可能要以百人/年来计量，但我们可以一步步来，渐进式的达成我们的终极目标：
UIaaS > UI PaaS > aPaaS > hpaPaaS
心有光芒，必有远方。