作者自2020年5月底入职新公司以来，一头扎进公司低码平台的建设中，从零开始，不断打磨在实践中，我也总结了很多经验和教训。在此，希望能够抛砖引玉，给各位大佬带来更多的新思维。本系列计划分为四个部分，将逐步讲解低代码平台搭建实践中的各种问题和解决方案：低代码实战一：建立认知，深挖业务低代码实战二：Talk关于结合具体业务产品实现LowcodePracticalPart3:基于现有能力不断拓展产品形态LowcodePracticalPart4:SummaryandOutlook这部分是开始，后续会根据what的结构进行扩展，为什么，以及如何去做。阅读大约需要八分钟。简介作者从事前端六年。其实也是今年才对low-code相关的概念和思想有了一定的了解，但是不知不觉就开始使用low-code模式进行开发，不过早在2016年初就开始了。当时笔者作为科室的一名前端小能手，接手了一个到现在都还比较麻烦的项目。本项目的目的是定期收集审计成员公司的报告，以表格形式汇总，供集团高层及相关分析部门审阅。刚接手的时候，笔者以为会是建几个表，填写，提交，审核，检查一条龙的流程。结果后面遇到需求的时候傻眼了。集团下属成员企业数百家，隶属于数个集团公司。各组负责收集和上报本组关键经营指标数据。但是每个板块的业务差异很大，大部分汇总的表格格式和数据都不一样！！每个业务版块平均有十多个表格，有时总共有六十、七十个完全不同的表格！！这还不是最可怕的，最可怕的是由于业务的频繁变化，这些表会经常变化！！并且必须能够支持表格数据在移动端的完美展示（在移动端展示大表格体验极差）！！做过业务系统的童鞋都知道，在数据库中维护六十、七十张业务表是很麻烦的，更不可能经常更改业务表的字段。前端的童鞋也是很辛苦的。几十个表单页改改改，不能原地爆。时间紧迫，第一个版本的开发时间只有一个月，当时终于想到了一套紧急解决方案：每张表用一个json对象来描述，大致如下：{row_01:{column_01:{rowspan:0,colspan:0,editable:false,type:'string',value:'business',...},column_02:{rowspan:0,colspan:0,editable:false,type:'string'},value:'indicator',...}},row_02:{column_01:{rowspan:0,colspan:0,editable:false,type:'string',value:'netcashflow',...},column_02:{rowspan:0,colspan:0,editable:true,type:'number',value:'',...}}}这是一个2X2的表，实际业务中需要的表复杂得多，但是通过一个设计良好的jsonschema，它总能完整地描述表格的样子，哪些行是标题，单元格需要跨越多少行和列，哪些单元格不能改变，哪些单元格可以改变，可编辑单元格的内容类型（字符串、数字、时间点、时间段、金额等）table>{{cell.value}}...等类型的输入项没错，核心代码就是这么简单。3、移动端定义了一系列适合移动端的组件，如主字幕、明细指标（左右结构、上下结构），并根据不同业务类型对数据展示的不同要求，它基于jsonschema（什么是DSL）转换成另一套mobiledsl，然后生成一系列基于mobiledsl和mobilecomponents的组件组合。比如：这种在移动端的展示比表格的形式舒服多了~转换后的移动dsl大概是这样的：[{type:"section",title:"financialindicators",subTitle:"1万元",list:[{type:"description",layout:"horizo??ntal",title:"NetCashFlow",desc:"1000"},...]},...{type:"introduction",intro:"XXXXX"}]渲染的伪代码就不写了，很简单。4.为每个表单自定义一个jsonschema作为表单模板。填表人可以在每个填表周期根据该模板填写表格。如果填写期间表单发生变化，只需要根据具体修改调整表单的jsonschema和mobileschema即可。只需要一张数据表就可以解决以往几十张、上百张数据表才能解决的问题。经过后续统计，至少有200多个不同版本的复杂表被新增、修改、修改。..回头看当时的初期项目，虽然还有很多问题，比如由于项目投入和人力经验，无法图形化输出jsonschema，但完全是手动输出哈哈。.比如表版本管理功能逻辑混乱等等。但这是我第一次完全自己掌控一个项目，从需求调研到产品设计到数据库表设计到前端开发和后端监理到项目管理。各方面都有了很大的提高。如果当时项目投入再大一些，完善了基于图形界面输出jsonschema的功能，那基本就是一个比较标准的低代码应用了。可惜资金不足，人手不足，只能实现手动json的阶段。不过，这个项目也为我积累了很多宝贵的经验。毕竟，从需求调研、产品功能设计、数据库表设计，到前端开发、后端监管，我都参与了很大程度。到底什么是低代码低代码？那么到底什么是低代码呢？看完我刚才举的例子，你可能已经有了一个初步的概念。这里我就根据自己的理解做一个总结。低代码旨在提高效率。通过图形化配置、少量参数配置、内置隐式逻辑规则等，输出能够完整描述业务模型、兼容代码编写的数据，并以此为基础，完成业务或产品形态。应用程序构建和渲染。效率的目的是为人服务，不仅是为了提高开发人员的业绩，还要为所有与业务应用相关的人员提供效率提升保障。二是为企业服务。营销页面低代码平台可以快速构建营销页面，场景应用低代码平台可以快速输出应用，流程表单低代码平台可以快速输出功能和逻辑完整的表单流程。图形化配置、少量参数配置、内置隐式逻辑规则等方式包含了一个低代码平台的重要核心，即门槛要足够低，操作方式简单易懂，所见即所得操作经验、低代码甚至根本没有写代码的低要求。输出能够完整描述业务模型并兼容代码编写的数据。这需要对业务进行持续深入的分析，全面了解业务图景。低代码平台适用于相对垂直的业务领域。相反，代码可能会成为障碍。根据业务或产品表单，完成应用的构建和渲染通过我上面项目的例子，很容易理解输入是表单，输出不一定是表单。可能是适合移动展示的样式，也可能是表单数据经过BI。输出适合大屏显示的可视化图表。展示形式（pc、手机、大屏等）、数据载体（单一数据、结构化数据、BI处理的数据）、平台特性（Android、iOS、小程序、h5等）都对低端有很大影响。代码平台。影响，必须结合实际业务进行深入分析。为什么要做低代码平台？因为业务需要，也因为更高的成本效率，因为从长远来看，低代码已经成为一种趋势。对于技术团队或个人而言，结合业务尽早接触或了解，有利于快速占领细分领域的技术优势。对于企业来说，对于定制化要求不是特别高的业务，低代码平台可以更好的提升效率和赋能。当然我一再强调，业务一定要结合具体业务来考虑是否需要开发或接入低代码平台。不过提前了解一下还是不错的~低代码平台应该做什么？在接下来的系列文章中，笔者将结合公司的低代码平台产品——一款可以通过图形化拖拽和简单的参数配置生成Android、iOS、支付宝小程序、微信小程序的四端UI。功能一致的应用程序——让我们来谈谈这个产品是如何从头开始一步一步构建的。主要内容包括但不限于：业务分析和抽象数据模型、组件抽象动态数据赋能可用性、易用性、满足更多定制化需求的能力。拓展运营，开放能力。欢迎在评论区交流。请纠正我。有兴趣的朋友欢迎点赞关注，年底的KPI就靠你们了。元旦假期我会尽快完成所有文章，尽快发出~
