手码6500字，带你快速看懂：什么是低代码开发平台（apaas），低代码有哪些价值，以及低代码平台的使用逻辑和心得。
一、什么是低代码开发平台（apaas）？
低代码开发平台是一种aPaaS（Application Platform as a Service），它是仅需少量编码+可视化组件拖拽 (drag & drop) 的构建方式即可快速完成应用系统开发的平台。该名词最早于2014年6月由Forrester Research最先提出。
低代码开发平台通常具备以下特点：
- 可视化集成开发环境（Visual IDE）;
- 大量可重用且支持拖拽的组件（drag & drop）；
- API应用程序编程接口（Application Programming Interface）；
- 等等。
如果你对这个概念还不太理解，可以想想一下《钢铁侠》中钢铁侠在自己的全息工作台上摆弄设计各种钢铁侠的场景……（虽然目前的低代码平台还没这么酷炫，但是大概的意思差不多）。
如果觉得这个例子太过科幻，其实我们身边随手都能看到类似的工具和平台，比如，Mac系统中的Automator或是iOS中的快捷指令（原来叫做workflow），亦或是前几年火过一阵的ifttt……
二、低代码开发平台的价值
假如我们需要用到低代码，那首先一定要明确低代码平台究竟能够给我们带来哪些价值。
以下是我总结出的几点价值，供大家参考。
1、 降本增效
据统计，低代码开发在企业内部信息化的应用上的效率提升大概在67%左右，相当于1个人能够发挥2-3人的人效。而开发完成后，测试和优化的周期也相应会大大缩短。所以相同的项目通过传统编码的方式来做可能需要3个月的时间，而低代码预计1个月左右就能搞定了。无论是人力的占用还是时间成本，低代码在降本增效方面都有着绝对的优势。
2、 逐步落地
不用像过去的代码开发一样，需要做大量的准备工作才能开始编码。通过低代码所见即所得，快速开发的特性。很多的业务实践或者优化都可以在几分钟内开发出来，得到效果反馈。这会直接改变原有的企业数字化战略计划。让数字化的整体规划过程可以更加从容。不用担心一旦开始开发很多东西就不能修改，不能回头的问题。模块化的开发模式，会让整个业务变得更加灵活，更加能够匹配市场的变化。
3、 全员参与
和传统编码必须得由IT人员参与的情况不同，对于一些基础性的改动或者开发工作，通过低代码平台已经不需要IT人员“事必躬亲”了，业务人员也可以根据自身的需求，通过平台的配置项快速完成业务的变更和修改，在IT资源紧缺的公司，这种模式，会很大程度的提高员工参与信息化建设的积极性，更好的推动企业数字化落地。
4、企业级底层能力
企业级最重要的意义在于必须要能够成为支持企业各部门、各业务开展的信息化重要“支柱”， 企业的数字化应用场景，按照业务类型通常包括数据信息管理、业务审批、各类报表分析以及其他业务；
- 按照业务部门可以分为人事行政、项目、销售、研发、生产等等；
- 按照当前的软件类别又可以分为ERP、SCM、CRM、OA、PLM、MES等等，
各行业中又还有其他的定义标准。
所以如果要采购低代码平台，能否支持到上述这些场景下，去完成系统开发任务，将会是所有公司采购平台的最关键因素。 谁也不想买一个工具箱，却只能解决一个问题。
5、易用性和可维护性
诸多的低代码开发平台往往都只强调业务开发过程，却忽略的后续的运维管理。要知道一个正常可运行的系统，开发完成才只是开始，后续还会有持续不断的优化和开发。那么谁来开发，谁能开发，如何进行版本的管理和运维。 大型信息化系统需要有严格的研发管理流程。不然一旦操作不慎，可能会导致企业重要经营数据的流失和业务的瘫痪。
这一块低代码是不能和传统代码开发“唱反调”的。企业级低代码在这一块能够保持和传统代码开发一样，在运维上：
- 支持针对开发人员进行权限管理，做到模块和功能的限制；
- 支持查看应用的运行情况，针对正在运行过程中的自动化事务的占用资源和次数进行监控；
- 支持应用系统的版本管理，可同步git，实现分支拉取和上传；
- 支持应用修改-发布机制，支持“UAT-灰度-生产环境”的开发更新流程。
6、拥抱新技术
除了能够支持常规的信息化系统的开发，随着市场发展的需求，新的技术融入能够和低代码一起产生不一样的化学反应。例如AIGC概念的异军突起，织信低代码 也积极响应，率先和ChatGPT、Stable Diffusion实现对接。
通过和ChatGPT的对接，实现了业务系统的AI智能开发（如智能生成数据模型，辅助编写代码，自动生成业务逻辑自动化等等），进一步提升开发效率。
而Stable Diffusion作为AI图片领域的重要模型，集成到织信低代码后，织信平台可以在相关图片业务场景中，实现AI文生图、图生图需求的快速调用。服务于电商、设计、广告等领域，极大的提高了业务生产力。
三、低代码开发平台的使用心得
下面以 织信低代码 为例，来深入聊聊低代码平台的使用逻辑。
应用设计过程
利用织信低代码进行应用设计的过程和传统开发过程是比较类似的，分为以下模型设计 页面设计 交互设计 流程设计 权限设计5个步骤。
模型设计：利用数据表模块进行模型和字段设计
例：我们要进行一个员工信息表的建立，员工信息表的内容如图：
首先我们需要根据员工信息表进行分析，确定每列对应的在织信中的字段类型。
| 列名称 |
字段类型 |
| 工号 |
单行文本 |
| 姓名 |
单行文本 |
| 性别 |
列表选择 |
| 年龄 |
整数 |
| 家庭住址 |
单行文本 |
确定好表单的字段类型后，在系统中进行模型配置
创建完成的数据表展示
页面设计：利用视图模块进行数据展示设计，对于复杂的页面使用网站模块和自定义页面进行页面开发
页面设置支持从显示设置、筛选条件、树形结构、数据过滤和排序、工具栏、表单配置、事件监听7个配置模块。用户可以根据实际业务场景，进行符合需求的数据页面配置操作。
配置后的页面展示内容及对应效果
交互设计：利用控件设计操作按钮
用户可以通过控件，拓展符合业务需求的交互按钮，可执行用户指定的操作行为，来满足实际应用场景的需求。控件支持在表格工具栏、数据表详情、仪表盘、右键菜单等多种场景添加配置。
控件配置项
流程设计：利用BPMN设计工作流程
织信的工作流是基于BPMB2.0的流程设计工具，支持用户通过工作流来完成各类业务流程的设计和开发工作。例，我们需要完成一个发票报销的审批流程：
下图为发票报销业务流程图：
基于业务流程图，在工作流中配置对应的流程：
权限设计：设计团队角色和应用角色
团队角色是能够分配在织信团队中的用户所具备的权限范围，包括团队管理 应用管理 应用设计 邀请成员 4种权限的分配，一般来说，团队内部权限分配可参考：
- IT及运维人员 :应用管理应用设计
- 行政及人事 :团队管理邀请成员
- 公司成员 ：无需权限
应用角色可以给应用内的成员进行角色和权限进行配置，可以设置在应用各模块中的权限。
除了团队角色 应用角色可以对成员进行权限的配置和管理，在系统中，还有许多地方可以根据场景不同设置特定的用户权限来实现业务需求，例如：
- 字段权限设置
- 记录行权限设置
- 审批权限设置
- 通过自动化配置的特殊数据校验
以上的步骤可以顺序进行，也可以分迭代循环进行。
在织信低代码中应用的设计过程和使用过程是分离的，修改应用的设置后需要发布应用才能生效。每次发布动作应用的发布版本号会递增。应用的发布只能递增，不能降级。如果有降级需求，需要在发布应用时将应用数据库做快照备份，降级时恢复备份即可。
安装部署和升级
在应用设计器中完成应用设计后可以将应用导出为imr（InforMat aRchive）安装文件，imr安装文件中包含了应用的所有配置项。通过在不同环境中分发imr文件可以实现多环境测试部署。一个典型的安装部署过程如下：
强烈建议在每次发布生产环境时都将imr文件备份，存入到制品库中。
环境变量
在不同环境部署应用时，需要动态的调整一些参数值。例如支付服务的地址，在测试环境对应的是测试支付地址，在生产环境对应的是真实的支付地址。
| 环境 |
地址 |
| 测试环境 |
https://test.pay.com/pay |
| 生产环境 |
https://pay.com/pay |
这些参数值会被自动化程序或者脚本引用，为了能保证应用在不同环境中迁移，织信提供了环境变量设置的功能。
在织信中可以通过设置 环境 ID 值的映射关系，并且通过表达式函数Context.appEnvProp(propKey)获取当前环境ID等于 propKey的值。 应用当前环境属性在应用设置页面修改。
版本说明
应用在进行版本升级时，应当将版本号增加，织信对版本号的格式没有硬性要求，建议使用主版本.次版本.修订版本的格式设置版本号。对于每一个版本可在应用设置中增加版本说明。版本说明可使用markdown格式书写。在导入或者升级应用时织信会显示此安装文件的版本说明。
团队人员的建议
对于简单的应用场景，例如任务管理一类的需求，如果应用中不涉及复杂的逻辑计算操作，应用的设计人员可以由产品经理担任。这类应用的配置过程都可以通过图形化的方式完成。
对于复杂的大型应用，例如ERP，MES，PLM一类的需求，我们建议应用设计团队由以下角色构成：
- 产品经理：负责需求的梳理，如模型设计、页面设计、交互设计、权限设计；
- 开发人员：负责自动化搭建，脚本编写以及在模型设计、页面设计、交互设计、权限设计过程中的表达式的编写；
- 测试人员 对系统进行功能测试 这与传统的开发模式是类似的，但是基于织信提供的大量功能，人员数量上会大幅减少。
使用逻辑讲完了，最后再讲一讲我是怎么利用低代码从0到1搭了一套工单系统的。
为了充分体验搭建过程，本人尝试搭建一个内容部门与其他部门需求对接所使用的应用，有点像内容团队的“临时工单”，来解决目前协同办公软件分工颗粒度过大、跨部门临时需求得不到重视、执行者无法了解任务优先级、领导不好把控进度等问题。
该应用希望实现的是：
- 1、临时需求能够通过需求方的录入，自动成为一个待分配的工作。
- 2、由相应负责人根据具体情况来分配人员执行。
- 3、执行人员可以通过了解任务紧迫程度，自行排列优先级，完成后上传结果。
- 4、由相应分工负责人和需求提出方来验收结果。
- 5、全程进度要一目了然，方便追责，有统计数据归档。
如果放在以前，不会编程的我只能对外求助，而这样一个不大不小的需求，也很难得到重视。现在我们可以考虑拿低代码平台尝试自己搭建，低代码中比较有名的有宜搭、织信Informat等低代码产品，本次我们依旧选择“织信Informat”来进行实操。
织信Informat内可以选择空白应用搭建，也可以选择基于既有模板搭建。模板中心提供OA管理、客户管理、项目管理、疫情防控、生产管理，进销存管理等类型，数量超过了上百个。
根据实际需求，本人在模板中选择的是看似不太搭界的反馈工单模板，看中的就是工单管理中反馈工单、任务列表、客户信息、服务申请、待派工单、待接工单、待处理工单、已处理工单以及满意度回访这一整套的售后管理流程，而这套逻辑正好适用于本人的需求。
所有的内容都是组件形式，比如我想在页面内加入评分模块，只需要拖拽到相应位置即可。一阵疯狂的重命名、删减、拖拽之后，应用就基本有了雏形，可以试用了。
当然，如果需要实现一些复杂的功能，或者现有的组件并不能满足需求，目前还是需要代码和一些函数逻辑的。所以低代码对于编程小白而言，仍有一定的局限性，但对于有一定编程基础的人，可以方便、快捷很多，省去很多基础操作。
完成全部调整后，应用上线，邀请朋友实测一下成果。朋友在填写并发起申请后，相应人员会收到需求的消息提示。
点击可以查看需求的详情，相关人员来负责任务的审批工作，通过的话就开始分工操作。当然，如果不合理自然也可以拒绝。
通过之后可以安排相应的执行人员，完成需求的推进。
执行人员处理完成任务后，会有一个验收的过程，由需求提出者和分工负责人来进行验收、评价，以确认需求结束。
在整个过程中，也可以很清晰地查看到项目的进度，任务在哪个时间进行到了哪一步，卡在了哪里，都很明确。预期功能通过简单修改相同逻辑的“售后工单”模板确实得到了实现。
在测试过程中，我们发现不论应用是否上线，都是可以随时去调整的，比如我们实测时候朋友发现部分环节应该对权限管理进行调整，这确实是本人搭建时遗忘了，于是我抓紧去添加关于这部分的设置就可以了。
总结：
简单快速，但依然存在一定门槛。
应用的搭建非常迅速，整个过程用时大概是一个多小时，期间主要用时都是梳理应用的逻辑，也就是想结构、想每一个地方该是什么，实际去动手的工作量反倒是不多。
事实上，大家看了本人的搭建过程应该会明白，用低代码搭建应用很简单，甚至要比PPT套模板要简单得多。在理清应用的逻辑的情况下，就像搭积木或者拼乐高玩具，只需要会用一点点电脑就可以完成搭建操作。
1、实际使用确实可以不用代码，完成一些简单应用的搭建。纯粹不需代码时，可能更像是搭建，开发的感觉比较弱，拖拽可以解决绝大部分需求。
2、后期调整简单，上线后可根据实际需求随时微调，不用来回找客服、找IT。
3、并且诸如我们常挂在嘴边的“大数据”，低代码平台也提供数据分析的类目和插件，模板会在数量和匹配程度上不断延伸，这意味着搭建应用时修改的地方会越来越少。也就是说，低代码平台在提高效率方面还会不断的强化。
问题：
本人在体验中也发现了一些使用中的问题：
1、应用框架误删后无法恢复，只能重新搭建，无法通过“撤销”挽回，说明还不是特别智能，存在优化空间。
2、对于编程小白仍有一定局限性，偏复杂的应用和功能会涉及到函数的调用，仍需要编程基础才能理解。
3、应用首页PC版横向布局看起来会比较奇怪，和移动端的适配有一些优化空间。
低代码的价值在哪？
那么，仅仅是“低门槛”和“高效率”就值得整个行业追捧吗？当然不是。虽然低代码至今依然存在一些局限性，但至少初步做到了将IT开发的能力赋予给不懂IT的人，这会带来不少价值。
1、低代码精简了数字化的难度。软件千千万，但为什么数字化转型很成功的传统企业却不多？一旦有成果显著的，也被称为各行各业的标杆。
软件具备通用性，即便是行业化软件，也是挖掘、梳理、凝聚特定行业的普遍问题后研发，大部分的数字化难点在“如何将通用软件，变成契合特定一家企业的系统”。这就出现大量边边角角但又特别重要的细碎需求，也是数字化落地的重要卡点。
低代码让这些边角需求的数字化，变得简单。通用系统有了，销售部门、生产部门、财务部门的差异需求，简单的自己也能解决，复杂的再找专业人士。
2、低代码解放了创造力，为企业带来创新的可能。以前，应用是IT或者外包公司来开发，他们可能对行业有一些理解，但依然很难完全理解需求方的想法，比如IT清楚医院科室问诊的大类需求，但无法一一照顾到某一科室的具体情况。那该科室的医生是不是了解？当医生可以随手开发应用，解决自己工作的问题，还可以不断将新需求、新想法补充进来，沉淀、创新的可能性更大。
3、对于个人，是一种高效工作的工具。以上两点更多是从公司的视角来论述，但低代码的受众还是要个人，熟练运用这种工具，可以快速搭建一些日常工作，甚至生活中的小应用，不用“等人帮你解决问题”。
实战体验中，总体来讲用低代码开发一些表单、流程类应用，要比想象中的更加简单。
低代码确实能降低开发的准入门槛，让更加了解业务流程的、但没有编程基础的人有可能参与到应用的构建中，这与“让听得见炮声的人来做决策”异曲同工。
拓展内容：
传统开发与低代码开发流程对比
以“ERP”系统为例，传统应用开发与低代码开发对比
传统的应用程序开发过程：
1、弄清楚要求。
2、规划架构。
3、选择后端框架，一些库，数据存储和任何第三方API。
4、选择一个前端框架并希望在完成开发之前不要弃用它。
5、选择部署堆栈，设置CI，创建运营计划。
6、创建线框和原型。
7、在您选择的JavaScript框架中手动编写UI代码。
8、写一堆失败的测试。
9、定义模型并将它们连接到数据存储。
10、定义然后编写业务逻辑代码。
11、创建将向前端提供或从前端接收必要JSON数据的视图。
12、在您选择的前端框架中实施您的工作流程和UI。
13、使用他们发布的界面集成第三方API，或者，如果幸运的话，使用您选择的语言支持的库。
14、重复直到测试通过。
15、测试安全性，性能，质量和用户接受度。
16、部署，修补，监控，更新，直到应用程序生命周期结束。
低代码开发过程：
1、确定要求。
2、选择任何第三方API。
3、在可视IDE中绘制应用程序的工作流程，数据模型和用户界面。
4、连接您的API，通常使用自动功能发现。
5、如有必要，可以将任何手动代码添加到前端或自定义自动生成的SQL查询。
6、测试用户接受度。
7、部署到生产环境，然后只需单击即可推送更新。
除了低代码开发平台之外，现在还出现了无代码平台，无代码开发平台无需任何代码就可以完成应用程序的开发，很多人觉得低代码和无代码是同样的，但是其实低代码和无代码的区别挺大的，选择平台的时候应该进行区分。
以上。
如果喜欢的可以点赞收藏喔~