低代码杂谈一

本文3300字，预计需要10分钟。

随着数字化、移动化推进软件的需求是显著增加的，而云计算、大数据等基础设施的成熟，人们期望以另一个方式完成软件开发的交付，低代码这个不太新的概念又获得了人们的关注。

市面上有关于低代码有许多争论，但是毋庸置疑的是此领域受关注程度越来越高，根据Gartner报告，市场规模年复合增长率超过20%，厂家、平台很多，侧重场景也有差异如表单类、流程类、设计类等。不过核心诉求无外乎提高效率、降低使用门槛，降低成本。

以下基于通用低代码平台，从组成、核心价值、组件之间的关系、设计/演进原则以及限制简单谈一谈个人的理解。

组成

• 模型
• 布局

布局规范

编辑器

• 编译器
• 流程/逻辑编排
• 任务调度
• 权限管理
• 组件库

布局组件库

业务组件库

• 集成管理

应用集成

API集成

数据集成(输入、处理、输出)

数据管理(导入、导出、批量编辑)

数据质量

核心价值

• 提高效率、降低使用门槛
• 封装知识交付能力

工作原理:封装知识和能力，降低使用门槛，减少沟通协作的环节，这里也请读者思考一个问题：单个客户定制需求真的非得完整走一遍严格的流程吗(需求收集->评审->开发->测试->用户验收->部署)，非得那么多人员参与吗？

组件关系

注:不同场景或者语境下描述会有较大差异，以下为个人理解。

应用的输入应为业务架构活动，此活动原则上和是否使用低代码无关。

业务架构师职责：落地企业战略目标去设计业务解决方案，其解决方案的核心是梳理业务流程、业务数据、明确业务侧的各种协作关系。

输出为：业务流程+业务能力，业务流程=活动集合，活动隐含角色、时机和行为；业务能力可以简单理解为活动执行的能力。而流程的输入或输出会用到数据的定义，因此为业务架构师的输出为:数据定义+业务流程+业务能力。

上图DA、AA、TA 均为平台的组成部分，目标是实现(内置)BA定义的流程和能力。

应用价值通过业务行为达成目标完成价值交付，承担业务实体在平台中成为模型,严格来讲业务模型和数据库中的表以及编程中的class语义上有较大不同。主要差异是业务对象的可能由多个表或者class的组成，其行为更多类似Service或者能力层的范畴。

模型定义: 业务模型定义(可能会对应多个对象，也就是说和对象的对应关系为1对多)主要承载 数据定义。

活动执行: 业务行为，偏向于Service或能力层范畴，有时会通过多个业务行为编排组合之后对外服务。

布局:业务对象展示、数据搜集和行为交互

时机+行为:任务调度

对应用进行抽象，通过平台的元素映射，通过业务组件(对象+布局+对象行为等)完成应用价值交互

平台和应用的关系

• 侧重不用

平台:侧重于通用能力封装和交付。不同平台的定位也会有较大的差异，如基于行业的平台也会内置很多行业内层能力，以及应用之间的协调。管理范畴也不一致。

应用：侧重于业务价值的交付，理论上低代码平台不直接面向用户，而是由应用封装之后以应用的形态交付。

• 生命周期不同

理论上平台的生命周期要远远大于应用的，应用 平台的稳定性理论上也要高于应用的。

• 交付方式不同

理论上应用的交付应该更为轻量，比如可以通过元数据同步、导出/导入应用安装包；导入/导出插件完成交付。

平台一般都需要各种流水线来完成其持续部署。

• 资源竞争

二者存在资源层面存在竞争,组织的目标、氛围、承压能力等会决定二者演进的速度和方向，极端情况应用会"绑架"平台，使其"丧失"通用性。

低代码平台的能力

• 自助能力

降本增效的手段之一是领域封装,减少相关环节，取消不必要的协作、会议。自助完成一些业务功能交付；比如查阅相关知识库或者参考类似的应用配置等。

可调试：一些业务流程经过封装，当需要对功能进行验证时，就需要清楚知道流程输入和输出，以及内部处理逻辑，除维护知识库之外，业务组件的可调试能力(甚至可视化)也是非常重要的。

另外常被忽略的是：由于使用低代码的未必都是专业的研发人员，所以平台要有相对比较强的兜底和监控能力。比如防止误操作，与主动发现使用不合理的地方如多重循环嵌套、SQL不合理等，异常服务的检测与隔离，防止局部使用不当引起大范围故障。

• 知识库

这个能力本来想放在自助能力中，后面想了想还是单独拿了出来。因为知识库维护和使用的未必是同一个角色，知识库包括规范、流程文档、平台知识库，应用知识库，最佳实践等。

知识库需要系统的持续维护，使用者最好可以直接"抄作业"完成相关功能的交付；知识库还需要提供良好的搜索能力，否则很多宝藏只能被尘封。

• 知识封装

将开发、业务专家的能力固化到组件中，方便一线人员使用。

同时将相关作业要制定相关作业标准，做到"填空"式作业，一定要杜绝千人前面。做到有纪律，重细节、够专业。

• 自动化能力

如果面向活动营销类的平台可以实现,从设计稿到页面的输出。

如元数据版本管理，应用的持续部署等能力。

• 复制能力

应用的复制能力：从A环境同步到B环境，需要清楚控制同步的文件，同步的内容，否则功能上线就是灾难。

多环境能力：随着生产和开发环境的迭代，如何能在开发、测试环境快速mock 生产的环境，或者如何把生产的环境脱敏"复制"一个，进行功能验证。

• 扩展能力

低代码本质是通用性非常高的底座+相对完善的插件。应用本身也是以"插件"的形式与平台集成，所以要考虑插件的开发、代码复用、版本管理，持续集成，以及卸载能力。

除了MVP版本有需求免疫的超能力之外，真正交付应用时，总有那么一些能力在规划的范围之外，采用何策略进行兜底，以及兜底的成本都是要进行考虑的议题。

部分业务类型有强事务的要求，在扩展插件场景、尤其是多进程的环境下，需要考虑事务一致性的管理等。

• 私有化部署

相对来说平台可能会用到较多的中间件，甚至云上的很多能力如云函数、高可靠的消息中间件等，那么也要考虑在私有部署时是否有可以替代的中间件。

云环境自动备份、Paas资源监控、水平扩展相对成熟，私有部署时，这些能力一般不如云完善。需要考虑资源的容量规划、监控等。

• 集成能力

三个维度的集成:业务集成、数据集成、api集成。落地时更多的以API或者数据集成的形式，数据集成时需要数据有很好的自描述能力，或者平台可以导出相关数据的定义。API 则要考虑应用之间的认证、鉴权等，以及上下游数据一致性验证等。

除内部接口外也可以接入一些外部服务，如图像识别、资料审核等接口；设置还可以接入一些API的应用集市等。

• 安全、合规能力

安全能力自不必说，平台提供应用的宿主，某种程度上也提供了底层一定安全等级的承诺，部分行业对数据的安全有强制的安全、合规要求就更要充分考虑，内置行业规范。

• 可视化能力

可视化的方面比较多，如流程可视化、配置可视化、开发过程可视化等。

开发过程比较理想的情况是提供一个功能丰富的在线IDE,可以实现代码校验，职能提示，语法高亮，以及相关调试能力等。

配置可视化：就是常说的拖拉拽，配置过程要充分考虑受众，部分平台在配置时仅提供界面操作，但是有的复杂的表单通过鼠标操作就过于反人类的；建议可以将配置导出(生成)文本文件，然后再导入;局部配置时最好也可以提供文本式的模板，文本的操作还是有很大的优势。建议开发、设计者多体验一下复杂场景的配置，不要过于沉迷所谓的拖拉拽。

• 国际化能力

设计/演进原则

• 完善平台vs 交付应用 取决于组织的目标，以及所处的阶段，研发低代码平台时需要考虑二者的平衡。
• 平台和社区之间

现在已经很少有公司可以不依赖社区交付软件，很多开发语言也是社区提供的如java、go等。不论后端还是前端的运行时都需要考虑和社区的关系，主要考虑避免过渡依赖社区，应该通过相关规范将其隔离。同时也要有升级的能力, ，避免"祖传"代码，找不到合适的人维护。

• 社区

平台终极的理想是有一个丰富的社区应用仓库，可以由内、外部伙伴完善平台的业务能力，那就要考虑平台的升级兼容策略，社区培养和治理等工作，以及相关生态建设等。

限制

• 低代码构建本身就是一个大工程

自身构建一个大工程，综上所述除了解决低代码平台自身的开发，还需要有一批业务专家参与共同制定相关的主题领域。

也以考虑直接使用业界低代码平台开发、交付应用。

• 组织和流程

组织包括人员以及人员之间的关系，低代码自身内置了对人员的要求，如平台开发人员，应用开发人员，业务专家等。不同的角色有不同的能力模型，需要考虑市场上是否有匹配的人才，还需要考虑平台的能力要求是否适合员工的成长，否则员工工作能力不能迁移，甚至不满足于能力被平台"绑架"而离开。

以上为个人一点流水账式的认知，如有不当之处，望指正。

注：

以上部分观点参考"说透低代码"

https://time.geekbang.org/column/intro/100108401?tab=catalog

4A截图来自<<业务架构解读与实践>>