【转:由Salesforce的元数据驱动引发的联想】

语雀原文链接，阅读体验更佳

引子

最近不小心看了几篇介绍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是近几年前端非常火的一个领域，国