低代码是领域特定语言还是通用语言？和Thoughtworks《聊聊低代码》

前天，知名外包公司Thoughtworks针对低代码发表了一篇《聊聊低代码》，从VB等“托拉拽”技术的覆灭开始讲起，将低代码定义为一种领域特定语言，代表程序员关上了低代码的大门。

从文章中我读到了知乎上非常流行的味道，即互联网==软件，一个技术用来开发大数据量、高用户体验的互联网服务时不好用，那么他就干啥啥不行了。作为一名入行十几年，一直在使用Visual Studio+.NET+WinForm/WPF，“托拉拽”搞企业软件开发的老程序员，我也有几句话说。

托拉拽已死？

Thoughtworks：就例如大家最熟悉的VB（Visual
Basic），现在回头来看不就是一个典型的试图通过组件的托拉拽加少量代码的方式实现应用的快速构建的“低代码平台”么？而又怎么会渐出了历史舞台？难道只是简单的CS架构问题么？话说想想BS架构下类似的工具也有不少，最后也都难逃同样的命运……
这句话的潜台词是“VB/WinForm/WPF/Silverlight等可视化界面设计方案都失败了，所以这条路行不通”。我认为，这句话得加一个限定，即“互联网领域”。

这些技术在toC端确实已经不再流行，但是toB领域依然是主流。用友U8 CS门户就是用WinForm做的，U8 BS门户基于Silverlight开发的，今天依然是用户最多的ERP软件；.NET和.NET Compact+WinForm做的各类数采和执行控制软件依然是工厂生产线的主力。为什么？因为可视化技术的本质是代码自动生成技术，也就是将用户托拉拽的行为翻译成代码（不只是C#、Java这种可执行代码，更常见的是XML和Json等描述性语言）。相比于手工优化后的代码，可视化技术自动生成的代码在性能上确实有一定的差距。在性能要求高的互联网领域，这种方案确实遭遇了很大的挑战；但是，在硬件性能趋于过剩的企业服务器领域，这种性能损失完全可以接受。

所以，在企业服务领域，可视化界面设计方案并没有失败，只是技术平台的升级，让那些为Windows桌面程序、Silverlight插件设计的可视化开发方案显得落后罢了。进入Web+多终端时代，企业服务领域需要的是新一代可视化技术，从产出Windows桌面程序，切换到产出纯H5的Web应用，而不是彻底退回到和互联网一样的纯手工编码。

低代码和可视化并不能提升效率？

Thoughtworks：这种平台往往Demo看起来非常的酷炫和有冲击力，但是一旦真正应用到实际工作过程中就会出现各种问题：开发效率不升反降，平台学习成本高，程序员学习动力不强，功能受限，感觉束手束脚，调试难测试更难，数据不开放，平台与工具绑定，性能问题等等……

即便有脚手架（类似ASP.NET MVC）写代码的开发和维护投入也比托拉拽要高很多，因为开发环节中，除了敲下代码，还需要涉及内部Review、自测、自查、调试以及接手他人代码的学习过程，可视化在这些领域都能体现出更强的效率优势。具体到可视化带来的影响，我的经验是.NET WinForm的界面构建速度比VC++大约高2-3倍；客户反馈用低代码做后端WebAPI比Spring Boot快2-3倍，前端快1-2倍的样子。当然我接触的项目都是企业软件，业务逻辑和数据处理复杂度高，性能和界面精细度要求低。

低代码基于特定领域语言？

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

在讨论DSL的可视化带来的各种限制之前，按照知乎惯例，我们得先问“低代码是不是基于DSL”。

我认为，低代码，尤其是模型驱动的低代码平台，本质是高级语言的可视化方案，而不是发明了另一种面向特定领域的语言。比如outsystems的process、mendix的microflow、活字格的命令，本质上都是在前端或后端执行的function，在前端表现为mvvm中的command，后端表现为webapi。在这里面，可视化的操作元素对应的是C#、JS的语句，并不是发明了一个新的语言，在抽象程度上没有本质差异，不过考虑到研发成本投入和市场定位，目前在功能实现上优先覆盖企业软件中涉及到的应用场景，如语言层面的输出输出参数、流程控制（顺序、选择、循环）、异常处理、调用、返回等，以及应用底层的数据访问（CRUD）、事务控制、日志，和更高层次的文件操作、WebAPI/RFC/Modbus调用等。

这就意味着，至少在企业服务这个大的领域中，低代码的约束性和应用场景和高级语言开发一致。具体而言，后端不存在写代码可以实现，而低代码的可视化无法实现的业务功能。在前端，低代码开发平台的前端设计能力和编码开发确实存在一定差距，即便是行业top的outsystems，也有一些交互的限制。不过，企业软件重后端轻前端的特点，让这些问题在后端开发的高效率面前，都变得可以妥协。

开发工具的生产力没有差异？

Thoughtworks：低代码平台的工具部分，往往最大的价值并不是提高程序员的效率，反而是为了实现对于业务人员的自助（Self-Service）服务平台。

从低代码概念的提出者Forrester到对低代码进行细分的Gartner，行业主流研究机构都将专业开发者视作低代码技术的主要用户群体。Forrester在低代码的相关报告中，将“面向专业开发者的低代码平台”作为重要分类；Gartner在低代码的定义中明确指出仅提供给业务人员使用，而无法提供给专业开发者使用的不能称之为低代码开发平台。

软件==互联网？

最后我想说，低代码技术的本质依然是软件开发技术，软件开发者无法忽视这个技术的存在。在追求极限性能、极致用户体验的互联网开发者看来，WinForm、Cordova、Blazor以及这回的低代码都无法满足开发者对最优化的追求。但是，我们也得看到，在面向企业服务的领域中，这些技术凭借着“节省开发成本”的一招鲜，压过了各自的不足和限制，正在大量的团队中服役。

软件开发没有银弹，互联网的砒霜也许就是企业软件的蜜糖。

所以，如果你从事的是企业软件开发，请一定认清咱们所在的这个行业与“互联网”的差异。当看到什么“35岁失业”、“低代码已死”等话题的时候，多琢磨琢磨。