低代码无法走出的困境——低代码平台的三大悖论！

【iVX不在这个讨论之列，iVX生成完整代码，应归入“图形化编程语言”大类。】

低代码平台架构的三大悖论之一：为“企业服务”量身定制，但又“平台锁定”！

几乎所有的低代码平台，包括低代码概念的提出者“
Mendix/Outsystems/Appian/Power Apps...”几乎都存在“平台锁定”的现象。而且这种“锁定”机制有一点像当年的Oracle，是“不断积累”的锁定（不像SaaS产品切换起来相对比较容易），低代码平台由于需要把研发资源不停在平台上积累，所以一旦大规模投入之后，由于无法生成源代码（或无法生成完整源代码），企业就很难脱离平台，这就是所谓的平台锁定。

这也是这么多年“低代码”很难快速发展的核心“阻碍”，没有企业愿意重蹈覆辙，让当年的“Oracle模式”再次上演。只要企业还能生存下去，可持续的安全还是企业的“Priority One”。

低代码平台架构的三大悖论之二：把“开发者”和“业务人员”放在同一产品中！

从产品角度来讲，“开发者”和“业务人员”压根儿就是属性和背景知识完全不同的两波人，甚至“思维模式”可能都是完全冲突的。低代码平台由于“产品设计”上的问题，不得不做成“一个平台”，然后忽悠出了“Citizen Developer”的概念。最终的结果就是搞的“研发的同学使用起来非常不方便”而“业务的同学完全看不懂和学不会”，两边都不讨好！

其实，在我看来，把不同的人员拉到同一个平台，实则“无奈之举”，没有想出更好解决方案的“权宜之计”。所以低代码平台在企业内部，两边得不到待见，推行起来自然也就阻力重重了。

低代码平台架构的三大悖论之三：“简单应用”没必要，“复杂应用”比写代码慢！

如果是简单应用，那么“SaaS”就已经很好使了，没有必要引入“低代码”（之所以叫低代码，就是开发过程中还是很难避免“代码”的）。那么用“低代码”来开发复杂应用呢？对于很多平台来说，由于很多原因，其实很可能比使用代码开发还要慢！

原因大体有那么几种：

（一）需要使用很多工具或引擎，没有完整的开发IDE。

操作繁琐，步骤和窗口太多，功能分散，导致虽然有一些代码省下来，但是整体操作次数和操作时间并没有缩短。

（二）“画流程图”来表达逻辑，过于复杂。

不知到从哪一家低代码开始，大家都喜欢通过“画图”的方式来表达“程序逻辑”，而画图的方式往往带来的直接解决就是“很慢”！（我知道要去掉代码，必须使用“图形化”的方式来表达逻辑，但是“图形化”不只有“画图”，我倾向iVX鼠标+面板的模式，明显效率会高很多。感觉大家都被“流程图”带偏了。）

（三）组件太少或组件的抽象和封装还没有做好。（这个就不细说了）