区块链、低代码、元宇宙、AI智能； 。

01 。

【 先来说说背景 】 。

这个概念由来已久，但是在国内兴起，是最近几年； 。

低代码即「 Low-Code 」； 。

指提供可视化开发环境，可以用来创建和管理软件应用； 。

简单的说； 。

就是可以通过各种组件的拖拽，实现页面的创建，交互流程和逻辑，以及数据层面的管理，更加高效的实现需求； 。

早先在数据公司时； 。

见识过低代码的应用，也参与过部分研发，比如元数据平台，BI分析等； 。

不过，当时还是以数据管理的工具来定义项目，并非是低代码； 。

从「 2020年底 」开始； 。

实际上，那个时间节点，低代码平台的应用已经形成趋势了； 。

现在的公司，将「 低代码 」平台的使用「 规划 」到「 业务体系 」中； 。

后来看，这是一个非常 正确的决策 ； 。

在当时的讨论会议上，大Boss给的理念； 。

非核心业务全面集成到低代码平台中，将核心业务的边缘流程，以实践的方式迁出小部分到低代码平台中 ； 。

并且给了理由，是基于「 行业趋势 」和「 业务周期 」的整体考虑，才做出的决策； 。

其实，所谓的降本增效，也会遵循上述的规律； 。

不过遭到技术部的「 稍微 」反对； 。

主管还当场给了理由，说明为何不支持这样的决策； 。

但是最终的讨论结果，出自部门老大的建议； 。

不动核心业务，先将「 边缘业务 」迁入，根据「 效果 」再决策后续规划； 。

当然大Boss最终认同这个结论； 。

以实践三年后的今天来看，人和人的「 差距 」确实挺大的； 。

组织内「 Boss 」层面的决策正确，「 部门 」层面的执行节奏，「 员工 」层面的后知后觉； 。

有感觉到明显的认知「 差距 」； 。

02 。

【 聊聊最初的疑惑 】 。

客观来说； 。

在研发领域内，大部分玩家对新事物都有一定的「 排斥 」情绪； 。

新事物意味「 打破习惯 」和诸多「 不确定 」因素； 。

主观来说； 。

个人虽然也有排斥新事物的心理，但是很少质疑有趋势性的事物，当低代码应用成为流行趋势时，个人选择跟随就好； 。

技术部为何下意识的反对低代码应用?

从最近三年的实践和采坑经验来说，以下问题可能都会成为「 否定 」的因素； 。

【 问题1 】平台选择； 。

这里重点考虑两个维度：普遍性和业务特性； 。

如果只是常规的业务数字化转型，建议优先从大的生态选择，比如「某微」或「某钉」，相对而言会更便捷； 。

如果有行业定制化的需求，则需要有针对性调研，比如财务系统，人事管理等； 。

【 问题2 】成本困扰； 。

思考一个问题:

简单业务需求从整体协作去考虑，涉及的时间成本、人力成本、以及产品技术的维护成本； 。

计算成本之后，和低代码平台的费用做对比； 。

客观的「数字」最有说服力； 。

这里依旧是降本增效的策略：更低的时间，更高的效率，更少的成本，更多的回报； 。

【 问题3 】业务适用性； 。

低代码应用刚火起来不久，并没有发展到各行各业都有成熟合适的解决方案； 。

所以针对低代码平台的使用； 。

最大的争议点就是，没有找到符合业务特性的平台，但是管理层急于追求数字化和降本； 。

这种情况下； 。

如果盲目引入到业务体系中，后期难免会成为烫手的山芋； 。

所以充分的调研，以及对市场上各种案例的参考，从而客观的分析公司当前的业务阶段，是否有必要引入低代码应用； 。

【 问题4 】复杂后的维护性； 。

涉及到一个决策问题，低代码应用到底谁来维护?

业务人员还是研发角色?

从实践经验看； 。

建议是由业务方将需求对接到研发团队，个人所在的组织中，是一个产品加一个研发，一起负责低代码平台的迭代； 。

值得注意的是； 。

低代码应用具有一定的使用门槛，在使用的时候需要遵循普遍的开发原则和规范，以此保证持续可维护性； 。

03 。

【 简单聊聊原理 】 。

在说低代码的实践之前，先来分析一下基础性的原理； 。

如果是 普遍的共性业务 ； 。

常规就是页面的渲染和展示，数据层面的增删改查，计算层面的加减乘除，当然还要考虑模型整体的驱动和交互逻辑； 。

如果是 行业特色的业务 ； 。

则需要低代码平台中进行深度定制化的功能，提供其特定的解决方案； 。

从 技术角度 进行原理的简单分析； 。

在低代码系统中，十分考验前后端的整体「 封装 」能力； 。

前端，页面中各种组件和工具的管理，交互时各种动态计算，页面整体的数据填充； 。

后端，提供整体的模型驱动能力，封装不同场景下的公共的交互接口，从而实现各个模块的流程和逻辑； 。

数据，比较常规的手段有两种； 。

【1】进行纵向的表结构设计，数据存储层面使用键值对的方式，构建搜索查询的逻辑比较复杂； 。

【2】数据采用JSON的格式，在数据体量大的情况下，要考虑查询效率问题； 。

【3】数据还要提供基础的分析和导入导出能力，以及API层面或者数据通道的搬运能力； 。

实际上低代码应用的现状，还会提供各种应用和生态的集成能力； 。

追求功能的全面性； 。

可以参考「某微」或「某钉」的低代码平台的集成能力； 。

04 。

【 组织内实践案例 】 。

明白低代码的基础原理之后，再来聊聊近「 3年 」的实践； 。

首先要明确一个「 认知 」； 。

如果只是从研发角度「 纵向 」看； 。

业务可能就是产品矩阵中所涉及的各种事务流程，以及参与流程管理和协作的各个角色； 。

角度没有问题，但是有点孤立； 。

但是，「 横向 」的从组织的整体来看； 。

即便抛开产品层面，还存在诸多的协作事项，业务流程的管理； 。

这些普遍不会被集成到产品矩阵中； 。

但是同样值得「 信息化 」和「 数字化 」管理，从而打造「 标准化 」流程； 。

在引入低代码平台之后，会形成如下的应用体系； 。

在工作中，如果涉及多部门间的「 横向 」交集； 。

那么会接触到很多第三方应用，而非单纯的研发部门搭建的产品体系； 。

有的应用极具行业的特色，有的应用倾向共性业务的管理，有的应用倾向私域客群的维护； 。

不同平台的共通点，都是可以提供定制化的低代码能力； 。

最为关键的是； 。

这些平台都提供「 对外 」的「 交互 」能力，可以是第三方应用之间的交互，也可以是与内部的产品体系交互； 。

在这种应用体系内； 。

组织在实践近一年之后，各种核心的业务流程，都全面的信息化和数字化管理，并且从应用层面打通了不同业务的交互路径； 。

最后，经过对比论证，业务流的「 效率 」得到极大的提升； 。

05 。

【 实践带来的反思 】 。

与低代码平台联系最密切的一个概念，就是「 数字化 」； 。

在数据公司时； 。

见识到数据层面可以挖掘的价值，智能化的分析决策流程，但是缺乏应用层面的数字化实践； 。

现在的组织中； 。

强烈的追求业务数字化管理，并且有幸见识到了完整的实践过程，才最终形成比较清晰的认知； 。

不得不承认，这是一个普通玩家，「 后知后觉 」的反思； 。

反思低代码应用； 。

各厂商基于自身所在的行业，以及技术和产品的实践经验，将其封装在复杂的低代码平台中； 。

从而提供，各种「 相对简单 」的业务流模型搭建； 。

这样可以支撑各种业务场景的数字化管理，并且低代码搭建的产品，本身具备很强的灵活可变能力，都有助于效率的提升； 。

在业务完成数字化之后，自然可以提升各个场景的统筹效率； 。

对于当下最热门的「 AI领域 」来说，其依赖「 数字化 」的基础，进而推进流程和决策的「 智能化 」管理； 。

反思技术的发展； 。

以前总觉得，所谓的信息化、数字化、智能化「 遥不可及 」； 。

但是区区几年的时间，就已经普及到各行各业； 。

成为当下最大的热点； 。

所以，面对新兴事物的时候，快速理解和衡量其价值，确实会给认知层面带来巨大的差距； 。

06 。

【 最后聊几句问题 】 。

随着低代码应用的普及； 。

越来越多的业务人员具备「 简单 」的开发能力，必然会给部分研发人员的带来负面影响； 。

无疑； 。

加剧互联网的「内卷」趋势，本就卷得一塌糊涂的行业，现在更是雪上加霜； 。

然而趋势的形成，不会以个人意志为转移； 。

就像现在的「 AI智能 」一样，领先的公司不会顾及反对的声音一路狂奔，落后的公司一边喊着反对又一边疯狂追赶； 。

真正的趋势，本着不可逆跟随就好的心态.

最后此篇关于聊聊「低代码」的实践之路的文章就讲到这里了,如果你想了解更多关于聊聊「低代码」的实践之路的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。