“低代码”平台的致命缺陷?我发现了

为什么我认为开源的低代码平台也不是企业最佳选择?

我先总结一下,大部分低代码的特征:

1. 为企业定制的一种内部开发框架,运行时的,整体安装到企业内部,属于企业服务;(还有一种纯SaaS的,国内更难推,不在这里讨论)
2. 大部分应用,还是需要代码开发,只是说代码量可能会少一点;但是,开发出来的应用,终身只能在"运行时"环境下运行,不能导出独立部署;

为什么程序员和技术管理者不太可能接受"低代码"平台?

1. 不安全(锁定特性)

大部分"低代码"平台实际上是一个为企业定制的"产品",而不是"一种新技术"!更像是一个"空中楼阁",只能进不能出那种。

由于无法生成代码,因此一旦选择某一"低代码平台",基本上等于把身家性命都押上了,一旦"平台有事",基本上会"颗粒无收",甚至影响现有的运行业务。国内,有上百家类似的低代码平台,基本上都是同质竞争,因此风险极高。因此,我认为技术管理者不敢使用。

2. 不信任

程序员只相信"代码",哪怕是自动生成的代码,也是可以接受的。如果不能生成代码,这将和程序员基本"认知"相冲突,并且这也将阻碍程序员去进一步参与建设"低代码"平台。在程序员眼中"不能生成完整代码"、"不能导出进行编译/调试/运行"的系统是不能被接受的。

3. 不完备

现在绝大部分低代码平台,实际开发能力还很"弱",简单说就是做不了什么。有些看上去啥都有,但是整个系统缺乏设计,一盘散沙。如果不经过长时间的打磨,很难产生提升生产力的价值。

再谈谈为什么我也不看好开源的低代码平台?

现在的低代码平台,本身的缺点是很明显的(平台锁定+程序员抵制),将这种模式开源之后,再在企业内部迭代,其实意义不大,很容易就让一个企业掉进一个"死胡同"里,"低代码"本身模式的缺陷,不太可能因为企业内部的迭代而根本改变。

开源低代码平台,看起来挺美好,在我看来也是巨大的坑,主要基于以下两点:

1. 调整一套生成应用的框架,太复杂

通过代码调整一个生成应用的框架对于"企业"来说,还是太复杂了。因此,这几乎成为了"开源低代码"的商业模式,帮助企业去定制。

但是,企业本身需要的"快速生成业务和应用的系统",这相当于是让企业去二次开发"VisualStudio"😂,这个对于一般企业来说,"不具备可行性"。

2. 产品迭代是个大问题

企业需要的产品,时间上并不允许投入太多在"开发平台"的开发上。另一方面,很多企业都是边开发,并投产,也就是说"一边使用平台,一边二次开发平台",这样的结果就是"前面的应用"很可能完全无法维护。一旦,很多团队都是"头脑一热",就上了一个新平台,可是如果后期平台调整产品迭代,会导致前期开发的成果全部作废,这也是一个非常大的损失。

3. 开源平台多数bug比较多,且暗藏玄机

(不细说了...)

因此,我认为,未来技术的发展方向一定是"能生成代码"的低代码/无代码平台,能够和现有代码体系无缝结合的平台,能够被程序员接受的平台。

欢迎大家发表意见。

相关推荐
devmoon1 小时前
在 Polkadot 上部署独立区块链Paseo 测试网实战部署指南
开发语言·安全·区块链·polkadot·erc-20·测试网·独立链
成茂峰1 小时前
软考高级·系统架构设计师 | 四、信息技术安全知识
安全·信息安全·系统架构·架构设计师
向哆哆1 小时前
CANN生态安全保障:cann-security-module技术解读
人工智能·安全·cann
不爱学英文的码字机器2 小时前
解读CANN MindX SDK仓库:AIGC应用开发的“低代码加速器“
低代码·aigc
wuli_滔滔2 小时前
CANN安全机制源码探秘 仓库中的权限校验与数据加密实现
安全·cann
liann1193 小时前
3.1_网络——基础
网络·安全·web安全·http·网络安全
独行soc3 小时前
2026年渗透测试面试题总结-17(题目+回答)
android·网络·安全·web安全·渗透测试·安全狮
小羊不会打字3 小时前
CANN 生态中的模型安全加固:`secure-model-deploy` 项目实践指南
安全·neo4j
独行soc3 小时前
2026年渗透测试面试题总结-18(题目+回答)
android·网络·安全·web安全·渗透测试·安全狮
HUIBUR科技5 小时前
低代码赋能供应商管理:打破管理壁垒,重塑供应链效能
低代码·数字化转型