低代码的核心问题：其实是方法论的问题！

在一条错误的方向上努力越多，浪费越大！有时候是没有办法，基于当时的认知和技术，以及硬件环境，只能做当时的事情，这个可以理解，但是如果技术等各方面条件具备，还一大帮子人往错误的方向上努力，这就是一个问题了！就像现在应该没有企业再投入燃油汽车的研发，都搞新能源了一样。但是“低代码”似乎是一个例外，眼看着无数产品都在错误的路线上越走越远～～～特别是在国内这种“一窝蜂”的大环境下，是对资源的极大浪费！

我来具体分析一下方法论出了什么问题：

                                低代码产品分类底层逻辑

把不同阶段的产品放在同一阶段中

（仔细看上面图）原本企业内部应用有三个阶段：

（开发态：研发阶段）-->（运行态A：配置管理阶段）-->（运行态B：使用阶段）

由于产品设计、技术等各种原因（我觉得主要是被Mendix/Outsystems等国外产品带偏了），将本应放在不同阶段的产品都“挤”在了同一状态里面（iVX除外）。无论产品是挤在“开发态”还是“运行态A”里面，用户用起来都会“拧巴”。

从技术上讲：开发态和运行态A的核心区别是“开发态是可以生成代码的”，只是一些技术架构上的原因导致无法生成完整代码。

把不同类型的用户（属性和背景完全不同）放在同一套产品中

（上图）从上图也可以轻松看出这一点。由于“程序员”和“业务人员”本质上是两个物种，因此根本无法通过产品来调和，背景知识和职业技能也完全不同。

那到底是“有代码”还是“无代码”呢？最后折中一下，弄了个“低代码”的概念出来。其实这个低代码就是这么来的。

总结

现在低代码产品的核心问题：就是方法论的问题，多数就是底层的方案存在重大瑕疵，根本无法通过进一步的迭代来修正问题。因此，也希望新进的低代码平台研发者和架构师能够对这个问题足够重视，不要走老路，可以尝试探索一些新的方向。

虽然还不算完美，但是iVX总体来说走了一条新的“方法”路线，大家可以多研究研究，个人觉得比Mendix等传统技术路线有很大的优化。