低代码算是这几年在 IT 行业内越来越尖利的探讨了，而且随着这两年大厂的大量裁员，更是亲者痛仇者快的事件，因为很多大厂发现把一些低端的研发岗位干掉了，反而整个体系在工具的辅助运行下，效率更高，执行力更优。
这里我不再深度交换这个对很对开发者很敏感的内容，明天我想从工程的角度聊聊低代码应该思考的问题。
其实目前低代码有两大方向，一个以依赖于库表构造生成 CRUD 的“代码流”，一种是以动态创建数据模型 + 引擎渲染性能的“配置流”，两大方向各有劣势，目前我比照了多家比拟有代表性的产品，这里给大家做个总结。
- “代码流”集成起来门槛低，找个代码生成器就能够疾速的交融到本人的框架之中。
- “配置流”应用门槛低，所见即所得，对技术人员的依赖度大大降低。
初看两者没有太大的差异，都是升高了开发成本，晋升了研发效率，都是不错的思路。
明天咱们从另外一个继续化的工程研发的角度来两者的差距与不同。
我置信大多数我的项目不是欲速不达的（当然大多数小甲方外包我的项目逃不出这个魔怔，然而他们的初心必定是想长期迭代的）。那么咱们来看看整个比照过程。
“代码流”一期建设如下图：开发人员通过建库建表，而后生成 CRUD 代码（甚至局部业务代码），而后补充业务性能，而后公布上线。
“代码流”二期建设，如果对一期的建设需要有调整，那么低代码是很难再用上了，只有采纳最原始的方法，写代码，优化代码。所以 这种模式的低代码比拟偏差于第一期的新建，后续的调整工作只有对之前生成的代码下来优化批改。
对于“配置流”的一期建设如下图：配置人员间接在整个体系内进行配置性能，造成了业务性能的根底配置数据，通过各个引擎将配置数据渲染胜利能。
其实第一期的建设老本与“代码流”的差不多，都须要化交付工夫。然而第二期建设就有很大的不同了，能够继续的节省成本。
“配置流”的二期交付：
1、复制生产环境的利用到开发环境（或者就在生产环境上生成一个正本利用）
2、对正本利用进行界面化编辑，实现历史性能的调整、新性能的新增，公布为利用的新版本
3、通过零碎提供的工具，将历老利用的历史数据迁徙到新利用之中 4、公布新利用，敞开老利用
从这个过程来看，在第一次建设时两者之间差不多，但继续迭代的过程中能够看出，“配置流”就会比“代码流”的形式在继续建设上要有劣势，始终能够通过配置来升高凋谢工作量，从而达到节俭人力老本的目标。
JVS 在线地址：http://frame.bctools.cn/
开源地址：https://gitee.com/software-mi…