根据调查结果显示：22%的人已经开始使用“低代码”，58%的人表示在一年内会去使用，70%的人群对于低代码的定义是非常模糊，91%的决策者认为他们利用了低代码之后效率提升50%以上。
这是一个全新领域，对于陌生的人群，我们应该如何告知其关于低代码开发平台的分类呢？
个人认为低代码分类可以有两种：
- 一种是从行业角度划分，分行业通用低代码开发平台和特定垂直领域的低代码开发平台；
- 另一种可以按可视化程度划分，实际上国内外逐渐把很多无代码平台也纳入了低代码这个体系，所以又可以分低代码和无代码平台。
对于织信低代码开发平台主要有三个明显特征：
1、织信Informat定位于企业级低代码，所以其定制能力具备了从无代码、到低代码两种开发模式，这也是其扩展性优势；
2、快速构建企业生态，尤其针对企业内部的业务场景，可以直接跟企业微信、钉钉等第三方平台生态绑定。
3、拥抱开放生态。织信Informat现在开放生态定位很清楚，核心会把企业连接能力做好，企业客户能通过织信“低代码”平台把内外部产品服务和数据进行打通。
除此之外，也有人说可以低代码分类可以从“功能性”和“领域性”2个方面进行区分：
1、“功能性”重点挖掘跨领域之间的共同特点，以功能为主形成一个个子系统进行复用；
2、“领域性”则更加专注业务，不断深耕聚集与业务相关的知识能力，提供更便捷的垂直业务系统。
甚至还可以从产品功能定义去拆分，如大家所熟悉的“表单驱动”和“流程驱动”，还有“模型驱动”。
而根据之前的实施案例来看，在数字化转型的过程中，很多企业更希望能有更合适他们的低代码平台助力，解决各类复杂的管理流程，通过之前的经验复用，形成一套“低代码”平台的分类逻辑：
1、为OA类厂商提供的“低代码”平台。以审批流程应用为主，把制度规范、管理流程串起来；
2、为财务、业财一体化、ERP客户提供服务的平台。直接为有需要的客户提供一套垂直业务系统，直接完成无代码式的数字化转型；
3、新型互联网厂商的低代码平台，无传统B端软件背景的厂商。
而如果是站在开发者角度，个人更倾向把“低代码”当做辅助开发的一个工具。
比如在业务模型确定后，后端通过“低代码”平台能够自动完成数据库脚本生成、底层增删改查基础逻辑代码生成、还有相关大量同质化的WebAPI代码；前端通过“低代码”平台则直接将设计图输出为页面文件。
这些“低代码”产出的代码，直接交付给稍微懂开发的程序员，稍作调整，即可直接编译发布进入测试环节。因此从开发者角度看，“低代码”的分类，是否可以参考程序员的分类，比如面向前端的、面向后端的、或面向数据库、运维的、测试的等等。
以上是关于“低代码开发平台应该如何分类”的全部内容，我说清楚了吗？如果大家还有不懂的地方，欢迎留言喔~