低代码平台在解决什么问题?

目前低代码平台如火如荼,低代码平台的优劣。在何种情况下,能够帮助我们解决什么样的问题?又会带来哪些隐患?如何有效控制?

image.png

1、低代码平台

在具体作答之前,需要先搞清楚低代码平台是什么。该名词最早于2014年6月由Forrester Research最先提出。wiki和gartner都给出了低代码平台的定义。

低代码开发平台(low-code development platform,简称LCDP),是一种方便生成应用程序的平台软件,软件提供开发环境,帮助用户以图形化接口以及配置的方式编写程序,而非传统的程序设计作法。
wiki(https://en.wikipedia.org/wiki/Low-code_development_platform)

An LCAP is an application platform that supports rapid application development, deployment, execution and management using declarative, high-level programming abstractions such as model-driven and metadata-based programming languages, and one-step deployments.
gartner(https://www.gartner.com/doc/reprints?id=1-1FKNU1TK&ct=190711)

再结合mendix,阿里-宜搭等低代码平台的描述,可以看到,低代码平台是一个能够为开发者或业务人员提供图形化界面,或配置的方式,快速生成应用程序的平台软件。

2、低代码平台的优劣

在讨论低代码平台的优劣之前,先要分析使用低代码平台进行软件开发的流程是怎样的,与传统开发流程的差异在哪里,其对哪些环节做了优化。

传统,软件开发流程 低代码平台,软件开发的流程
需求定义
架构设计、技术选型
UI设计(页面布局、交互、风格设计等)
基础设施搭建
前端编码
后端编码
功能性需求测试
非功能性需求测试(安全、性能、扩展性等)
应用上线
需求定义
UI设计(页面布局)
基础设施搭建(如果平台提供,则可忽略)
图形化界面,生成应用代码
功能性需求测试
应用上线

对比可以发现,低代码平台对比传统开发方式,在以下开发环节做了优化:

  • UI设计:传统流程中的UI设计,需要对交互、应用风格进行设计。由于低代码平台已经定义通用的组件和组件的交互方式,使用者只需关心页面布局,由此可保证UI的整体一致性,也可减少设计人员的工作量。对于风格的特殊化,部分平台也支持自定义theme。
  • 架构设计、技术选型:传统开发流程中,在项目之初,项目开发者需要了解项目需求和目标,使用DDD等手段拆分微服务,选择适合业务场景的前端后技术栈。由于低代码平台的封装,使用者无需关心平台生成应用背后的技术栈和架构设计,这些早已被平台定制化。
  • 基础设施搭建:传统流程中的基础设施搭建,需要包含前后端项目搭建、CI/CD流水线、数据存储、应用部署。对于部分融合了云平台的低代码产品,例如阿里宜搭,已经提供端到端解决方案,数据存储、环境搭建等,整个基础设施的搭建均不需要使用者关心。对于暂不支持端到端解决方案的低代码平台,仍需使用者准备数据存储和手动部署应用。
  • 图形化界面,生成应用代码:低代码平台通过界面拖拽和配置生成前端代码,通过数据字段映射、通用API、流程引擎的配合生成后端代码,替代了传统软件开发中的前端和后端编码。前端和后端的编码环节,在整个开发流程中占据了主要的成本和时间。低代码平台以图形化界面的开发方式,提高效率,节约成本。
  • 非功能型需求测试:传统开发流程,需要关注应用最终的非功能需求,例如安全性,防止代码中存在安全隐患;或者性能,需要满足多少吞吐量和并发。对于低代码平台,代码的安全性和性能,已经交于平台负责,在使用者选用低代码平台时,应关注平台在该方面的能力,而非在在应用开发后测试。

由此,也可以发现,对比传统的软件开发方式,低代码平台具备以下优势:

  • 提升效率:
    • 利用图形化界面生成代码的方式,减少前端和后端代码工作,缩短开发时间;
    • 组件、功能的复用,避免重复造轮子;
    • 业务人员可以跳过开发,直接从需求到产品;
    • 对于支持端到端解决方案的低代码平台,能够节省基础设施的搭建工作。
  • 降低成本:
    • 低代码平台降低开发人员要求,初级开发人员和业务人员也可以利用平台快速开发应用软件,降低软件开发成本;
    • 由于开发流程的的优化,应用软件开发周期随之缩短,最终降低应用软件开发的支出。
  • 增加灵活性:
    • 人员配置更加灵活,低代码平台降低了使用者的学习成本和使用成本,使得初级开发人员和业务人员也可以开发应用;
    • 业务方面增加灵活性,应用开发达到了所见即所得的效果,便于产品快速试错。
  • 一致用户体验:传统前端开发,UI界面自定义程度较高,再加上多端多团队开发,容易导致UI界面不一致,造成用户体验感下降。
    • 低代码平台内置统一的交互和设计风格,生成应用软件UI高度统一;
    • 页面布局,可根据不同业务场景进行调整。
  • 安全性有保证:
    • 减少了人这一不确定因素的参与。软件开发中,最不稳定因素来源于开发人员,低代码平台对于组件、流程引擎、统一接口等公共功能进行封装,避免重复造轮子,从而也减少了bug产生;
    • 低代码平台已内置统一的安全管控,例如XSS攻击防护、权限管理,从而保证应用软件的整体安全性,无需使用者重点关注。

但同时,低代码平台也存在以下劣势:

  • 适用应用场景有限:
    • 低代码平台一般只针对特定的业务场景,是对部分业务需求中公共部分的抽象,不能满足所有业务场景,并非软件开发的银弹。
    • 自定义程度有所限制,例如布局仅能依靠平台内置布局。用户只能使用预定制的组件构建应用,无法满足高度定制化的需求。
  • 性能负载存在瓶颈:低代码平台所生成应用软件,能够满足通用的性能要求。但随着用户的不断增加,应用软件的性能问题也会随之暴露。
    • 受限于平台生成应用,所使用的架构和技术栈,传统的调整手段和优化方式,例如增加redis缓存,可能并不适用。
  • 学习成本:
    • 存在额外的学习成本,但学习曲线较为平缓。
    • 低代码平台之间无法知识共享。由于低代码平台,自身抽象程度和方式的不同,导致平台之间的使用方式差异较大,不易进行知识共享。
  • 存在合规性问题:
    • 由于低代码平台快速构建应用,在构建过程中,可能会存在一定的合规性问题,缺少必要部门的审核和监管。

3、在何种情况下能够帮助客户解决什么样的问题?

预计到2024年,低代码平台将会参与到65%的应用开发活动。到2024年,75%的低代码平台开发将被局限在非关键型任务、中小型应用。到2024年,75%的大型企业将至少拥有四套低代码开发工具。
--《Low-Code Development Technologies Evaluation Guide》

随着云时代的到来,借助云平台,低代码平台也拥较为广阔的市场。从低代码平台的特征及现有产品,可以发现低代码平台能够解决一些通用性问题,支持一些具备共性的业务场景。但同时也需要注意到,低代码平台也并非银弹,无法解决所有问题。

低代码平台能够解决:

  • 重复开发,耗时耗力:在非核心业务场景,存在大量相似场景,例如表单应用,此类应用开发难度较低、但开发成本高、周期长。在该场景下,利用低代码平台,较少的开发人员和业务人员,可以在较短时间内生成应用。从而帮助客户解决相似功能应用重复开发,耗时耗力的问题。
  • 快速验证和试错:对于部分核心场景,低代码平台可以利用其低成本、高效率的优势,帮助客户生成试验版本,在市场中进行快速验证或试错。帮助客户以往试错成本高,无法紧跟市场变化的问题。
  • 快速应对临时业务:对于临时业务,例如疫情期间的打卡程序,传统开发方式耗费人力和时间,且ROI较低。可以通过低代码平台,快速生成应用,避免过大的成本投入。帮助客户解决临时业务高成本、低产出的问题。

4、低代码平台会带来哪些隐患?如何有效控制?

低代码平台可能存在的隐患,需要透过低代码平台的核心和技术发现。
低代码平台的核心之一是,对业务的一层抽象。我们知道软件开发需要随着市场需求变化,需要高度的定制化。但是基于一个特定领域的定制化需求,也是能够抽取出共性的。例如表单应用,虽然字段、交互、审批流程有差异,但基本业务流程是一致的,设计表单、填写表单、审批、展示。针对这一特定领域的低代码平台,便可以通过逻辑和规则编排出定制化的表单应用。
低代码平台的另一个核心是对编码做一层封装,低代码平台上的界面组装、组件拖拉拽、流程设计、数据结构设计,就是这层封装表现。
实现这层封装,就需要借助DSL和语言解释器。DSL是领域特定语言,用于对特定领域进行描述,语言解释器是对DSL的翻译,既可以将DSL翻译为机器能够理解的代码,亦可以将用户的界面操作翻译为DSL。DSL和语言解释器应成对出现。
一个低代码平台的DSL可能由多种,常见的可能有

  • UI的DSL(包含元素、样式、布局等)
  • 数据结构的DSL
  • 流程引擎的DSL

借助DSL,低代码平台可以实现代码、组件、项目的复用。将复用的组件和代码,使用逻辑和规则进行编排,便生成应用软件。这种方式的复用和编排,有利于降低新建应用软件的复杂度,这也是低代码平台能够做到提升效率,降低成本的核心所在。

外购第三方低代码平台

“业务的复杂度不会消失,只会转移。”利用低代码平台快速生成应用软件,也是把业务复杂度从编码转移到低代码平台中。但正是这层转移,使得外购第三方的低代码平台成为一个可选项。如此,便可以省去己方的开发复杂度,进而节省资源和人力成本。
但同时,利用第三方平台也存在以下风险,需要注意:

  • 厂商捆绑的风险。DSL和语言解释器大多是黑盒,内部的实现逻辑各个平台各不相同,且现阶段并没有通用协议规范。风险发生时,轻则无法更新应用软件(低代码平台只生成代码),重则在低代码平台上运营的应用软件均无法使用(使用低代码平台的端到端解决方案)。可以通过以下方式缓解和预防该风险。
    • 选用多个低代码平台,均摊风险。《Low-Code Development Technologies Evaluation Guide》报告中也提到,到2024年,75%的大型企业将拥有多套低代码工具。多vendor的方式可以形成有效的竞争,避免一家独大。即使风险发生,也可以做到快速切换。
    • 选择非核心业务场景生成应用,以此降低风险影响。即使风险发生,此类应用不涉及企业核心领域,可以保证充足时间,寻找替换方案。
    • 低代码平台私有化部署。私有化部署,可以降低风险的影响,保证已有已有应用能够正常运行和更新,数据也由己方掌控。风险发生时,也只会影响到低代码平台本身的升级和厂商支持。
    • 也可通过自建的方式,避免厂商捆绑。
  • 技术风险
    • 版本支持方式。随着低代码平台升级,DSL和语言解释器也会随之升级。需要提前确认,版本兼容性,以及应用软件升级策略。
    • 第三方集成。应用软件开发,需要与大量三方系统集成,低代码平台需要提供较为易用的第三方集成方式。
    • 业务边界。由于低代码平台,具有一定的局限性。需要提前了解厂商产品的业务边界,确认是否符合己方要求。
  • 其他风险
    • 性能风险,选用厂商时,应提前了解生成应用软件的性能极限,例如最大用户并发、数据表最大容量,和适用的性能调优手段,例如是否支持横向扩展。进而帮助己方选择适用场景。
    • 安全风险,提前了解厂商产品的安全防护策略,以及判断是否满足企业自身的合规性要求。例如端到端解决方案,是否提供多套环境,支持企业内部的验收和审查。

自建低代码平台

通过自建低代码平台的方式,可以避免第三方的风险,但同时也将业务复杂度转移到企业内部。在自建低代码平台时,需要关注以下风险

  • 建设大而全的平台风险。平台建设之初,应确立低代码平台关注的问题,确定业务边界。
    • 确定低代码平台建设的针对领域,解决该领域的通用性问题。对于非该领域问题,应避免纳入平台,以免成为大而全的平台,增加维护成本和开发成本。例如图表展示功能,并非低代码平台的核心域,可以借助第三方平台完成,以teablue等第三方平台通过iframe嵌入的方式支持。
    • DSL设计粒度。例如组件粒度设计不够细,无法满足用户需要;设计的太细,维护和开发成本高。1、应满足大多数应用场景,对于ROI较低的场景,可以结合流程引擎和少量代码完成。2、引入用户扩展组件功能,用户可以在原有组件基础上,自行扩展,自行维护。
    • 第三方对接。应用软件不再是单独存在,它需要借助不同应用的能力,才能实现业务价值。对于低代码平台而言,需要设计良好的第三方对接方式,便于利用不同应用的能力。
  • 平台升级,旧版本应用无法兼容的风险。平台升级后,DSL和语言解释器也需随之升级,版本兼容需要一定的策略,平衡兼容性和可维护性。
    • 小版本兼容。保留旧版本语法解释器,或者兼容旧版本DSL,保证小版本的兼容。
    • 不支持跨大版本兼容。1、保证就应用继续使用,但不允许导入平台继续修改。2、提供旧版本应用升级策略或升级脚本。
  • 性能风险
    • 低代码平台所生成的应用,在用户增加时,可能会存在性能下降的问题。解决性能问题的方式,与平台构建应用的模型强相关,有一定的特殊性和局限性。1、提前预测应用的性能需求,对于高性能要求的应用应避免使用低代码平台生成。2、可以增加应用横向扩展的功能,储备性能提升预案和方法。
    • 对于核心场景或者ToC应用的试验场景,需要提示开发者,平台所产生的应用可以达到的最大性能。
  • 资源浪费的风险。低代码平台可快速构建和部署,会存在大量无用应用,造成资源浪费。
    • serverless方式部署应用,避免应用长期占用资源。
    • 以制度管控加成本核算的方式,提高资源利用率。

5、结论

  • 云时代,低代码平台市场更加广阔,除第三方低代码平台外,企业自建平台需求巨大。
  • 低代码平台的核心在于对特定领域的业务抽象对代码的封装。这层封装主要以DSL语言解释器实现。
  • 低代码平台同时也是对代码的复用,可以有效降低成本、提高效率。
  • 低代码平台,需要明确应用场景,避免大而全的产品。

参考文章

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,445评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,889评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,047评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,760评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,745评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,638评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,011评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,669评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,923评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,655评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,740评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,406评论 4 320
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,995评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,961评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,023评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,483评论 2 342

推荐阅读更多精彩内容