低代码设计教程（一）：设计目标

 什么是低代码呢？

2014 年，Forrester Research 研究机构正式提出了低代码的定义，即利用很少或几乎不需要写代码就可以快速开发应用，并可以快速配置和部署的一种技术和工具。例如大家通过Excel创建了一个表格来管理数据，Excel其实就是一个最成功的低代码工具，而且已经融入到了所有人的生活和工作中。

低代码有价值吗？

目前网上有很多声音，一种认为低代码是行业毒瘤，一种认为低代码会取代程序员。我觉得这两种方式都比较极端。

我认为低代码的核心是抽象，包括对产品功能的抽象、业务模型的抽象。抽象能力是产品经理和架构师必须掌握的核心能力。

低代码核心能力

我们在设计低代码之前，需要分析低代码的应用场景，需要使用低代码来解决什么问题？

我们以报表场景举例：业务人员给开发人员讲解业务模型、计算规则；开发人员编写代码；项目实施人员部署发布；业务人员测试验证上线；

这时，我们希望设计一个低代码产品，把1、2、3步的工作省略，由业务人员直接设计报表。我们的"报表工具"1.0版本就规划好了。

随着工具的推广使用，越来越多团队需要使用我们的工具，需求也越来越多，我们发现每次版本升级都需要消耗很多时间。

这时，我们的2.0版本希望变成一个BS版本，由产品团队统一负责升级管理。

有一天，老板说我们这个工具很不错，希望能去市场销售，让更多用户使用，同时也能给大家带来不错的奖金。于是团队开始扩建，随着销售的客户越来越多，我们团队也越来越大，老板疑惑了，我们产品不是很成熟吗？为什么团队还需要这么多人？原来每个客户都是私有化部署，安装、部署、培训、个性化需求处理占用了很大一部资源。

老板说，那我们做一个3.0的saas版本吧，企业统一到我们这里来注册使用，我们统一收集需求，并按版本计划统一发布，这样团队投入减下来的费用让利给客户，让客户购买产品价格降下来。

我们的报表3.0版本越来越成熟，市场占有率也趋于饱和了，但是老板希望公司业绩继续增长，于是号召大家开会，今年我们计划在低代码领域再开发几个新产品，例如“xx文档”、“xx流程”，“xx数字云”。你们好好设计下业务场景，但是我提几点要求：

企业可以购买多个产品，可以叠加套餐优化。企业、用户、权限这部分需要统一使用我们报表工具这部分的能力，大家不要再重复开发。

于是，我们从报表工具中剥离出来一个针对内部多产品的内部产品“管理平台1.0”

低代码系统设计教程

接下来，我会结合我们自研的低代码系统以及在公司的使用案例分别从以下几个章节来进行介绍。

企业数字化场景案例

低代码产品的重点基础产品：平台管理服务设计

数据查询场景（BI）设计

数据维护场景（表单、流程）设计，从低代码到零代码的思考