今天听了58关于低代码技术的部分分享。从前面的分享来看，是从现状出发，解决了落地的诸多问题，从应用的部分来看，是节省了时间，有30倍效能提升。我注意到分享的过程中有许多概念和问题，的确是开发过程中应该注意的，但真正的低代码开发就是这个样子吗？我又去找了好些低代码产品来复习，比如阿里的低代码引擎，概念更多，面对综合示例，有一点信息爆炸的感觉，业务人员怎么下手呢？我耐心看完三篇协议规范后，还是被一堆概念堵塞着，这些都是必须吗？
不能只是“低代码”
低代码应用的技术特征是低代码，通常是通过“搭积木”的方式开发出来。IT技术人员对此又爱又恨，爱的是可以节约大量的开发时间，极大的提高生产效率，恨的是长此以往拼拼凑凑，难免武功全废。 但低代码应用的典型用户是业务人员，评价低代码应用，要从业务使用的角度来看，甚至于完全不能从软件开发的角度出发。理所当然，低代码应用不能只叫“低代码”应用这么技术化的名字。 那么低代码应用的本质是什么呢？或者是低代码应用的出现表示了什么？我们从低代码的内外视角了解一下。
向内观察
低代码的开发过程
低代码开发不能回避软件开发过程：
- 物料组织及管理：按照某个规范(NPM)创建、发布、更新物料
- 设计组装及调试：按照场景或者需求组装物料并进行详细设置，通过实时预览确认满足设计需求
- 发布运行及更新：自动化打包并发布
当然，更简答的方式就是直接克隆一份已有应用代码，简单修改后直接发布。
我们可以看到的优点是：
- 零编程入门：不需要掌握代码编程，对编程语言没有要求
- 多物料堆叠：根据需要重用物料，需要掌握物料知识
- 所见即所得：设计和多端预览都很方便
- 自动化过程：编程、发布对用户透明
我们可以看到的劣势是：
- 专用的开发工具：与现有的编程工具不同，是一种设计、预览、发布一体化的 IDE 工具，一般联网使用
- 特定的设计流程：和其他工具不通用，只能用于同一套开发工具
- 复杂的设计衔接：需要理解编程知识，管理页面函数和变量
- 特定的发布流程：有些只能发布到指定平台，并不能自己构建
低代码的代码特点
编码是研发过程的必要环节。
我们在说编程语言的时候，高级编程语言与低级编程语言相比，语义更强，同样的功能实现代码量更少，开发效率高。
换个说法，越接近于机器指令的，越是“低”，越接近于人类语义表达的，越是“高”。
而“低代码”和“高代码”的高低与编程语言是相反的，低级代码似乎并不“低级”。
“低代码”开发中使用的组件强，效率高，代码量少，“高代码”的开发效率取决于工程师，代码量一般比较大。
应用是软件结果的必要体现。
低代码应用中有大量的配置，几乎是一切皆配置。从配置的详细程度来看，细节全部暴露了出来。
但配置不是一种代码吗？比如一种声明式代码？虽然大部分配置是通过 IDE 生成的，并不需要手写。
从配置的来说，低代码是多配置应用。配零代码就是全置应用。
从这个意义上讲，低代码并非是低代码，而是大量的配置代码。
借鉴外部
跨专业的融合需求
低代码应用的广泛说明了业务人员对于计算机应用软件的需求，同时也说明信息技术普遍融合到了业务中。
这里不妨借用一下几个产品来说明一下。
从书面文章到电子文章 - markdown 编辑器
在网站上发表文章，需要先编写后排版。如果没有模板，就要先学习网页三件套，html/css/javascript。 但写作者来源千差万别，不可能都想学习这三者，尤其是 javascript。 开发工程师提供的方案从 textarea （多行文本框）升级到 richTextEditor（富文本编辑框），使编辑器的易用性有了很大的提升。 但从来没有哪一个富文本编辑框得到了与 markdown 编辑器相当的影响力。这是为什么呢？
mardown 编辑器使用特点
- 理解零难度，识字就可以看懂，无需专业知识
- 起步零门槛，会用输入法就能写，最简单的文字排版只需要按回车符
- 升级成本低，增加了一些简单的字符，就可以完成文章结构组织、样式标记
- 学习无要求，可以学一项用一项，不用可不学
我们只需要学习写文章的知识，
- 有了段落和标题就可以写很多文档了
- 有了强调、下划线、删除线就可以文字的样式
- 有了图片、列表、引用就可以丰富内容
- 如果要写办公文档，再学习表格
- 如果要写论文，再学习公式
- 如果要强调专业呈现，再学习各种专业图表
如果熟悉了 markdown 的语法，你还可以获得的好处是：
- 任意编辑器编写，发布时复制到指定平台即可
- 通用性强，各家编辑器都可实时预览，主要功能兼容
在写电子文章这件事情上，相比开发网页，markdown 编辑器是不是提供了一种“低代码”实现途径？
从计算工具到电子报告 - jupyter notebook
但凡亲自做过数据分析或者科学实验的人都知道，数据分析不好做。数据采样、数据加工、数据分析、数据呈现，一次分析有70%以上的时间都花在这些过程上。 有了计算机，我们一般都编写数据处理程序来替换人工处理过程，提高效率。 无论是怎样使用程序，都避免不了数据的输入、输出和函数的改进，很难一次编写到位。这就要求分析人员具有编程的基础。 而一旦当你使用了基于 python 的 jupyter notebook，一切困难都迎刃而解。
jupyter notebook 使用特点
- 可以写文档，具有明显的顺序结构
- 可以编写单行代码，也可以编写代码块
- 可以立即执行某个代码块，也可以调整顺序执行多个代码块，也可以不执行
- 执行结果可见，可以缓存
- 可以画图
我们甚至不需要了解编程语言里的函数和变量，因为它是和数学相通的，表达方式也一致。 只要你会数学，你就可以做数据分析。 我们只需要学习数学函数
- 理解数值、数组、矩阵
- 理解预处理、统计、分析函数及其使用方式
- 理解绘图函数及其呈现结果
如果和使用 jupyter notebook 的人协作，你完全可以将文件分享给伙伴，文件记录包括：
- 研究的操作步骤
- 每个步骤采集的数据
- 每个步骤的处理函数
- 每个步骤的处理结果
- 每个步骤的图像分析
在电子报告这件事情上，相比编写 word 文档或者使用更加专业的分析工具，jupyter notebook 是不是提供另一种“低代码”的实现途径？
融合思考
低代码应用需要新解决方案
从已有的广泛使用的低代码应用来看，低代码应用应该具有以下特征
- 专业知识的表达简洁，易于理解，甚至零学习成本
- 编写时可以不依赖于特定的工具，具有广泛的支持
- 进阶时支持渐进式学习方案，知识点即学即用
- 运行时可以指定执行工具，执行规则透明可重复
所以我们是不是可以对低代码应用有一个新的解决方案期望？
- 一种新的业务需求表达方式，非 IT 人员也可以轻松的表达应用需求
- 一种新的业务需求管理方式，非 IT 人员也可以轻松的应用变更
- 一种新的业务应用运行方式，按标准或着规范运行
- 一种新的业务应用编译方式，可以打包为通用格式在多个平台上运行
低代码应用的新构建
我们可以基于以上思考来尝试构建新的应用
物料库
- 源码使用 git 管理，比如 github / gitee / gitlab 等
- 图片素材可以使用文件存储，比如腾讯 COS、阿里 OSS 等
物料
- 元数据：数据标准或者规范，用于描述模型
- API：基于元数据的数据访问服务，主要是自动生成
- 基于元数据的原子 API，自动生成，也可以手动配置
- 基于元数据的数据处理原子 API，可以通过模板生成，也可以手动配置
- 基于 GraphQL 和原子 API 的组合式 API
- 组件：基于元数据的可视化交互元素
- 基于 npm 包的组件实现
其中
- API 和组件可以实现为单文件，通过 url 访问
- API 和组件均支持私有和公有
应用
基于组件构建，可连接API，符合某个元数据标准的程序
工具
- 编辑器：支持 yaml 编写的文本工具
- 预览器
- 远程：Web 浏览器
- 本地：electron
- 编译器（对用户透明）
- 方案A: 基于 vitejs 的构建
- 前端构建工具 vite
- 构建管理
- 方案A: 基于 vitejs 的构建
- 表示载体：yaml 由于应用的结构一般较为复杂，需要选用层次化结构的语言，在表达上，我们可以选择 yaml 作为基本载体。
应用的极简表示
以图书信息的 CRUD 为例，编写以下文件即可
app:
exmaple.com/web/v1/book:
page:
- 图书:名称,ISBN,出版社,数量,单价,总价 | public.com/mat/v1/list
其中
-
app：表示本文件描述的数据为应用 -
exmaple.com/app/v1/book表示应用的部署地址，包含- 应用所属 exmpale.com
- 类型: web
- 版本：v1
- 名称：book
-
page: 表示按照这是一个单页应用 -
图书:名称,ISBN,价格,数量,单价,总价表示模型的详细信息- 名称为
图书 - 属性为：
名称,ISBN,出版社,数量,单价,总价
- 名称为
-
| public.com/mat/v1/list表示模型使用的组件-
|为管道符号，连接模型和组件 -
public.com/mat/v1/list是组件对应的 URI，点击可以访问
-
使用构建工具 lowcode build exmaple.com/web/v1/book -o book 即可得到应用实例。
当然也可以在线预览 lowcode preview exmaple.com/web/v1/book 即可实现实时预览。
模型表示
为了更加准确的描述模型，我们要编写元数据。
以下描述图书模型： example.com/md/v1/book.yml
图书元数据1
model:
/md/v1/book:
图书: 名称,ISBN,出版社,数量,单价,总价
图书元数据2
model:
/md/v1/book:
图书:
- 名称 > "你当像鸟飞往你的山"
- ISBN > "9787544276986"
- 出版社 > "南海出版公司"
- 数量 > 10
- 单价 > ￥59.00
- 总价 > ￥590.00
可以通过完整的示例来描述数据，由编译器自动推断类型。
图书元数据3
如果存在多种示例，可以全部列出。 比如内部刊物没有 ISBN 的，数量有为0的，单价有1000元的，单个书目总价超过100000元的。
model:
/md/v1/book:
图书:
- 名称 > "你当像鸟飞往你的山"
- ISBN > "9787544276986", ""
- 出版社 > "南海出版公司"
- 数量 > 10,0
- 单价 > ￥59.00,￥1000.00
- 总价 > ￥590.00,￥100,000.00
对于存在多种示例的，系统会自动推断数据范围。
图书元数据4
当然也可以自行定义数据类型，版本如下：
model:
/md/v1/book:
图书 | book:
- 名称 | VARCHAR(30) > "你当像鸟飞往你的山"
- ISBN | VARCHAR(20) > "9787544276986"
- 出版社 | VARCHAR(30) > "南海出版公司"
- 数量 | INT > 10
- 单价 | DECIMAL(6,2) > ￥59.00
- 总价 | DECIMAL(11,2) > ￥590.00
当然在此处，如果查看 /md/v1/book，可以看到定义的信息和系统推断的类型信息。
组件表示
这里组件是包含业务模型的组件，包括数据源和物料。 数据源应该是 API， 也可以直接使用模型，可自动自动生成 API。
基于模型的组件表示
以下描述组件实现： example.com/ui/v1/book-list.yml
component:
/ui/v1/book-list:
model: /md/v1/book
type: public.com/mat/v1/list
基于 API 的组件表示
如果数据源是外部 API，可以表示如下
component:
/ui/v1/book-list:
api: another.com/api/book
type: public.com/mat/v1/list
应用的进阶表示
对不不同的应用，组件的组织方式不同。 可以针对单页、门户、管理后台等设置多种模板。
app:
/app/v1/book:
public.com/template/console:
name: 图书管理系统
copyright: example.com © 2022
login: post:/md/v1/session | public.com/mat/v1/login
logout: delete:/md/v1/session | public.com/mat/v1/logout
menu:
- 物资管理
- get:/md/v1/book | public.com/mat/v1/list
我们可以先选择模板，按照模板要求配置信息或者组件。
小结
高度的语义特征是低代码的特质。
将编程变为配置，缩减编码量，只是将事情变复杂，因为用户要进阶使用还是绕不开专业知识点。
只有将代码高度浓缩，隐藏IT技术细节，变成描述性语言，让其他行业的人员易于理解和学习，才有可能变为真正的低代码。
低代码浪潮已经来了，低代码应用的变更维护也在路上。进化之中方显本色，哪一种更好呢？我们拭目以待。