共计 3618 个字符，预计需要花费 10 分钟才能阅读完成。
笔者自 2020 年 5 月底入职新公司以来，一头扎进公司低代码平台的建设中。从零开始，在实践中一直打磨，也总结了不少教训与教训。在此，心愿能抛砖引玉，给各位大佬带来更多新的思考。
本系列打算分为四篇，逐渐解说低代码平台建设实际中的各种问题和解决办法：
- 低代码实战篇一：建设认知与深挖业务
- 低代码实战篇二：联合具体业务产品谈谈实现
- 低代码实战篇三：围绕现有能力一直拓展产品状态
- 低代码实战篇四：总结与瞻望
本篇为开篇，依照是什么、为什么、应怎么做的构造来开展，大概须要八分钟的浏览工夫。
引子
笔者从事前端六年，其实也就是往年才对低代码相干概念和思维有所理解，然而不知觉中使用到低代码模式来进行开发却早在 16 年初就开始了。
过后笔者作为部门内前端小能手，接手了一个即便在当初看也是相当麻烦的我的项目。这个我的项目的目标在于定期以 表格 的模式收集审核成员公司的报表，汇总给团体高层和相干剖析部门查看。刚接手时笔者想着不就是建几个表单，填写、提交、审核、查看一条龙完事儿了嘛。
后果前面一对接需要才傻了眼，团体下有上百个成员公司，归属于数个版块集团公司，每个版块团体负责对立收集版块内的要害经营指标数据并上报。然而每个板块的业务天壤之别，汇总的表格格局、数据绝大部分都不一样！！每个业务版块均匀十多张表格，多的时候总共 六七十个齐全不一样 的表格！！这还不是最可怕的，最可怕的是因为业务变动频繁，这些表格还会常常变动！！而且还要能反对在挪动端完满的展示表格数据（挪动端展示大表格的体验极差）！！
做过业务零碎的童鞋们都晓得，数据库里保护六七十个业务表是十分麻烦的，业务表字段要是频繁的改变那更是没方法做。前端童鞋也很苦逼呀，几十个表单页面改来改去，那不得原地爆炸。
工夫紧急，第一版开发工夫只有一个月，苦思数日的我终于想到了一套在过后看来解了当务之急的解决方案：
- 每个表格用一个 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 始终、体验统一、性能统一的利用—来谈谈这个产品是怎么从无到有一步步建设而来的。
次要内容包含但可能不限于：
- 业务剖析与形象
- 数据模型与组件形象
- 动态数据赋能
- 可用性、易用性和满足更定制化的需要
- 拓展经营和凋谢的能力
欢送大家在评论区交换，如有谬误也请斧正哈。
感兴趣的敌人欢送点赞关注，年底 KPI 就靠各位大佬啦。我将在除夕放假期间尽快实现全副文章，尽快收回~
