笔者自2020年5月底入职新公司以来，一头扎进公司低代码平台的建设中。从零开始，在实践中不断打磨，也总结了不少经验与教训。在此，希望能抛砖引玉，给各位大佬带来更多新的思考。

本系列计划分为四篇，逐步讲解低代码平台建设实践中的各种问题和解决办法：

• 低代码实战篇一：建立认知与深挖业务
• 低代码实战篇二：结合具体业务产品谈谈实现
• 低代码实战篇三：围绕现有能力不断拓展产品形态
• 低代码实战篇四：总结与展望

本篇为开篇，按照是什么、为什么、应怎么做的结构来展开，大约需要八分钟的阅读时间。

引子

笔者从事前端六年，其实也就是今年才对低代码相关概念和思想有所了解，但是不知觉中运用到低代码模式来进行开发却早在16年初就开始了。

当时笔者作为部门内前端小能手，接手了一个即使在现在看也是相当麻烦的项目。这个项目的目的在于定期以表格的形式收集审核成员公司的报表，汇总给集团高层和相关分析部门查看。刚接手时笔者想着不就是建几个表单，填写、提交、审核、查看一条龙完事儿了嘛。

结果后面一对接需求才傻了眼，集团下有上百个成员公司，归属于数个版块集团公司，每个版块集团负责统一收集版块内的关键运营指标数据并上报。但是每个板块的业务大相径庭，汇总的表格格式、数据绝大部分都不一样！！每个业务版块平均十多张表格，多的时候总共六七十个完全不一样的表格！！这还不是最可怕的，最可怕的是由于业务变化频繁，这些表格还会经常变动！！而且还要能支持在移动端完美的展现表格数据（移动端展现大表格的体验极差）！！

做过业务系统的童鞋们都知道，数据库里维护六七十个业务表是非常麻烦的，业务表字段要是频繁的改动那更是没办法做。前端童鞋也很苦逼呀，几十个表单页面改来改去，那不得原地爆炸。

时间紧急，第一版开发时间只有一个月，苦思数日的我终于想到了一套在当时看来解了燃眉之急的解决方案：

1. 每个表格用一个json对象来描述，大概如下：

{
  row_01: {
    column_01: {
      rowspan: 0,
      colspan: 0,
      editable: false,
      type: 'string',
      value: '业务',
      ...
    },
    column_02: {
      rowspan: 0,
      colspan: 0,
      editable: false,
      type: 'string',
      value: '指标',
      ...
    }
  },
  row_02: {
    column_01: {
      rowspan: 0,
      colspan: 0,
      editable: false,
      type: 'string',
      value: '净现金流',
      ...
    },
    column_02: {
      rowspan: 0,
      colspan: 0,
      editable: true,
      type: 'number',
      value: '',
      ...
    }
  }
}

这是一个2 X 2的表格，实际业务中的表格要远远复杂得多，但是通过一个精心设计的 json schema，总能完备得描述这个表格长什么样子，哪几行是表头，单元格要跨几行跨几列，哪些单元格是不可改的，哪些单元格是可改的，可编辑单元格的内容类型（字符串、数字、时间点、时间段、金额等等）

2、PC端展现表格时基于json schema做渲染，伪代码如下：

<table>
  <tr v-for="row in jsonSchema">
    <td
      v-for="cell in row"
      :rowspan="cell.rowspan"
      :colspan="cell.colspan">
      <span v-if="!cell.editable">{{cell.value}}</span>
      <template v-else>
        <input v-if="cell.type==='string'" v-model="cell.value" />
        <input-number v-if="cell.type==='number'" v-model="cell.value" />
        <date-time  v-if="cell.type==='dateTime'" v-model="cell.value" />
        ...等等其他类型输入项
      </template>
    </td>
  </tr>
</table>

没错，核心代码就是这么简单。。

3、移动端定义一系列适用于移动端的组件，比如主副标题、指标详细（左右结构、上下结构），根据不同业务类型对数据展示的不同需求，基于 json schema 转换成另一套 mobile dsl（什么是DSL），再基于 mobile dsl 和移动端组件生成一系列组件的组合。比如：

这样的显示在移动端上就比表格的形式舒服多了~

转换后的mobile dsl 大概是这样的：

[
  {
    type: "section",
    title: "财务指标",
    subTitle: "万元",
    list: [
      {
        type: "description",
        layout: "horizontal",
        title: "净现金流",
        desc: "1000"
      },
      ...
    ]
  },
  ...
  {
    type: "introduction",
    intro: "XXXXX"
  }
]

渲染的伪代码我就不写了，也挺简单的，

4、每个表格定制一份 json schema 作为表格模板，填报人每个填报周期都可以此模板为基础填写表格，某个填报周期如果表格发生了变动，只需要调整表格的 json schema 和根据具体的修改，更改移动端 mobile schema 即可。只需要一个数据表，就能解决以往几十上百个数据表才能解决的问题~后续经过统计，增增改改至少有两百个不同版本的复杂表格。。。

现在回看当时这个初级项目，尽管还有许许多多的问题，比如由于项目投入和人手经验能力的问题，未能做到图形化输出json schema，完全是靠的人力手工输出哈哈。。还比如表格版本管理功能逻辑混乱等等。但是这是我第一次独自一人从需求调研到产品设计到数据库表设计再到前端开发后端监督再到项目管理，完整的掌控一个项目，各方面都有了较大的提升。

如果当时项目投入再大点，完善基于图形化界面输出 json schema 的功能，基本就是一个比较标准的低代码类应用了。可惜经费不足、人手不足，只能做到手撸json的阶段。不过这个项目也为我积累了很多宝贵的经验，毕竟从需求调研、产品功能设计、数据库表设计再到前端开发后端监督等等我都有极大程度的参与。

low-code低代码到底是什么？

所以低代码到底是什么呢？看了我刚刚举的例子，可能大家已经有了一个初步的概念。在这我根据自己的理解，做一下归纳总结。

低代码是以效率提升为目的，通过图形化配置、少量参数配置、内置隐含逻辑规则等方式，输出能够完全描述业务模型且能够兼容代码编写的数据，并以此根据业务或产品形态，完成应用的构建与渲染。

以效率为目的

一是为人而服务，不仅是提升开发人员的效能，更要能给业务应用所关联的所有人员提供效率提升的保障。二是为业务而服务，营销页面低代码平台快速搭建营销页面，场景应用低代码平台快速输出应用，流程表单低代码平台快速输出功能逻辑完备的表单流程等等。

图形化配置、少量参数配置、内置隐含逻辑规则等方式

蕴含着一个低代码平台的一个重要核心，那就是门槛一定要足够低，简单易懂的操作方式，所见即所得的操作体验，低代码甚至完全不需要写代码的低要求。

输出能够完全描述业务模型且能够兼容代码编写的数据

这要求能够对业务持续进行深入的分析，对业务的全貌具有充分的了解，低代码平台适合较为垂直的业务领域，过于追求大而全，低代码可能反而成为阻碍。

根据业务或产品形态，完成应用的构建与渲染

通过我上面项目的例子，很好理解，输入的是表格，输出的不一定也是表格，可能是适合移动端展示的样式，也可能表格数据经过BI输出适合大屏展示的可视化图表。展现形态（pc、mobile、大屏等）、数据载体（单一数据，结构化数据，BI处理的数据）、平台特性（安卓、iOS、小程序、h5等）等都对低代码平台有较大影响，我们必须结合实际业务深入分析。

为什么要做低代码平台呢？

因为业务需求，也因为成本效率更高，更因为从长远上，低代码已经成为一种趋势。对于技术团队或者个人，结合业务尽快接入或者了解，有利于在细分领域迅速占有技术优势。对于企业，对于定制化需求不是特别高的业务，低代码平台能较好的增效赋能。

当然，我反复强调业务，一定要结合具体的业务来思考当前是否需要开发或者接入一个低代码平台。

但是，提前了解了解也蛮好~

低代码平台应该怎么做呢？

接下来的系列文章中，笔者将结合公司的低代码平台产品—一款通过图形化拖拽和简单参数配置就能生成Andriod、iOS、支付宝小程序、微信小程序四端UI一直、体验一致、功能一致的应用—来谈谈这个产品是怎样从无到有一步步建设而来的。

主要内容包括但可能不限于：

1. 业务分析与抽象
2. 数据模型与组件抽象
3. 动态数据赋能
4. 可用性、易用性和满足更定制化的需求
5. 拓展运营和开放的能力

欢迎大家在评论区交流，如有错误也请指正哈。

感兴趣的朋友欢迎点赞关注，年底KPI就靠各位大佬啦。我将在元旦放假期间尽快完成全部文章，尽快发出~