（注：本文最早发布于2020年5月份，当时低代码平台已经在行业中被热议，如今热度不减，文中的思考也仍然适用）

最近在很多场合听到大家在谈论“低代码平台”这个概念，尤其是其概念在投资和收购市场上的火爆，吸引了很多人的关注和目光。

一时“人人都是程序员”，“不会写程序也可以快速开发应用”的声音四起，很多人都开始思考这是不是软件开发行业的未来。

今天就聊聊我的想法和观点。

低代码平台，是通向美好生活之路还是托拉拽重现江湖

低代码开发平台是一种aPaaS（Application Platform as a Service），它是仅需少量编码甚至无需编码 (0代码) 即可快速通过可视化拖拽 (drag & drop) 的方式完成应用程序开发的平台。该名词最早于2014年6月由Forrester Research最先提出。

低代码开发平台通常具备以下特点：

• 可视化集成开发环境（Visual IDE）;
• 大量可重用且支持拖拽的组件（drag & drop）
• 等等

如果你对这个概念还不太理解，可以想想一下《钢铁侠》中钢铁侠在自己的全息工作台上摆弄设计各种钢铁侠的场景……（虽然目前的低代码平台还没这么酷炫，但是大概的意思差不多）。

如果觉得这个例子太过科幻，其实我们身边随手都能看到类似的工具和平台，比如，Mac系统中的Automator或是iOS中的快捷指令（原来叫做workflow），亦或是前几年火过一阵的ifttt……

当你第一次接触到类似的平台，相信一定会眼前一亮：软件还能这么做？！我们现在这一行行攒代码的方式太low了？！这难道才是软件行业的未来？！

但当你压抑不住激动的心情，跑到那些老程序员面前，眉飞色舞的介绍这个你认为即将要改变软件行业未来的新趋势时，老程序员可能连正眼都不瞧你一眼，顶多从嘴角再吐出几个字：“哎……又是托拉拽…… ”

要知道，“托拉拽”这三字，在老程序员的心中，可能并不是一段美好的记忆……

日光之下并无新事，只有你不曾经历的历史

其实低代码平台不是最近才出现的概念（像很多其他的所谓的新概念一样），Thoughtworks的技术雷达早在两年前2018年的11月份那期，就已经提到了Low-code platforms，不过遗憾的是，它并不是作为新技术的推荐，反而是被放到了Hold（暂缓，谨慎使用）的象限里。

翻译成中文就是：

低代码平台使用图形用户界面和配置来创建应用程序。 可惜的是，推广低代码平台推荐的这种开发应用的方式意味着你不再需要熟练的开发团队。这样的建议忽略了以下事实：”编写代码只是创建高质量软件所需的一小部分，而诸如源代码控制，测试和精心设计解决方案之类的实践同样重要”。 尽管这些平台有其用途，但我们还是建议谨慎使用它们，尤其是当它们带有降低成本和提高生产率的奢侈主张时。

我个人也在10多年前，就有过使用类似号称可以“托拉拽”快速实现应用开发的工具平台（当时还叫做SOA平台，但是仔细看了一下和现在大家谈论的“低代码平台”我觉得没什么不同）开发应用的经验，当时的惨痛经验让我现在还记忆犹新……

就像是上文技术雷达提到的一样，这种平台往往Demo看起来非常的酷炫和有冲击力，但是一旦真正应用到实际工作过程中就会出现各种问题：开发效率不升反降，平台学习成本高，程序员学习动力不强，功能受限，感觉束手束脚，调试难测试更难，数据不开放，平台与工具绑定，性能问题等等……挣扎了一段时间，最后还是放弃了，重新回到了原来的开发方式上。

类似的平台其实还有很多很多，别的不提，就例如大家最熟悉的VB（Visual Basic），现在回头来看不就是一个典型的试图通过组件的托拉拽加少量代码的方式实现应用的快速构建的“低代码平台”么？而又怎么会渐出了历史舞台？难道只是简单的CS架构问题么？话说想想BS架构下类似的工具也有不少，最后也都难逃同样的命运……

从另一个角度看，如果低代码平台那么厉害，为什么那么多互联网公司还在持续招聘那么多的程序员，没日没夜的写着最基本的代码开发软件，为什么不大量的使用低代码平台来快速构建自己的应用呢？（对于互联网企业，还有一点非常重要，就是非常注重核心系统的自研可控，以及对于数据的百分之百管理，这也是现在越来越多非互联网企业开始关注的）。

换一个角度，客观来看，其实“托拉拽”也不是没有成功场景，例如在常见的工作流设计（BPM）和最常见的办公自动化（OA）场景下，很多场景都是通过“自定义表单 基于托拉拽的流程编排”来实现的，在过去一段时间也很好的满足了一些场景需求。

而在软件开发领域，我们熟悉的UML 设计器 MDD（Model driven development）也曾红极一时，虽然最后MDD虽然没有得到大范围的应用，但是基于UML的托拉拽方式对于软件进行设计，还是延续至今。

还有一个我们更熟悉的场景，SQL其实也算是一个最常见的“低代码平台”的成功应用场景，如果把“SQL”看成一个“编程语言”（本质上就是），那我们在用各种数据库设计工具对于数据库进行设计，并最终由工具自动转化为“SQL”在数据库中执行的过程，其实就是一个理想“低代码平台”运作的过程。（想象一下没有类似的工具平台，全部SQL需要手写的酸爽滋味）。

嘿！你这一会儿说低代码平台不靠谱，一会儿又说还是有成功场景的，话都叫你说了，到底你要怎样！（拔刀）

少侠先冷静先冷静，待我为你拨云见日，其中玄妙娓娓道来……

不吹不黑，客观洞察低代码平台的本质

如果想搞清楚，低代码平台的应用场景和价值，一定要“透过现象看本质”，思考一下低代码平台在酷炫的界面，眼花缭乱的功能背后，其本质到底是什么？

废话不多说，直接给结论：

低代码平台 = 领域特定语言（DSL） 语言解释器（Interpreter）

其实我们大多数人对于低代码平台搞不清楚，根本上是因为关注点错了，我们将太多的关注点放到了各种酷炫的“托拉拽”的工具上面（虽然很有冲击力，尤其是对非程序员），也就是语言解释器（Interpreter）部分，而恰恰忽略了其最重要的也是关乎于威力以及成败的领域特定语言（DSL）部分。

可能这里的领域特定语言（英语：domain-specific language、DSL，后文简称为“语言”）大家会感到一些陌生，其指的是专注于某个应用程序领域的计算机语言，又译作领域专用语言。值得骄傲的是，我司的“老马”，Martin Fowler出过一本同名著作，也是DSL领域的丰碑之作。

说回来，其实也没那么复杂，我们常说：“语言的边界就是思想的边界” ，而领域特定语言（DSL），简单理解就算是我们在面对某一个特定领域形成的语言（有时候也成为元模型），例如我们上边提到的例子里：

• 我们操作数据库用到的SQL，其实全名就是Structured Query Language（结构化查询语言）本质上就是面对关系数据库系统的一种DSL，而各种SQL设计器，其实就是这门语言的设计器和解释器而已。
• 我们在处理工作流时，其背后也有一套语言，例如常见的BPML（Business Process Modeling Language ，业务流程建模语言），我们看到的各种酷炫的流程设计编排工具和平台，无非也就是这门语言的设计器和解释器而已。
• 我们在设计软件系统时，背后用的UML，全名叫Unified Modeling Language（统一建模语言），而无论是各种UML设计工具还是MDD（模型驱动开发方法），也都是这门语言的设计器和解释器而已。
• 类似的例子还有很多……

所以一个低代码平台的关键成败，作为解释器（Interpreter）的花里胡哨的工具其实并不是关键；低代码平台关注解决的问题领域（软件开发，软件设计，应用开发、数据库操作、系统集成、中台能力组合编排…），以及是否能通过“抽象”和“约束”为这个领域设计出一套好的DSL（或是元模型），才是关键，也直接关乎平台的成败。

以史为鉴，为什么有些低代码平台会大放异彩，而有些则退出舞台

讲到这里，有一个问题一直悬而未决，为什么像VB这样的低代码平台会渐出历史，而像SQL、工作流引擎这样的低代码平台则会持续焕发生命力呢？

这个问题很关键，因为想清楚了这个问题，对于帮助我们判断现在百花齐放的各种低代码平台是否靠谱，能否成功有非常大的借鉴价值。

其实这个问题也不难解释，因为上面我们已经提到，一个低代码平台的关键在于其关注的问题领域以及是否能为这个领域设计一套好的DSL，所以我们看待一个低代码平台，就只需要关注：

1. 它所关注的领域到底是什么？
2. 以及这个领域是否能抽象出一套通用的DSL（元模型）出来。

DSL关注的领域越“特定”，例如只关注在流程设计，或是只关注在关系数据库查询某个具体领域上，DSL的设计复杂度越低，反而语言的设计和包装而成的低代码平台越容易发挥威力，获得成功，大幅提升其实所在领域的效率。

反之，DSL关注的领域越“通用”（极致就是通用编程语言，例如C），越想覆盖尽量多的领域场景，就会导致“语言”的设计复杂度越高，低代码平台的设计和应用难度越大，失败的概率也会越大（想想给C语言设计一个托拉拽的LowCode平台的难度…）。

这也很容易理解，这就像是给“中文”写一个解释器的难度和失败概率，要比给一个行业黑话（可能就几十个词）写一个解释器的难度和失败概率大得多一样。

其实DSL中的S就是特定（Specific ）的意思，这个名字本身就已经把答案早就告诉了我们，只有关注特定的领域（Specific Domain）的领域特定语言（domain-specific language）往往才能发挥出更强大的威力！

那么，低代码是否会替代或颠覆传统的软件开发方式呢？

想清楚了低代码平台的本质，我们就知道其实本质上并不存在什么高代码平台低代码平台之分，我们在用低代码平台“托拉拽”，和在IDE里敲代码本质上是一样的，都是在用一个“工具”通过一套“语言”在描述和表达一类“业务”而已。

而区别只在于“语言”的“抽象层次”。

语言越接近于机器底层，对于”语言”的约束越少，IDE能帮我们做的事情越少，我们就得写更多的代码，但是好处就是语言的通用性越强灵活性也越高，什么领域的问题都能描述（想想汇编或C）。

语言越接近于业务场景层，对于”语言”的约束越高，IDE能帮我们做的事情越多，我们就可以少写些代码（极致就是no-code），但坏处就是语言的通用性差灵活性降低，只能描述某个特定的领域的问题（想想SQL）。

所以“低代码平台的兴起”所代表的“语言”通过聚焦于一个特定领域从而进一步逼近业务的趋势，就像是“中台的兴起”所代表的“平台”通过聚焦于一个特定领域从而进一步逼近业务的趋势一样（原谅我），都是大势所趋。但由于存在效率与通用性的博弈，所以这个过程注定只能算是对于编程语言在特定领域的不断再抽象和细化过程，并不会完全替代过去的软件开发方式（就像虽然行业黑话确实能在特定行业内提升沟通效率，但行业黑话最终也无法替换中文一样）。

总结

最后，再总结一下我的观点：

• 低代码平台的选择，关键不看工具（语言设计解释器）设计的多漂亮，而是要看其专注的问题领域及范围（个人推荐越专注越好），以及对这个领域的建模和DSL（元模型）设计能力。
• 如果是自建低代码平台，除了对于领域建模的工作必须要做意外，可以再衡量一下再做一个低代码平台的工具（托拉拽）部分的价值。往往有了良好设计和建模后，大部分时候写代码的效率不比托拉拽的效率低，而且还有完整的软件工程实践（代码脚手架、版本控制、测试、CICD…）支撑。
• 而制作一个低代码平台的工具部分，往往最大的价值并不是提高程序员的效率，反而是为了实现对于业务人员的自助（Self-Service）服务平台。
• 如果是选择第三方低代码平台（产品），在权衡其关注领域，模型和语言设计，以及工具设计用户体验之外，还需要考量其平台绑定、数据开放性、可维护性、可测试性、性能标准、学习成本以及未来的向自建平台的迁移成本等指标，个人建议最好只作为过渡产品或是应用于非企业核心领域。

文/Thoughtworks王健

原文链接：https://insights.thoughtworks.cn/low-code-platform/

更多精彩洞见，请关注微信公众号Thoughtworks洞见。