引子

宜搭负责人骁勇给我举过一个例子，我们小时候逢年过节穿的衣服，都是去裁缝店选一下材料、量一下尺寸，等个半个来月，讨回来就可以穿了，衣服合身又喜欢。镜头切回今天，我们只需要在天猫、淘宝上看看图片、选择合适的尺寸就可以下单了，第二天就可以穿上，偶尔一丝不合身，偶尔大街上撞衫，但我们并不在意，因为我们享受到了更多的便利与高效。受益于这个产业制定了很多的标准化模型，比如身材模型：S、L、XL、XXL，我不再需要每次都去量身高尺寸，现在标准化生产出来的衣服可以满足超过 90% 的需求，除明星或特殊场景之外也不会费心思去量身定制。

image

服装、饮食、汽车乃至各行各业发展至今都已经形成非常成熟、高效的产业链，软件研发行业同样如此，业务需求在增长且变化快，越是技术密集型的工种越容易带来人力不足的瓶颈。这就越需要更多的标准和模型的制定，标准越趋于统一，就越高效，有时候 “放弃创造力才是最大的创造力”，本质是追求普惠，可以预见，未来绝大多数场景将使用标准化模板通过无定制或低定制来完成业务需求。

image

期望的软件研发姿势

接下来就简单谈一谈基于 no-code > low-code > pro-code 渐进式思路的研发体系。

一、 前置概念

在开篇之前先介绍几个概念：

[图片上传失败...(image-bc32d7-1614910639772)]

云计算主要分为三大类服务：软件即服务 (SaaS)、平台即服务 (PaaS) 和基础架构即服务 (IaaS)。

• 软件即服务 (SaaS) 是一种通过互联网交付应用的模式。客户能够通过 Web 浏览器访问 SaaS 应用，这意味着，客户无需购买、安装、维护和更新硬件或软件。SaaS 提供商负责确保一切顺利进行，而且客户通常能够使用最新版本的应用。

• 平台即服务 (PaaS) 能够提供云平台和各种工具，帮助开发人员构建和部署云应用。用户可以通过 Web 浏览器访问 PaaS，所以企业无需购买和维护基础硬件和软件。借助 PaaS，开发人员还能采用租用的方式挑选所需的功能。

• 采用基础架构即服务 (IaaS)，企业可以通过按使用付费的方式，“租用”服务器、网络、存储器和操作系统等计算资源。IaaS 提供商负责托管基础架构和处理系统维护及备份等任务，这样，客户就无需购买硬件或雇佣内部专家对其进行管理。

在 PaaS 层有专门用来支持应用在云上开发、部署、运行的平台，称之为 aPaaS (Application platform as a service)，在 aPaaS 基础上，提供 no-code & low-code 方式开发应用的平台称之为 hpaPaaS (High-productivity aPaaS)，提供快速应用研发能力，比如业务编排、逻辑编排、模型驱动、页面编排等。

以上概念加入了一些我的个人理解，不同平台可能有不同解释，我们接下来对比一下业内几款明星平台，看能给到我们什么参考？

二、 业内精品

• Microsoft PowerApps：微软全家桶服务集成的非常好，比如 Excel，全站写代码的地方都统一为 Excel 相似的概念 Formula/Fx，另外 PowerBI/PowerFlow 十分强大，定位 hpaPaaS (low-code)；

• Google AppMaker：谷歌产，谷歌全家桶服务集成的非常好，谷歌工程师文化在 SCRIPTS 体现得比较极致，无论是后端、前端都使用开发生态的 JS 语法，代码提示十分友好，定位 hpaPaaS (low-code);

• Salesforce SaaS：平台领头羊，集 IaaS、PaaS、SaaS 与一体的云平台，目前市值 1255 亿美元;

• Sap：集 IaaS、PaaS、SaaS 与一体的云平台，相比 salesforce，使用的技术要新一些，体验上要好一些，目前市值 1577 亿美元；

• OutSystems：提供桌面 IDE，最近提供的 OutSystems AI 能够辅助模型设计，定位 hpaPaaS (low-code)，作为后起之秀，表现不俗，已获得多轮融资，在 2018 年估值 10+ 亿美元，俨然成为下一个独角兽。

应用研发能力对比如下：

image

几点产品体验感受：

• Google 和 Microsoft 老牌玩家玩 hpaPaaS 这一套相当得心应手，体验相当讲究，把自家的服务包括三方常用服务整合的非常好。

• OutSystems 类似微软，提供多种流式编排，很多时候不需要写代码，同时也整合了非常多数据服务，比如 Swagger 的 OpenAPI。

• Salesforce 和 SAP 类似，从单一的应用程序，到一套应用程序，到一个快速应用开发平台，企业协作工具，再到一个应用程序容器和数据库提供，提供了一套完整的生态链，以 SaaS、PaaS、IaaS 的分层方式对外输出。

几点参考：

• 高效整合才能降低成本，这是所有玩家的心智，不容质疑。

• 视角要放大，要能够覆盖 90% 场景，必须要构建一套完整的生态链，从 no-code 到 low-code 再到 pro-code 都要有对应的解决方案，且要做到互相之间能够打通，这是 Salesforce 和 SAP 给到的经验，目前 AppMaker 和 PowerApps 主要针对表单、表格垂直领域，还不能够玩大，单一领域视角解决的问题有限。

• 可视化的流式编排针对特定场景提效明显，应对稍微复杂一点的场景，一点也不好玩，比如 AppMaker 就粗暴一点，直接使用 SCRIPTS，书写表达式更舒服，不知道使用 OutSystems 的用户是什么感受。

三 、走过的可视化建站

很长一段时间，国内兴起了很多可视化建站产品，「可视化建站」是「低代码建站」的前身，目标也是不用写一行代码，拖拖拽拽就可以把一个站点搭建起来，但更多的是从表现层（前端）单一领域去解决问题，只能完成静态页面的效果，对于真正的业务很难走完闭环。

总结一下突出的问题：

• 纯前端思维，比如数据服务接入方式，缺少像 AppMaker/PowerApps 支持 DataConnectors 的统一数据接入层，和各个系统没有形成有效整合。

• 能解决的场景也有限，高度复杂的企业级 CRM 系统，不是通篇一律的，业务逻辑高度复杂，面临定制化考验，稍微复杂一点的，需要做的工作可能会更多，甚至有时候搞不定，没有享受到可视化搭建带来的福报。

• 很多专业开发在搭建平台施展不开才华，缺少专业级工具支持，比如 VSCode、Git。

• 不同角色之间不能有效的形成配合，比如后端数据接口，不能在可视化搭建工具中反射出来。

• 搭建页面大多以 Schema 形式存储，代码也不好 diff，在运行时动态渲染也会带来性能问题。

• ......

看到众多业内优秀的设计，给我们带来了很多奇思妙想，典型的 hpaPaaS 这种架构一定程度上能将我们标准化场景完全解决掉，但标准化场景偏消费性质，消费我们生产的物料沉淀、场景沉淀等，这样的纯 hpaPaaS 平台应对企业级场景肯定会透支，我们在为能活 102 年的超大型企业设计商业操作系统时，不能一律求快、求简单，还需要考虑灵活性、扩展性、复杂性，在这套系统上要能源源不断的生产标准化的物料、场景，持续将复杂性问题抽象沉淀，形成一个有效的生态循环系统，我们需要的是一种加强版的 hpaPaaS 平台 —— 企业级 hpaPaaS 平台。

四 、企业级的 hpaPaaS

以我们「企业智能事业部」为例做一下简单的业务分型：

image

中后台业务大多是和表单、表格相关的，这对 hpaPaaS 平台来说是好事，但真正代表企业级场景特别是财务、法务等系统，涉及到的表单可以用魔鬼来形容，比如表单嵌套表格，表格再嵌套表格（存在必然有合理之处），无法使用一套规则来描述，强大如 AppMaker 或 PowerApps，对这类问题基本无解，主要是没有提供 backup 机制，企业级应用最初始状态大多是定制型应用，如何进化为标准化的配置型应用，进一步成为解决方案或商业能力，这是「企业级 hpaPaaS 平台」需要重点解决的。

将较年轻的产品 AppMaker 和 PowerApps 定义为商业级解决方案，将较成熟的 SAP 和 Salesforce 定义为企业级解决方案，商业级能解决大多数通用问题，而企业级是要能解决更多复杂性问题，面对复杂性企业级问题时，我认为最起码要做到两点：

• 将不同场景所需要的能力进行分解、分层，最后通过能力的整合来应对，提升灵活变通能力；

• 同时有通用方案和兜底方案，多种方案之间应该遵循统一标准，是打通融合的。

如果非要用一句话概括企业级 hpaPaaS 能力，我认为是从 no-code 到 pro-code 的渐进式能力，如下图：

image

实现这样的「企业级的 hpaPaaS」有以下几个重难点：

重难点一：从 no-code 到 pro-code

以一个简单的业务系统为例来说一下这个过程。

迭代一（no-code 开发）

最初比较简单，符合标准化的 CRUD：

1. 进行业务建模，配置业务规则；

2. 根据建立好的模型选择标准化 CRUD 模板，直接产出；

3. 预览、发布。

迭代二（low-code 开发）

但是有些地方需要稍作定制，比如时间戳的格式化、页面上需要额外展示用户详细信息：

1. 将标准化生成的产物，以可视化编辑打开；

2. 修改关联字段时间的格式化方式、新增用户信息块；

3. 保存、预览、发布。

迭代三（pro-code 开发）

随着业务复杂度变高，很多业务逻辑需要写更多代码，也希望代码被版本控制、进行 diff 等：

1. 将标准化生成的产物在 WebIDE 中打开；

2. 编辑视图，比如关联的动作，定位到对应动作代码，修改逻辑；

3. 使用 WebIDE 提供的 git 功能，进行代码对比及代码提交；

4. 保存、编译、预览、发布。

no-code 和 low-code 试错成本低，在创业时期我更希望使用这两种方式，随着我的业务的成长，价值逐渐被认可，对该产品的要求也变高，这时候我也愿意投入更多，这时候可以采用 pro-code 方式对我的项目进行精装修，这种渐进式交付能力将越来越多的被推崇。

在这过程中，有一个关键点，no-code 到 low-code 再到 pro-code 始终遵循的是一个标准，在我需要时可以被任意方式打开。

虽然我们期望未来业务研发只有 10% 的工作需要 pro-code 来完成，但 pro-code 的相关技术体系也是不可或缺的，它就是一个全功能开放的底层架构，no-code 和 low-code 在这之上做的更垂直化，所以并不是说 10% 就不需要了，尤其在做企业级研发，pro-code 的存在更是一颗定心丸。

对于 pro-code 核心关键点有：

• WebIDE：pro-code 环节设计上是可以使用桌面 IDE 的方式，但未来必定属于云开发时代，桌面 IDE 天然的和 PaaS 平台有割裂感，过去我们担心 WebIDE 技术不成熟，今天 vscode 引领了新一代的编辑器变革，带来诸如 coder、theia 等功能和性能都很完备的 WebIDE 技术储备，技术上没什么好担心的；

• Git 打通：企业级产品，没有那么随意，一般需要强管控，其中版本控制尤为重要，不管是 pro-code 还是 no-code，最终形态都是一种代码形式的标准产物，都应该托管在 Git 仓库上，在必要的时候可以进行回溯和对比；

• 可视化编辑打通：可视化编辑是 low-code 和 no-code 的代表功能，通过 Recore （统一 DSL）的技术将可视化和 pro-code 打通，是 pro-code、low-code、no-code 三者之间形成互通的必要条件。

[图片上传失败...(image-7c242c-1614910639772)]

重难点二：服务的集成

在上面提到的产品中，都有这样的一个设计，无论是自家的服务还是别人家的服务通过一个集成平台，将他们有机的整合在一起，在任何需要的环节，都能被高效的使用。

image

图片源自：https://developers.google.com/

我们也提出 OneService 概念，期望将与数据相关的接口或服务通过 OneService 集成起来，打通生产中的各个环节，如下图：

image

重难点三：生命力

我们设计的系统，比较关心两个问题：

1. 能创造多少价值？

2. 能活多久？

我认为一个具有顽强生命力的系统，应当在时间维度上持续创造价值，有以下几个关键点：

• 适合的土壤，大风向以及政策鼓励，有强烈市场需求；

• 持续标准化，标准化不是一个固定结果，而是一个动态过程，需要有一个进化机制，保证标准化的生态具有自洁能力，适应行业发展；

• 行业渗透，打通行业链路上下游，将标准、理念融入到行业各节点，能够反哺自己的生态，并有助于形成规模；

• 共同成长，带动行业成长，行业的成长就是自己的成长。

image

五、 未来可期

SaaS 化的平台，以 SAP 和 Salesforce 为代表在欧美国家活的很滋润，在中国刚起步，从过去一年的变化可以看到，国家越来越多的政策在鼓励中小型创新企业，意味着未来 toB 市场前景广阔，阿里整体风向现在也是 toB，钉钉和阿里云已经在这条路上越走越稳，让我们看到，在 toB 这件事情上时机已经成熟，而我们现在要做的就是把本土化的 SaaS 平台做好、做强。

作者：开发者小助手_LS

阿里云云栖号