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