低代码之殇II

上一篇文章说的IBM和微软的低代码平台没有取得广泛的应用，是否低代码平台的概念不成立？

我这两年也在做低代码平台的研发工作，不过更偏向于产品层面的规划，而不是写代码。在正式投入人员进行开发之前，先进行了市面上的低代码平台的调研。类似的低代码的分析报告也有很多，我只是从我的角度进行一下评价。

1. 首先，低代码平台是个工具，目的是用这个工具更高效率，更高质量的交付一个信息化管理系统，而不是针对特定场景的开发工具，比如Unity3d是用来开发游戏和VR的工具；
2. 这里说的信息化系统，典型的有：进销存、OA、CRM、固定资产管理、HRM等等
3. 主要的功能就是表单+流程+报表+权限
4. 一般是B/S架构
5. 低代码平台一个影响深远的点在于该平台是面向业务人员还是面向开发人员

为了方便对比，做了两种模式的对比：

	面向业务人员	面向开发人员
典型案例	lotus notes和sharepoint	jeecg, entfrm；我们的平台
理念	平台要容易学习，不需要专业IT知识也能配置	平台是由开发人员使用的，通过配置提升开发效率，同时可以通过二次开发实现复杂的业务逻辑和需求
问题	开始配置很容易，二开很痛苦	配置操作不直观，非专业人员学习困难
优点	能配置出来的功能都很完美	无论多复杂的功能都能实现

需要说的是，还有很多低代码平台是介于这两者之间，有的偏向任务人员，有的偏向开发人员。

当然了选择哪种模式，更多是在于低代码平台未来要开发的目标项目都是什么类型的，以及公司整体产品矩阵的布局。微软有了visual studio就没必要搞一个面向开发人员的低代码平台，否则就跟visual studio有些冲突。

我所在的公司会遇到运营商、金融、党政军、国企、私企各种行业的客户，业务系统也是五花八门，在软件项目利润越来越低的背景下，希望通过使用低代码平台降低项目开发成本，提升交付质量，自然的选择就是需要低代码平台是给开发人员使用的，用低代码配置出来的系统，能够让开发人员很容易上手，进行二次开发，无论客户提出多么复杂的需求都能满足，否则遇到无法实现的二开需求，项目也就很难交付了。

虽然我们的低代码还是在不断迭代升级中，但是已经用低代码实施了几个项目，都取得了非常好的效果，达到了降低成本，提升质量的要求。

篇幅限制，关于如何做到面向开发人员的低代码平台，在下一篇文章中介绍。