写点什么

低代码开发,老树开新芽?

2021 年 9 月 01 日

低代码开发,老树开新芽?

在 2021 年年初,InfoQ 发布了 2021 年的技术预测文章,其中就谈到了低代码 / 无代码将扩展,加快应用开发,业界很多无代码 / 低代码平台在专业领域有了应用,例如:无代码人工智能、无代码机器学习等等。


但是任何一项技术在开枝散叶过程中,难免会遇到各种质疑、阻碍,但随着在降本提效、增质方面发挥促进作用,那跨过技术生命采用周期里的鸿沟只是时间迟早的问题。


今年首场技术会议 ArchSummit 全球架构师峰会,将于 4 月 25-26 日在上海举办,这里面就包含低代码 / 无代码实践专题。陈阳 Younger 老师拥有 10 年以上互联网架构技术经验,国内低代码开发倡导者和推进者,担任了此专题的出品人。关于技术在落地应用层面会出现哪些问题,有幸请到他来回答。以下是整理内容,以飨读者。

对低代码 / 无代码平台的认知误区


近年来,低代码越来越火。整个业界也有各种各样的声音,对低代码存在的误区无外乎以下这几个方面:


1- 误认为低代码是一个全新的概念或技术,其实不然。事实上,早在 20 年前就已经出现低代码模式了。因为近年来,在数字化转型浪潮、人口红利消失等大背景下,需求越来越丰富多变,甚至新冠疫情也冲击了原有协作模式、商业模式等等,对 IT 互联网开发在“降本、提效、增质”方面要求越来越高,国内外也涌现出了相应的低代码平台及解决方案。特别是国外的 OutSystems 宣布获得 3.6 亿美元投资和估值过 10 亿美元,低代码平台 Mendix 被西门子 7 亿美元收购,这两个事情进一步把低代码推到了风口。在 Gartner 2020 的企业低代码应用平台魔力象限图中,Mendix 与 OutSystems、Salesforce、微软等共同处于领导者象限。


图:企业低代码应用平台的魔力象限,资料来源:Gartner(2020 年 9 月)


2- 低代码 / 无代码其实是一个比较广的范围,这里视野要看得广一些,比如不要认为可视化与低代码是完全的等号,可视化只是低代码的一种展现形式。一些优秀的低代码开发平台,基本上是贯穿了系统的各层架构、行业应用主要场景、研发全过程、工作全流程等;比如微软的 Power Platform,以企业数字化全局为出发点,集成了 Office365、Azure、Dynamics 365 等,包含其所谓的“四大天王”:Power Apps(应用开发)、Power BI(业务分析)、Power Automate(流程自动化)、Power Virtual Agents(智能虚拟代理)。


3- 误认为低代码开发平台的建设很容易、没有门槛,其实也不然。低代码开发平台的使用门槛低,但建设门槛并不低,甚至很高,背后需要很多丰富的组件及技术沉淀。比如 Mendix 是在 2005 年就成立了,用更快、更简单的方式来驱动客户体验和运营效率;而 OutSystems 在 2001 年就成立了,专注于改变企业软件的交付方式。包括国内比较出色的在低代码领域也有十年以上的累积沉淀。


4- 误认为低代码是万能的,能代替一切,能像神一样解决一切痛点。这种观点就太过头了啊。我们看待任何一种技术或概念,都要客观、清醒、结合实际场景来看待。不要太过于炒作和神话了。


5- 误认为低代码是万万不能的或者没啥价值。这个观点和前面一种观点,都是属于太极端的。低代码有很多非常优秀的落地实践,前面说的 OutSystems、Mendix、微软等就能说明了。这里就不多讲了,本次峰会的低代码专题会有技术大牛为大家带来精彩分享。

低代码 / 无代码的先天不足


低代码 / 无代码在国外的应用情况还是比较好的,国内相对来说还比较落后。主要原因无非是行业场景、文化观念、成本、生态等因素。


行业场景多且复杂,很难有一个通用的平台能覆盖所有行业、满足所有用户需求。目前受欢迎的更多的还是各个垂直领域的平台。


观念及文化的差异。低代码 / 无代码将是目前开发结构上的一种新的补充,让开发人员能够有更多精力聚焦业务逻辑及创新。比较乐观的是,国内已有不少企业或项目在专注或重点布局低代码,甚至组织架构也有相应的变化调整。


学习成本和体验不协调。低代码平台虽然不用学习专业的计算机编程,但还是有学习成本的。包括体验方面也得关注。举个常见的例子,在应用功能非常庞大复杂时,可视化图形会不会因为太巨大反而无法可视或者操作卡顿等等;会不会不如‘show me the pro-code’。所以,对于功能丰富强大的低代码平台来说,如何持续优化学习成本和体验也将是关键的挑战。


目前,除了缺乏学习资料、视频等社区支持外,还缺少活跃的低代码生态。低代码平台要想越走越好,构建生态必不可少,这个生态里需要包括低代码平台厂商、低代码代理销售伙伴、低代码应用开发人员、低代码培训和服务商、低代码用户、低代码应用市场等等。

低代码 / 无代码技术的适用范围


陈阳老师说,低代码适用范围没有特别的局限性,如所处行业数字化转型面临的需求场景丰富,业务运营创新节奏快,或者“需要更迅速试错的”,比较适合使用低代码。


有些团队缺少专业开发人力,可以通过低代码 / 无代码减少开发人力成本的。此外还有较多重复人工操作流程的团队适用低代码。


从业务需求策划到最终开发完成、测试上线的整个流转环节过多、链路过长的,可以通过低代码 / 无代码减少不必要的环节。陈阳强调说,无代码其实属于低代码的一种特例或升级。某些企业的非开发人员,也在通过无代码平台做一些开发工作。所以,低代码无代码,是直接让‘思考的过程’变成‘创造的过程’。


最后,像行业解决方案或 SaaS 的提供商等比较适合使用,低代码 / 无代码在某种程度上说逐渐成为 SaaS 提供商的必备高效工具。

低代码平台选型注意事项


对于是自己开发低代码平台,还是采购外部平台这个问题,这需要按团队类型、需求和技术角度去考虑。


如果是平台提供方,其客户的需求与日俱增、运营创新压力大,而且平台自身也沉淀了足够的技术及服务组件等,是非常有必要开发低代码 / 无代码平台,赋能客户,让客户能有更多精力聚焦在其自身业务逻辑和运营创新上。


如果是平台使用方,若面临数字转型与运营创新压力、开发人力匮乏等情况,可以考虑采用业界低代码 / 无代码平台。在选型的时候,一般可以从以下几个因素考虑:


  1. 所处行业及诉求。比如服务聚合、工作流、数据流、应用逻辑流、ERP、BSS、CRM、Web 应用、原生应用、小程序、游戏等,每一项都有比较擅长的低代码平台提供方。

  2. 平台经验及开放性。低代码平台 / 无代码提供方的所能支持行业、以往成功案例经验,技术及服务沉淀情况等。建议选择与自己行业匹配、诉求匹配,且有多年相关沉淀、平台自身的二次开发也足够开放的平台。

  3. 自身数据敏感性。对于数据保密有严格要求的企业,考虑支持私有云部署的平台。

  4. 平台生态。低代码 / 无代码平台的生态建设情况,建议考虑生态更完善更活跃的平台。

  5. 平台未来规划。所选择平台,一定要是一个计划长期持续发展的平台,有较为清晰的发展规划,能帮助客户持续发展的。


之前在看相关介绍的时候,也注意到,其实有很多团队或者技术人并没有快速尝试低代码,原因无外乎低代码平台不好用,低代码 / 低开发不可控,低代码应用难以维护等等。那么到底该如何使用呢?在实现一套低代码 / 无代码开发的“流程引擎”,有哪些关键步骤 / 因素 / 技术?


其实这些问题,也是低代码 / 无代码平台发展中必须要面临的几个重要挑战。作为低代码 / 无代码平台,在开发过程中常见的几个注意点:


  1. 平台的体验。操作需要足够简单、清晰、便捷,学习手册视频需要足够简明易懂。

  2. 平台的表达性、可视可读性。前面也提了一个常见的例子,在应用功能庞大复杂时,有些低代码平台的可视图太大,并无法可视甚至操作十分卡顿,会让使用人员非常痛苦。

  3. 平台的多人协作性,能够支持多人在线开发。

  4. 平台自身的开放性,二次开发是否友好。在需要更多定制化功能时,是否有足够的二次开发能力供开发人员个性化扩展。

  5. 平台的可靠稳健性。低代码无代码平台,需要真正做到“Less code,less bug;No code,no bug”。

  6. 问题及故障善后工具。需要有完善的监控告警系统,在出现问题时,也需要有相关的日志跟踪、问题快速定位工具、故障善后工具等,能够快速查明真相,处理故障善后事宜。


图:一码多端


另外关于“流程引擎”,可以再分工作流引擎、数据流引擎、应用逻辑流引擎等等。工作流引擎、数据流引擎在市面上有较多不错的案例,比如开源的 CCFlow BPM 工作流引擎。这里大概说一下应用逻辑流引擎。


随着互联网业务的蓬勃发展、数字化经济的繁荣,业务运营应用变得频繁,所以也诞生了相应的应用逻辑流程引擎。应用逻辑流程引擎,最终会面对的是 C 端海量用户,关键点包括有:管理端的流程可视化、页面可视化、简易的 DSL、数据建模、Mock 测试、用户资源管理、运营管理等等,用户端的一码多端技术(可以一次开发,多终端运行)、后台权限控制(账号体系及登陆鉴权、安全防刷等)、流程节点解析执行引擎、分布式节点事务引擎等等。


图:支持全球化


如果涉及全球化的,还得支持多语言,海内外账号差异环境差异,能做到一次开发全球支持。总的来说,在安全性能上也提出了更高的要求。

制定一套新的低代码参考标准


虽然低代码应用在不同行业场景不同领域,但低代码 2.0 有一些共同特性,覆盖全研发过程、涉及系统各层架构等。比如以云原生为基础,都具备基础的云端 WebIDE 快速扩展、领域 DSL、前端可视化开发、后台逻辑流程的可视化开发、数据建模工具等等;比如 Gartner 报告里的低代码相关技术,包括 iBPMS 智能业务流程管理套件、多重体验开发(MDXP)、机器人流程自动化(RPA)、快速移动应用开发工具(RMAD)等。


可以将业务逻辑剥离后,抽出一些通用基础技术模块,并制定相应的扩展规范。需要业界能够贡献开源出一些不错的基础模块、认可统一的通用协议等等,以及共同打造活跃的低代码社区。这个还有很多路要走,也会有很多挑战。


Gartner 数据预测,到 2024 年,65% 的应用程序开发将是低代码。到 2023 年,超过 50%的大中型企业将采用低代码应用程序平台(LCAP)作为其战略应用平台之一。


在国内,这两年将可能迎来低代码的井喷现象;一些重复的流程、低价值的开发或大部分应用,将不再是纯人工开发;与底层较近的工作、多端的差异开发等,也会由低代码屏蔽;低代码开发将会成为一种新的能力和广泛使用的生产方式,也进一步加速数字化转型和业务运营创新。


总的来说,低代码将掀起新的开发浪潮,但不只是替换或取代,更多的是补充和创造更多可能性。


低代码很美很有想象空间,但最后,陈阳还想给低代码泼一下冷水,低代码还有很多槽点与不足。我们需要时刻保持客观、清醒的态度看待每一个技术概念风口,要从解决实际痛点和产生实践效益出发,才能让低代码健康地、可持续发展下去。


更多低代码话题,可以关注 2021 年 12 月 3-4 日北京ArchSummit架构师峰会会议上的演讲议题。

2021 年 9 月 01 日 00:00749

评论

发布
暂无评论
发现更多内容

week01-学习心得

强哥

极客大学架构师训练营

作业一:食堂就餐卡系统设计

飞翔的风

食堂就餐卡系统设计

逍遥乐天

week0-作业一

徐培

作业二:根据当周学习情况,完成一篇学习总结

飞翔的风

架构师训练营 - Task Week 1

brave heart

极客大学架构师训练营

就餐卡系统设计文档 【第一周】

mylove321

【架构课笔记-第一周】一般方法与设计文档

Nelson

食堂就餐卡系统设计

yupi

架构师训练营 第一周 作业

极客大学架构师训练营

就餐系统架构设计

草原上的奔跑

极客大学架构师训练营

架构学习作业-食堂就餐卡系统架构

乐天

就餐卡系统架构设计文档

gen_jin

第一周作业(1)

佳明

《架构师训练营》--第一周命题作业

极客大学架构师训练营

【架构师训练营 - week1 -2】学习总结

早睡早起

关于架构师的理解(第一周学习总结)

关于架构师的一点理解

石刻掌纹

读笔 | 为什么“杨丽萍”们的生活被指责

张鸱鸺

读书笔记 心灵圣经 生活方式

第一周作业

仪轩

架构师训练营 第1周总结

Lingjun

极客大学架构师训练营

架构0期作业1

Nan Jiang

极客时间-作业一-食堂就餐卡系统设计

刘柯

食堂就餐卡系统设计

weijin

架构师训练营第一周学习总结

JUN

食堂就餐卡系统设计

跨域刀

极客大学架构师训练营

架构师训练Week1 - 学习总结

伊利是个圈

学习 极客大学架构师训练营

第一周总结

gen_jin

架构训练营第一周-作业

无心水

第一周作业(2)

佳明

信息的表示与存储-浮点数的表示

引花眠

计算机基础

低代码开发,老树开新芽?-InfoQ