“低代码/无代码”有致命缺陷，“可选择代码”才是王道！

低代码/无代码，这个概念真的好吗？

国内的风口，往往都追逐国外的“概念”。有些概念确实很先进，有些概念却只是技术发展过程中阶段性的产物，今天我们要说的“低代码/无代码”就是这样产物。

我一直都不太喜欢“低代码/无代码”的概念：

“低代码”太模糊，低到什么程度才叫“低”？低代码一定需要写代码吗？写代码的难度会降低吗？还是说难度上和正常写代码一样或者更难一些？——如果需要写代码，那么低代码的用户就必须是程序员了，那么是不是意味着程序员需要多学一套低代码的框架，才能在低代码平台上进行开发？如果是这样，学习低代码框架的成本会比实际开发是节省的时间更多吗？效率到底提升多少？

“无代码”太绝对，这种叫法，在一个公司的开发团队内部，肯定是不受待见的。“无代码”的话，说明这套系统本身是排斥代码的，那么以前辛辛苦苦积累的各种代码资源怎么办？而“无代码”本身的资源肯定是有限的，光这一点，就会阻碍无代码相关产品的发展。

低代码/无代码，技术上有哪些缺陷？

上面是概念上本身的问题，技术上也是很大的“自身”缺陷的。甚至，在我看来，之所以Mendix、Outsystems等传来“低代码”这种叫法，也是“程序逻辑无法完全通过图形来表达”之后的一种妥协的方案。

另外，其实低代码产品，在国外一直也是不温不火，其技术架构上也是有一些“顽疾”的，而且很难去除。这里面主要有三大问题（我在一些文章里面提到过，这里就简单说一下）：

三大缺陷之一：无法完整导出代码（避免平台“锁定”）

低代码平台有上百个，而平台本身不会有标准，要标准，就只有“导出代码”一途，只有“编程语言”，特别是已经被绝大多数企业接受的语言和框架，可以作为标准。如果不支持导出代码，意味着所有开发的东西“以后无法出来”！对于一个企业的研发安全将是一个挑战。

其实，能够导出代码也是一些低代码开发平台一直追求的，例如Mendix Outsystems CodeWave等，这些已经做的很好了，但是还是无法完全导出前后台代码，或者有一些需要安装一些特殊的运行时环境。各种原因吧，一些是底层技术依赖，例如工作流或者权限管理等开源产品，一些是出于商业上的考虑。总之基本上都不能完整导出代码。

三大缺陷之二：开发能力本身受限（前后台功能欠缺）

声明一下，这里的能力受限是指“不写代码”的情况下，能力受限（因为代码啥都能做，但是和低代码平台本身能力就无关）。

例如前端只能做很简单的页面的拼接，后台复杂的功能也需要写代码。这里面原因也有很多种：例如很多平台使用简单的“页面设计器”，功能受到很大限制；有些在后台能力上做了很大阉割；更重要的没有一个“图灵完备”的逻辑可视化表达方案。

三大缺陷之三：开发效率受限（开发有些时候比写代码还慢）

这里面主要还是没有IDE统一的开发环境，产品和技术都有很大关系。特别是产品因素，有时候看上去一个平台好像这个功能也有，那个功能也有，但是操作起来非常分散和麻烦，很多弹窗，导致开发效率大跌；有时候这个地方可以控制逻辑，那个地方也可以控制逻辑，导致最终逻辑混乱。还有一些技术造成的，例如预览一次要好几分钟等。

“可选代码”才是王道，而且已经存世，且免费（ivx.cn）

什么是“可选代码”？

简单来说就是：现有的各种代码资源都可以导入，并快速在图形化界面使用；在图形化IDE里面开发完成后，又可以以各种代码资源的形式导出。你不使用代码，什么都可以做！而如果你想用代码的时候，各种代码资源都轻松使用。这种随心所欲的状态，才是“可选代码”！国内的图形化编程IDE iVX应该基本已经做到了，值得表扬👍😆

这里面有很多技术难点，其中，我认为最重要的就是“面向组件编程”和“可视化逻辑编辑面板”。其中“面向组件编程”，可以很好的“融合以及隔离”代码，而逻辑表达，则是所有编辑操作的基础，不仅要“图灵完备”还要“快”。

“可选代码”本质上已经跨入了“图形化编程语言”的领域，但又确实涵盖了“低代码/无代码”相关的概念范畴，因此我认为是“低代码/无代码”最终方向。