智能化软件开发微访谈·第十六期：低代码 / 无代码开发

1）从您的角度看，什么是低代码/无代码开发？业界对于低代码/无代码开发是否存在其他不同的理解？低代码开发和无代码开发之间的区别是什么？

『低代码』，从"低"或 "low"的本意出发应是指，在满足同样功能需求的前提下，相对于传统开发模式，用更少或更简单的代码实现开发需求或等价效果。注意这里开发过程变“低”，并不代表产出目标也可以“低”，否则就失去了意义。『无代码』，顾名思义，即通过非编码的方式实现成常规编码开发完成的需求或等价效果。前者允许编写少量代码，后者则完全无代码。

2）低代码/无代码开发与软件工程领域的一些经典思想、方法和技术，例如软件复用与构件组装、软件产品线、DSL（领域特定语言）、可视化快速开发工具、可定制工作流，以及此前业界流行的中台等概念，之间是什么关系？此外，低代码/无代码开发与 DevOps、云计算与云原生架构之间又是什么样的关系？

显然，要实现低代码/无代码开发效果，必须提前封装好各种组件、业务模块，而在封装的过程中为了加强模块的内聚，降低模块间的耦合，很有可能（非必须）采用 DSL 的方式，HTML 就是一个非常好的实现图形用户界面的 DSL 例子，但实现图形用户界面的方式不一定是 HTML。而理想情况下，让所有封装的组件模块，按照同一种接口标准实现，通过一种预设机制将其编排（框架/平台），这些组件就很容易像在生产线上一样，被开发者们拿来组装成各种想要的系统，这就是软件产品线了，无远开发平台就是一种软件产品线的实现。

而相对中台来说，低代码/无代码开发的目标只是解决开发环节的问题，而中台，除了要解决开发环节如何通用或高效复用的问题外，还需要解决外延的管理问题，比如组织、渠道、流程等等。

至于云计算/云原生/DevOps，低代码/无代码开发工具与之没有必然的联系。如果工具本身是在云上，那么显然它是在 IaaS 上的 PaaS 层，如果产出物也直接部署在云上，那么天然的是云原生，甚至整个运维的过程都不需要了，全部由平台方来简化定义运行时的关注指标，提供相关服务。

3）支撑低代码/无代码开发的核心技术是什么？低代码/无代码开发的火热是软件开发技术上的重要变革和突破，还是经典软件工程思想、方法和技术随着技术和业务积累的不断发展而焕发出的新生机？

方法上，上述第二个问题本身基本已经涵盖，并无特殊性。至于通过人工智能技术生成代码，然后继续基于代码做二次开发这种方式，暂不把它作为低代码技术的范畴，因为代码二开之后，这个过程是不可逆的，后续的维护迭代依然需要基于代码来做，这个过程并不”低”。

近二十年来，没有看到像汇编语言到 C 语言这样的无损简化或者技术突破。更多的是因为现代开发环境的成熟（浏览器标准化，云基础设施完善，人工智能技术能力普及）和业务的积累（C/S 结构向 B/S 结构转化、大量 B 端/C 端用户心智成熟）使得开发者可以在这一新的情境下有所作为。

4）低代码/无代码开发已经发展到什么程度？有哪些成熟的低代码/无代码开发平台？能够支撑哪些应用类型，是否前端应用（包括各种移动端和网页端）仍然是所支持的主要应用类型？低代码/无代码开发能够在多大程度上改变当前的软件开发方式？

实际上，目前市面上的大部分低代码工具，其可行性和完备性都是没有得到充分检验的。实现的场景过于简单，像是表单制作+工作流审批+数据采集等等，更不会考虑持续维护、迭代、扩展等需求。当然，简单不代表在其领域内不完备。要测试某款低代码/无代码的成熟程度，只需在它宣称能满足的领域内，拿一款标准常用软件作为开发目标，尝试开发即可。比如，在信息管理领域，财务软件几乎就是一个标准件，因为全国财务会计制度是统一的，工商局要求每个企业的年报是一样的。财务系统都不能做，不用谈满足其他定制化更深的 ERP/MRP 需求。市面上很多说做的财务管理其实只是一个收付记账对账功能，不是财务系统。

【无远开发平台】是一款在【信息管理领域】比较成熟完备的低代码开发平台，它采用 SQL+配置的方式，可以开发各类 B 端和 C 端应用，产出物可以私有部署或云部署，累计产出系统上千个，内容涵盖到各个领域，可以见无远的案例：https://wuyuan.io/case

当前的开发方式很大程度上是由过去几十年的惯性决定的，不论是从技术成熟度，生态圈，还是对旧系统的依赖和以及未来的扩展和演进，都决定了当前技术管理者选型的方向。现有的低代码/无代码方式很难在已有的信息化场景下改造旧系统甚至做新应用。而要寻找完全没有包袱的业务，并且又愿意尝试低代码/无代码开发的用户其实非常困难。更何况，低代码/无代码在很多需求场景的功能上都达不到要求，只有在能满足同等需求的前提下，才能再谈改变或替换的代价是多少，值不值得做。

5）低代码/无代码开发未来发展的方向是什么？围绕低代码/无代码开发存在哪些技术难题需要学术界和工业界共同探索？

低代码/无代码的未来发展的方向，个人认为有这几点：

首先，一定不能以牺牲功能完整性为代价来实现，否则用户是不可接受的。

除非某款工具能做到在特定领域内，从有代码->低代码->无代码的这个开发模式转换过程是完备的，有本体模型及相关演算做支撑，否则，开发出来的一个系统会是（或者随着需求迭代会慢慢变成）一个残次品，又不得不花更多的成本去请专业开发人员来编码补全。比如，在信息管理领域，一款财务系统，如果只是实现让一个会计做凭证录入、修改、查询以及总账，但是结账功能无法实现，那么最终是无法得出资产负债表的。这样的系统对会计来讲依然是不可用的。系统软件的可用性，必须以完备性作为前提保障。

其次，整个开发模式或框架应该是开放的可持续扩展的。

领域内的知识是会随着时间和空间的变化而变化的。当初应对特定领域的低代码/无代码工具，很有可能因不能满足新的需求，而被完全打破。

能在更高的抽象层次应付领域内将来可能产生的变化，是优秀的低代码/无代码工具实现的表现。比如一款表单设计器，一开始可能支持电话号码、邮件、身份证这种特定输入。假设，现在要增加手写签名输入，得到 base64 图片，是否有能力让平台方或三方快速扩展出这种新的输入形态的组件，并且不影响表单本来的整体逻辑以及对旧配置的兼容。

最后，不能为了减少或规避代码编写而增加更多配置的代价。

比如某工具为了给用户提供丰富的 UI 设置能力，同时要避免用户写 CSS 代码，罗列了二十多个属性设置，每个属性给出一堆候选值。而用户可能只需要改变字体大小和背景颜色，实际上，写 CSS 就是两行的事情；再比如，某个 SQL 逻辑涉及到 连接 3 张表，每个表取 5 到 10 个字段，最后基于两个字段做 group by, 为了避免写代码，要配制出等价逻辑的 SQL，用户需要点开三张表，每张表做关联字段设置，还要逐个选定字段，最后配置分组，操作界面复杂得非常难看或者根本做不了，这样的无代码其实意义是不大的。更何况，等到需要对数据库优化，建联合索引的时候，你会发现你要给无代码开发者解释更多的概念，还不如让他一开始系统地学习 SQL 知识。

关于哪些技术难题需要学术界和工业界共同探索：

其实考察 SQL 这门古老的语言可以获得很多借鉴意义。

SQL 其实是一个很成功的低代码实例。SQL 诞生之前，人们要管理维护数据，需要编码实现各种数据结构、排序算法，还要考虑内存限制，跟磁道寻址打交道等等，其繁琐程度可以想象。有了 SQL 之后，直接可以使用 SELECT/INSERT/UPDATE/DELETE 这种非常贴近自然语言的方式来完成对数据的管理。这种低代码演化之所以能成功，是因为它有一整套完备的实体关系模型和关系运算理论做支撑。这种完备性论证，正是目前市面上的低代码工具所缺少的，也是工业界亟需学术界给予支持的部分。

所以，一个建议是，学术界可以尝试在某些特定行业领域（比如供应链、工业组态、执行制造、电商、物联网）结合生产实际做相关研究，必要时，甚至直接去现场考察实习，然后把掌握的领域知识利用形式化武器，做一些抽象和逻辑推演，最后得出 DSL 或相理论。然后，工业界基于这些 DSL 和理论成果去落地实现，加快该领域内上层应用的开发迭代的速度。

DMTF 组织

是一个很好的学术界和工业界相互合作的例子，产出了很多领域的通用模型和协议，值的借鉴。

以上只是摘录部分，完整访谈实录见：https://mp.weixin.qq.com/s/Wdzwyv70AlmGore0jdaXrw