低代码对比分析,从工程化上看产品的优劣(低代码项目)

低代码算是这几年在IT行业内越来越尖锐的讨论了,而且随着这两年大厂的大量裁员,更是亲者痛仇者快的事情,因为很多大厂发现把一些低端的研发岗位干掉了,反而整个体系在工具的辅助运转下,效率更高,执行力更优。

这里我不再深度交流这个对很对开发者很敏感的内容,今天我想从工程的角度聊聊低代码应该考虑的问题。

其实目前低代码有两大方向,一个以依赖于库表结构生成CRUD的“代码流”,一种是以动态创建数据模型 引擎渲染功能的“配置流”,两大方向各有优势,目前我对比了多家比较有代表性的产品,这里给大家做个总结。

  • “代码流”集成起来门槛低,找个代码生成器就可以快速的融合到自己的框架之中。
  • “配置流”使用门槛低,所见即所得,对技术人员的依赖度大大降低。

开发团队

模式

产品模式

授权尺度

宜搭

阿里

配置流

SaaS为主

使用授权

JVS

软开企服

配置流

私有化为主

使用授权 源码授权

jeeplus

代码流

私有化为主

源码授权

jeecg

国炬信息

代码流

私有化为主

使用授权 源码授权

jnpf

引迈信息

代码流

私有化为主

使用授权 源码授权

初看两者没有太大的差别,都是降低了开发成本,提升了研发效率,都是不错的思路。

今天我们从另外一个持续化的工程研发的角度来两者的差距与不同。

我相信大多数项目不是一蹴而就的(当然大多数小甲方外包项目逃不出这个魔怔,但是他们的初心肯定是想长期迭代的)。那么我们来看看整个对比过程。

“代码流”一期建设如下图:开发人员通过建库建表,然后生成CRUD代码(甚至部分业务代码),然后补充业务功能,然后发布上线。

低代码对比分析,从工程化上看产品的优劣(低代码项目)

“代码流”二期建设,如果对一期的建设需求有调整,那么低代码是很难再用上了,只有采用最原始的办法,写代码,优化代码。所以 这种模式的低代码比较偏向于第一期的新建, 后续的调整工作只有对之前生成的代码上去优化修改。

对于“配置流”的一期建设如下图:配置人员直接在整个体系内进行配置功能,形成了业务功能的基础配置数据,通过各个引擎将配置数据渲染成功能。

低代码对比分析,从工程化上看产品的优劣(低代码项目)

其实第一期的建设成本与“代码流”的差不多,都需要化交付时间。但是第二期建设就有很大的不同了,可以持续的节省成本。

“配置流”的二期交付:

1、复制生产环境的应用到开发环境(或者就在生产环境上生成一个副本应用)

2、对副本应用进行界面化编辑,实现历史功能的调整、新功能的新增,发布为应用的新版本

3、通过系统提供的工具,将历老应用的历史数据迁移到新应用之中

4、发布新应用,关闭老应用

低代码对比分析,从工程化上看产品的优劣(低代码项目)

从这个过程来看,在第一次建设时两者之间差不多,但持续迭代的过程中可以看出,“配置流”就会比“代码流”的方式在持续建设上要有优势,始终可以通过配置来降低开放工作量,从而达到节省人力成本的目的。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。