从 no-code 到 low-code 再到 pro-code

很多企业级系统发展到成熟期都会有这样的诉求：配置化。经过多年的发展，系统的核心能力已经较为完整，而不同业务线或使用方的个性化诉求本身不大，更多是对于存量能力的个性化改动，为提高交付效率，快速支持业务产生价值，对存量能力封装，提供标准化模板，以配置化方式展示，提供给运营操作，实现低成本定制，实现自运营自闭环。

其背后的技术实现就是low-code。

那no-code、low-code、pro-code三者有什么不同呢？可以参考下面概念说明：

业界有几种全家桶集成解决方案，比如微软的PowerApps，谷歌的AppMaker，Salesforce的SaaS产品。

业界aPaaS平台带来几点参考：

- 高效整合才能降低成本，这是所有玩家的心智，不容质疑。
- 视角要放大，要能够覆盖 90% 场景，必须要构建一套完整的生态链，从 no-code 到 low-code 再到 pro-code 都要有对应的解决方案，且要做到互相之间能够打通，这是 Salesforce 和 SAP 给到的经验，目前 AppMaker 和 PowerApps 主要针对表单、表格垂直领域，还不能够玩大，单一领域视角解决的问题有限。
- 可视化的流式编排针对特定场景提效明显，应对稍微复杂一点的场景，一点也不好玩，比如 AppMaker 就粗暴一点，直接使用 SCRIPTS，书写表达式更舒服，不知道使用 OutSystems 的用户是什么感受。

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

存在以下一些问题：

- 纯前端思维，比如数据服务接入方式，缺少像 AppMaker/PowerApps 支持 DataConnectors 的统一数据接入层，和各个系统没有形成有效整合。
- 能解决的场景也有限，高度复杂的企业级 CRM 系统，不是通篇一律的，业务逻辑高度复杂，面临定制化考验，稍微复杂一点的，需要做的工作可能会更多，甚至有时候搞不定，没有享受到可视化搭建带来的福报。
- 很多专业开发在搭建平台施展不开才华，缺少专业级工具支持，比如 VSCode、Git。
不同角色之间不能有效的形成配合，比如后端数据接口，不能在可视化搭建工具中反射出来。
- 搭建页面大多以 Schema 形式存储，代码也不好 diff，在运行时动态渲染也会带来性能问题。
......

不同目标用户的产品方案有所不同，商业级能解决大多数通用问题，而企业级是要能解决更多复杂性问题，面对复杂性企业级问题时，我认为最起码要做到两点：

- 将不同场景所需要的能力进行分解、分层，最后通过能力的整合来应对，提升灵活变通能力；
- 同时有通用方案和兜底方案，多种方案之间应该遵循统一标准，是打通融合的。

三者渐进式如下：

演进路径如下：

no-code 开发

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

进行业务建模，配置业务规则；
根据建立好的模型选择标准化 CRUD 模板，直接产出；
预览、发布。

low-code 开发

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

将标准化生成的产物，以可视化编辑打开；
修改关联字段时间的格式化方式、新增用户信息块；
保存、预览、发布。

pro-code 开发

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

将标准化生成的产物在 WebIDE 中打开；
编辑视图，比如关联的动作，定位到对应动作代码，修改逻辑；
使用 WebIDE 提供的 git 功能，进行代码对比及代码提交；
保存、编译、预览、发布。

对于 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 三者之间形成互通的必要条件。

服务的集成

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

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

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

能创造多少价值？
能活多久？

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

适合的土壤，大风向以及政策鼓励，有强烈市场需求；
持续标准化，标准化不是一个固定结果，而是一个动态过程，需要有一个进化机制，保证标准化的生态具有自洁能力，适应行业发展；
行业渗透，打通行业链路上下游，将标准、理念融入到行业各节点，能够反哺自己的生态，并有助于形成规模；
共同成长，带动行业成长，行业的成长就是自己的成长。

from 阿里技术