低代码平台扫坑,如何避免业务应用系统未来的龟爬?

性能问题是很多业务应用软件的常见现象,前期看不出来,随着数据量的增长常常出现性能呈指数级下降而变成蜗牛系统。

借助于低代码开发平台可以快速构建应用系统,但是往往内部实现方法和过程对用户是黑盒,能否确保后期系统可以持续稳定运行?是否存在程序执行效率降低的问题,以致于前期贪便宜入坑,后期需要不断砸钱填坑?这是个需要研究的问题。

产生性能问题的源头总体上可以分两部分:1、基础平台性能,2、业务功能执行性能。

所有越高级的编程语言相对于低级的语言都会带来执行效率的下降,所以现在软件对硬件的要求越来越高。低代码开发平台也同样存在这方面的问题,由于内部需要进行一些解释执行的过程,肯定不如传统编译的软件跑的快,就像同样的功能java肯定跑不过c语言,但是这种损失是一个定值,相对于开发效率的提升完全可以忽略不计。另外,平台型的系统基础功能,代码会比一般程序员编程质量要高,基础功能部分执行效率会比程序员自己手写开发的高,所以一般这方面不会有什么问题。

真正影响较大的是业务功能实现方法的优化,一个算法的优化可能带来执行效率的万倍提升。现在很多低代码平台是无代码方式(这类系统优缺点以后专题作剖析),自带业务功能实现。总体来说,封装度越高的越难保证性能,这种系统是把业务逻辑代码和系统技术代码事先做成了标准件固化在一起,可以简化开发,但是往往做不了灵活度要求高的复杂应用,外界也不能进行干预和调整优化;对于低代码开发类的平台开放性越高的越可以由用户自由掌控,这种机制是将技术代码和业务代码做剥离,系统将确定性的技术代码自行做优化处理,肯定比大多数程序员手工开发的程序质量高,而不确定性的业务代码可以做默认实现也可以交由用户干预自行开发,随着数据增长,用户可充分介入不断地跟踪优化,既可兼顾开发效率又可兼顾执行效率和复杂的业务逻辑深度定制。

所以,经研究决定,本人现在开发的开发软件的平台采用后者的方案,不能做深度业务定制开发的平台不是真正的开发平台,不能确保可持续可靠服务的系统不是负责任的系统。

不解释

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2022年4月12日
下一篇 2022年4月12日

相关推荐