飞道的博客

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

512人阅读  评论(0)

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

其背后的技术实现就是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 阿里技术


转载:https://blog.csdn.net/peter7_zhang/article/details/114381474
查看评论
* 以上用户言论只代表其个人观点,不代表本网站的观点或立场