低代码对比分析，从工程化上看产品的优劣

低代码算是这几年在IT行业内越来越尖锐的讨论了，而且随着这两年大厂的大量裁员，更是亲者痛仇者快的事情，因为很多大厂发现把一些低端的研发岗位干掉了，反而整个体系在工具的辅助运转下，效率更高，执行力更优。
这里我不再深度交流这个对很对开发者很敏感的内容，今天我想从工程的角度聊聊低代码应该考虑的问题。
其实目前低代码有两大方向，一个以依赖于库表结构生成CRUD的“代码流”，一种是以动态创建数据模型+引擎渲染功能的“配置流”，两大方向各有优势，目前我对比了多家比较有代表性的产品，这里给大家做个总结。

• “代码流”集成起来门槛低，找个代码生成器就可以快速的融合到自己的框架之中。
• “配置流”使用门槛低，所见即所得，对技术人员的依赖度大大降低。
  
  初看两者没有太大的差别，都是降低了开发成本，提升了研发效率，都是不错的思路。
  今天我们从另外一个持续化的工程研发的角度来两者的差距与不同。
  我相信大多数项目不是一蹴而就的（当然大多数小甲方外包项目逃不出这个魔怔，但是他们的初心肯定是想长期迭代的）。那么我们来看看整个对比过程。
  “代码流”一期建设如下图：开发人员通过建库建表，然后生成CRUD代码（甚至部分业务代码），然后补充业务功能，然后发布上线。
  

“代码流”二期建设，如果对一期的建设需求有调整，那么低代码是很难再用上了，只有采用最原始的办法，写代码，优化代码。所以 这种模式的低代码比较偏向于第一期的新建， 后续的调整工作只有对之前生成的代码上去优化修改。
对于“配置流”的一期建设如下图：配置人员直接在整个体系内进行配置功能，形成了业务功能的基础配置数据，通过各个引擎将配置数据渲染成功能。

其实第一期的建设成本与“代码流”的差不多，都需要化交付时间。但是第二期建设就有很大的不同了，可以持续的节省成本。
“配置流”的二期交付：
1、复制生产环境的应用到开发环境（或者就在生产环境上生成一个副本应用）
2、对副本应用进行界面化编辑，实现历史功能的调整、新功能的新增，发布为应用的新版本
3、通过系统提供的工具，将历老应用的历史数据迁移到新应用之中4、发布新应用，关闭老应用

从这个过程来看，在第一次建设时两者之间差不多，但持续迭代的过程中可以看出，“配置流”就会比“代码流”的方式在持续建设上要有优势，始终可以通过配置来降低开放工作量，从而达到节省人力成本的目的。
JVS在线地址：http://frame.bctools.cn/
开源地址：https://gitee.com/software-mi...