低代码热度不断……
编码更少、交付更快、成本更低,并覆盖软件开发全生命周期,怎么看低代码都是个不错的软件开发工具。可为什么它总会引发争议,甚至被主要用户群体之一——程序员所诟病呢?
技术浪潮引发巨大变革,也带来了无数“取代论”,比如机器翻译是否取代人类翻译、机器人记者是否取代人类记者,以及低代码开发是否取代程序员。
答案是否定的。低代码平台不会取代专业开发者,相比于平民开发者,专业开发者依然有着很强的优势。但这一发现并不能真正将开发者变成低代码的支持者,尤其是当他们第一次开始尝试去了解低代码的时候。
粗略总结,开发者对低代码平台所见即所得设计器有两种反应:
A:“天呐,看看我能以多快的速度开发出了xxx!”有相当一部分人在感叹低代码技术为开发软件带来的快速便捷。但还有另一种更为突出的反应。
B:“我不相信有人能用这个搞出yyy!”有人担心它担不住开发关键任务带来的风险,比如平台不稳定、开发进度过半有问题无法解决等等。
以上两种看法看起来并无毛病。归根到底,是因为这样一个具有普遍性的基本事实:低代码的确大幅提升了应用系统中“70%~80%部分”的开发效率(六到十几倍),但是,针对应用开发中?20~30%的重要或关键需求,低代码开发无法满足。但总体而言它的利会大于弊。
低代码开发过程常被比作拼积木:像拼搭积木一样,以可视化的方式,通过拖拉拽组件快速开发出数据填报、流程审批等应用程序,满足企业里比较简单的办公需求。
还有诸如:
这些关键能力表明低代码平台在建模与逻辑方面具备较强的能力,而接口和集成能力可使专业开发人员完成低代码无法实现的部分,通过低代码与专业代码开发的协作实现复杂应用的开发。
在选择开发工具时,程序员通常考虑的首要问题是:这款工具能否覆盖所有需求?如果需求增加或变更,该工具是否支持相关操作?这些问题同样适用于低代码平台的选型。
在实际项目交付过程中,如果我们仅可以满足90%的需求,另外10%的需求满足不了,那么真实用户大概率是不会买单的。因此,在评估低代码产品的时候,我们一定要保证该平台可以支撑所有系统模块类型的开发,同时也要具备足够的扩展性,确保使用纯代码开发出的模块能够与低代码模块进行无缝集成,而这离不开编程接口。
以国内主流低代码开发平台JNPF为例。该平台提供开箱即用的开发组件,同时为系统的各个分层均提供编程扩展能力,以满足企业级应用开发对扩展性的高要求。借助分层编程接口,开发者可以用纯代码的方式实现新增功能,无需受限于低代码开发平台的版本和现有功能。
采用的是最新主流前后分离框架(SpringBoot+Mybatis-plus+Ant-Design+Vue3)。代码生成器依赖性低,灵活的扩展能力,可灵活实现二次开发。
为了支撑更高技术要求的应用开发,从数据库建模、Web?API构建到页面设计,与传统软件开发几乎没有差异,只是通过低代码可视化模式,减少了构建“增删改查”功能的重复劳动,还没有了解过低代码的伙伴可以尝试了解一下。
从根本上说,使用低代码来构建软件和以其他方式构建软件没有什么不同。
使用低代码开发,你可以尽量避免那些不必要的工作。比如,你无需手动编写另一个用户和权限管理模块,无需处理最新编程框架的特性,也无需在编写第一行应用程序代码之前先写上十个测试方法,而是可以直接创造新的、有价值的东西。
毕竟,基于平台,那些问题都已经被解决过且其固有模式被充分接受时,您何必还要再重复操作一遍?
当迷雾散尽,低代码开发平台重新露出高效率开发工具的本色时,你会选择它吗?