低代码，到底靠谱不？（这四个才是真正的低代码平台）

最近一段时间，“低代码”概念特别流行，有的人特别推崇它，也有的人对此不屑一顾。

推崇它的人，认为它有很多优点，比如说能够降低开发周期，提高系统开发效率，降低开发成本，学习成本低等。并且认为它会成为一个未来的趋势。

而对其不屑一顾的人则认为，低代码貌似提高了效率，实则应用场景要求很苛刻，一旦需要低代码平台不能提供的功能，就要折腾好大一圈，甚至还可能完成不了需要的任务。就好像有的人说的，用普通代码花一周完成了100%的任务，而用低代码一个小时就完成了99%的任务。那么剩下的1%呢？答案是，没法完成。

那么，究竟低代码到底有意义吗？靠谱不？今天我们就来讨论一下这个问题。

首先我们来看现状，低代码的现状就是：概念很美好，实现很拉胯。

事实上，低代码的工具十几年前就有，比如说大名鼎鼎的Webmethods中就提供了一套图形化编程工具，基于Java的Flow语言，通过简单的图形化操作，就能够完成很多的任务。并且支持自己创建图形化模块，以及修改图形化模块中的代码。用起来是非常方便的。但是这套东西卖得挺贵，至今也没有特别流行起来，基本上也没有什么开源软件能够达到Webmethods工具包的效果。目前也就是像Scratch这类哄小孩的图形化编程工具比较流行。

而目前宣称能够大幅提高开发效率的各个低代码平台，实现都很一般，不仅实现的功能很简单，不适用于一些复杂场景。而且生成的产品也非常难以维护或者是修改其功能。

例如某款流行的低代码平台，创建表单的时候，可以很轻松地通过页面操作生成一张表单，而一张表单就会在后台生成一张表。而生成的表既不具有正常在设计数据库表结构时要考虑的表间关联关系，也很难从表的自动命名中看出其实际意义。这意味着如果想基于这种自动生成的表去进行复杂的查询功能开发，是非常困难的。

而类似于这种的问题还有很多。当然如果从产品的角度来讲，这些实际的问题是可以逐渐优化的。所以这些问题只是暂时的。

低代码最大的问题在于，一个项目的复杂度简化，是有限度的。而对于不同的开发人员来讲，所能接受的信息复杂度是不同的。

除去非常简单的应用以外，大部分项目的需要都是比较复杂且具有很多自定义功能的。这就意味着如果一款低代码平台如果想兼容所有的功能的话，那么势必要增加非常多的功能模块。那么对于开发人员来讲，与普通代码的区别可能就是，普通代码要记忆几百个函数或接口，而低代码要记忆一百多个模块及其属性和适用范围。而这个学习成本，和可能出现的潜在问题，其实是差不多的。

固然我们可以将很多代码模块化，事实上这本来也是大部分程序员在做的工作一样，开源的中央仓库里诸多可直接引用的库即是这一工作的成果，大部分时间，程序员们只需要知道哪些库能够完成自己的功能，并且阅读一下其使用手册就好了。

而如果把大部分功能组合起来，那么势必会导致很多过程对于开发者而言成了黑盒，从而在需要修改的时候无从下手。

而如果组合的功能不够，则开发者就需要学习更多的模块。这两者的本质是一样的。因此低代码的本质就决定了，它只适用于非专业人士，用一些通用的模块化功能来完成自己的简单需求。而对于专业人士来讲，需要学习和了解的，则远远超出了低代码平台所能提供的功能。

当然，如果低代码平台真正流行起来之后，很可能会出现介于两者中间的半吊子程序员。

这就好比是所有的手机品牌都在那里，各种配置甚至各个部件的厂商、参数信息都能很清楚的拿到。

但是对于大部分人来说，可能完全无法分辨，两个1599的不同品牌手机，技术上来说，到底哪个好。所以经常会咨询一些似乎很懂，但实际又不很懂的半吊子专家。最终随便买一个专家推荐的品牌型号。

这种事情我们也会在选购电脑和买车的时候常见。

低代码平台普及之后，想必开发程序的时候，也就会出现大批的这类专家了。

喜欢本文的话，欢迎关注活在信息时代哦：）