还有戏没戏？低代码的天坑与对策！

国内低代码基本上分为“三种技术流派”：

一、aPaaS，可以对外部署的“运行时”系统：

（绝大多数都是这一类，包括Mendix那些...）

多数模块都是已经成型，并做好了的，有一点像一个SaaS的合集（区别是可以对外部署），自带用户和权限管理模块；提供接口供外部程序调用，不能生成代码（可以导出部署那种代码），其自身能力和模块（特定模型）设计有很大关系，通常称为“模型驱动”，并解决“领域内应用”的快速开发问题。

二、代码生成型系统：

（好像就两家，iVX和CodeWave）

有自己的“内部编程语言”，并做了语言之间的生成和转换，做了编辑器/解释器/转换器等来完成这一步。

“图形化编程”---> “内部编程语言” ---> “高级语言JS/Java”

这类平台，已经具备编程语言的属性，功能的完备性会更胜一筹。如果组件设计灵活，IDE整合充分，可以带来编程效率的大幅提升，并且可以支持几乎所有场景和系统的开发。

三、aPaaS，“运行时”但不对外部署：

这类系统也有一些，感觉上就和SaaS没有什么区别，可能在使用场景上更加丰富，另外支持多租户管理。当然越是成熟和固定的系统，其灵活性就越差，但是对已经开发好的功能使用起来通常会更容易和简单。

低代码平台“两大天坑”：（主要指第一类aPaaS运行时低代码）

天坑之一：无法做到“零背景知识”，还需要代码背景

其实，这也是“低代码”这个叫法的来源，也是“低代码”悖论的核心所在，需要背景知识其实和现在使用高级语言的程序员是一样的，甚至能力上也并没有更低要求。

这个的最大阻碍来自“新进者”，也就是新的开发者，由于学习周期和现有程序员几乎一样，甚至还要多学一个低代码平台的框架，以致“学习成本”太高，自身的收益又有限（如果只是加快了某些场景下系统的开发效率），所以并不被新进开发者开好。这代表没有“生源”，这种aPaaS平台因此很难说有很好的前景。

天坑之二：行业无统一标准，无法导出代码，意味着“平台锁定”

前面说了，这类型平台对开发者来说，几乎看不到什么好处。接下来，我个人认为，对于aPaaS使用者“企业”来说，也是“弊大于利”的。

首先，低代码aPaaS平台不同于传统的SaaS平台，aPaaS低代码需要不停的研发投入的，而SaaS是“用完即走”，实在不行，还可以把SaaS相关数据下载下来，然后打包带走。

aPaaS并无实际上的行业标准（也不可能有），又不能导出代码，因此所有的研发沉淀，都被锁定到了平台内部，如果放弃使用，基本代表以前的投入就“打水漂”了。这里的下载代码，感觉就和SaaS应用可以下载数据一样重要，这算是一个保底需求。

另外，由于无法导出代码，因此以往的“研发管理形式”、“成熟的产品上线流程”、“代码管理”这些可能都要调整，其实是一个成本很高的过程。

对策及相对成熟的解决方案

光挖坑，不埋，那就是给大家徒增烦恼！所以，其实并不是没有解决方案，而且已经比较成熟。

其实上面提到的第二种类型“代码生成型”就是不错的解决方案，严格意义上，这种产品并不算是“低代码”（更像是图形化编程语言，但是也无所谓了，国内都这么叫了）。

推荐两个产品 iVX和网易的CodeWave，这两个是国内维二可用的“代码生成型”平台了。具体哪个好，我就不评价了，大家都可以去试一下，但是我可以把一些我认为合理的评价标准给列出来，大家自己去体验。

一、代码的生成能力：

（1）代码完整性：

子工具尽量少，这样可以生成全部代码；不然工具内部的代码有，而工具自身的代码肯定没有放进去，也就是说生成系统的完整性就会受到很大影响；代码是否可以单独编译运行？

（2）生成代码语言：

最好选用大家都通用的，例如前端JS，后台Java，如果还能支持那是更好，例如Python和Node等；

（3）代码可读性：

这个其实非常重要，不然如果有什么意外情况，代码还是无法修改；下面是某低代码平台自动生成后台Java代码截图（写得还是比较清楚，每个服务都单独封装，并有详细备注）。

二、IDE的整合能力：

简单来说就是：

一站式管理！（所有研发过程，最好都装在IDE里面，不用再跳出去，一切都搞定）

更少的点击！（例如最好不要有画图，画图其实是效率很低的操作类型，信息容量低，操作慢）

更少的窗口！（这些都是成本）

信息容量大！（最好逻辑表达等生成和表达代码的区域有更大的信息容量，留白少）

确定的控制！（例如控制逻辑最好一个地方，不好多个地方控制逻辑，很容易乱和错误）

三、实际开发效率

预览要等多久？

编译要等多久？

Debug要等多久？调试效率如何？

四、运行效率

这是一个核心参数了，但是我认为对于一般系统，其实这个参数没有那么敏感，不要有几倍以上的差距就好，几毫秒或20%以内的性能其实不是很敏感。

还有一个非常重要的点“是否实现了后台运行时资源和生成代码的解耦”！其实，运行起来，主要瓶颈都在数据库访问以及复杂的计算等地方，这些都是“云计算”解决的核心问题，我觉得“低代码”或说“图形化编程语言”没必要再把这些问题解决一遍（也搞不定），能使用好云计算来解决这些问题就足够了。因此我提倡“代码和运行时资源”解耦，这种方式成本低，效果好，只是不能满足后台研发人员“炫技”的需求。

低代码本身只是一个国外传过来的概念，核心还是看是否能够帮你解决问题？

如果你是初学者？看“是否可以快速学会？”，“学会了是否啥都能干？”，“能否挣到钱？”

如果你是公司老板？看“看是否可以提升效率？”，“成本是多少？”，“后期有什么风险？”

如果你就是程序员？看“生成代码质量？”，“代码运行效率？”，“代码可读性？”，“是否是发展方向”...

另外大家也不用一棍子打死，概念始终是概念，和做出来的产品有很大区别！有时候“概念有限制，产品上做了突破，远远超出了概念本身”；有时候“概念很好，产品做的垃圾，反而让大家对本身先进的概念产生误解”。

总之，多尝试新的技术和产品，跳出“固化思维和模式”，不一定会发现惊喜，但至少不会被时代抛弃。