低代码对比分析，从工程的角度看产品的优劣势这是一个谁恨谁恨的问题，因为很多大厂发现一些低端的研发岗位被干掉了，但是整个在工具的帮助下，系统效率更高，执行效果更好。这里我就不再深入讨论这个对开发者非常敏感的内容。今天想从工程的角度谈谈低代码应该考虑的问题。事实上，低代码目前有两个方向，一是依靠库表结构生成CRUD“代码流”，二是动态创建数据模型+引擎渲染功能的“配置流”。两个方向各有优势。目前我比较了一些比较有代表性的产品，这里给大家总结一下。“代码流”集成门槛低，找个代码生成器就可以快速集成到自己的框架中。“配置流程”使用门槛低，所见即所得，大大降低对技术人员的依赖。乍一看，两者并没有太大区别。它们既降低了开发成本，又提高了研发效率。他们都是好主意。今天我们从另一个持续工程研发的角度来看两者的差距和区别。我相信大多数项目都不是一蹴而就的（当然大部分小A方外包项目都逃不过这个魔力，但他们的初衷一定是长期迭代）。那么我们就来看看整个对比过程吧。“代码流”建设的第一阶段如下图所示：开发者建库建表，生成增删改查代码（甚至是部分业务代码），补充业务功能，发布上线。如果“码流”二期建设第一期的建设需求有所调整，低码将很难再次使用。我们只能用最原始的方法来编写和优化代码。因此，该模式的低代码更倾向于一期的新建，后续的调整工作只是对之前生成的代码进行优化和修改。“配置流”建设的第一阶段如下图所示：配置器直接对整个系统中的功能进行配置，形成业务功能的基础配置数据，通过各种引擎将配置数据渲染成功能。事实上，一期建设成本与“码流”类似，都需要最大化交付时间。但是二期建设就大不一样了，可以继续节省成本。“配置流程”二次交付：1.将生产环境中的应用复制到开发环境中（或者只是在生产环境中生成一个复制应用）2.编辑复制应用界面，实现历史功能的调整和新功能介绍新增，作为应用的新版本发布3.通过系统提供的工具将旧应用的历史数据迁移到新应用4.发布新应用，关闭旧应用从点从这个过程来看，在第一次构建的过程中，但是在不断迭代的过程中，可以看出“配置流”的方式在持续构建上比“代码流”的方式更有优势，开放的工作量始终可以通过配置减少，从而达到节省人工成本的目的。JVS在线地址：http://frame.bctools.cn/开源地址：https://gitee.com/software-mi...
