低代码开发平台真的靠谱吗？

严肃讨论一下

低代码的愿景和现状：

本来低代码平台这个概念的推出，应该是个皆大欢喜的场面。既能给企业降本增效，又能让程序员专注业务逻辑，提升核心竞争能力，岂不是利好双方？相互进步？

但真正推到市场后，现在市场的表现如何呢？据 Gartner 统计，当前，国内 LCAP（低代码应用开发平台）渗透率尚不足 5%，尽管前期媒体不断造势国内低代码平台估值多少个亿，预期融资多少多少，怎么成为行业翘楚，但现在这一记的市场遇冷，就是得让吹嘘的声音小一点，让大家都能冷静一下，仔细想想现在的低代码碰到了什么问题，遇到了什么发展瓶颈。

低代码的现状：

低代码的优点是显而易见的，降低投入成本、提高研发效率、加快交付程序的速度等等，但是，这些都是理想状态下的。

现实的情况是，低代码平台本身是一个开发框架，能在平台上造出什么很大程度依赖于框架本身的能力。

在当前阶段，而大部分表单驱动型和基于 BPM 的核心框架做出的低代码平台，在程序员眼中无异于“玩具”——只能做最简单事情的那种，而且还不一定能做好。

第二个问题在于，低代码平台的能力有限，一旦个性化需求刚好不在框架能力范围内，二次开发实现成本、时间都不容小觑，万一企业选的低代码平台还不开放，开发的程序被“锁定”在低代码平台的运行环境中，那就更是寄人篱下，连自己开发的程序主动权都没有，一旦平台遇到阻碍或 bug 紧急运维，你的产品也只能干瞪眼，等着低代码平台自己的人员维修。

第三个问题在于，因为低代码平台本身就是一个内部逻辑未知的“黑盒”，问题排查也无从下手，万一遇到类似最近语雀的平台故障，导致数小时登陆不上又该如何？

救赎之道？

这几个问题，每一个都是重中之重，丝毫不敢怠慢，但总结下来都是最基础的技术问题，本文还没有讨论大部分开发人员和业务人员对新事物的抵抗和其他心里因素等。当然，碍于篇幅，本文只在此讨论低代码平台遇到的技术瓶颈和解决方法。

在我看来，解决以上的问题有且只有一个，那就是低代码平台本身必须具备“生成代码”的能力，且足够开放，不搞封闭生态。生成代码涉及到很多“尖端”技术，例如编译器/解释器的开发，AST 的开发等等，因此要想生成代码本来就不容易，生成具有可读性的代码就更难了。

在封闭生态这一点上，阿里就做了很好的表率，从基础组件、区块、模板等到各种钩子，物料的配置、约束和扩展基本上是统一了低代码的概念和生态，遗憾的是使用这套规则的人还是少数，大家都顾着跑马圈地，一个个地想要将用户围在自己的生态圈里，就连国外 OutSystems 和 Mendix 这种低代码大厂也不例外。

反倒是国内一些没有过度宣传，专注做技术的技术厂商，默默把这个问题攻克了。虽然国内有一些厂商能够生成部分内部模块代码或者打包一个内部环境格式的文件，但是绝大部分都不能“真正生成代码”，像编程语言那样生成代码，要具备“可读”、“可调试”的能力，体验上和手写代码没什么区别，包括维护的方式。

这方面只有国内的 iVX 平台，扎扎实实地把这个点子实现了，同时也不锁定，前端生成的代码可以直接在 VUE/react 中使用，后台可以直接导出 Java 和 Node 代码。

比较遗憾的是，知道这个平台的人还不怎么多，否则也不会有这么多低代码平台靠不靠谱的问题了。