【世界新要闻】渗透率仅有1%,低代码怎么就不受企业待见
“转码”无疑是最近这几年在年轻人中广泛谈论的一个话题,而计算机科学(computer science)也更是被称为“宇宙机”。但这一切的基础,是过去二十余年间互联网成为了全球经济增长的重要引擎,作为互联网产业的基础,程序员自然也就吃到了时代的红利。
然而随着互联网行业寒冬期的到来,降本增效、开源节流几乎成为了全球互联网厂商共同的应对措施,甚至高薪酬程序员的“35岁危机”一下子似乎变成了现实。但问题是程序员的门槛并不低,并且还是互联网企业的刚需,那么有没有一种既能保障代码的产能、又可能降低成本的解决方案呢?答案其实是有的,而这就是自两三年前开始变得火热的“低代码(LowCode)”概念。
(资料图片)
只需少量代码、甚至无需代码即可完成开发工作,这是许多低代码平台描绘给企业用户的图景,看起来似乎厂商也有了可以不用高薪酬程序员的机会。可事实却是,即便全球权威咨询机构Gartner给出了在2021年至2026年间,中国LCAP(低代码应用平台)市场收入将以25.4%的复合年增长率加速增长这一乐观预估,但从其他机构的统计数据来看,目前低代码软件在企业软件市场的渗透率还不到1%。
那么问题就来了,低代码平台描述的未来是如此美好、又非常契合企业的需求,那么企业用户怎么就不买账呢?
为此,首先不妨来看看低代码本身。即使Java、C++、python等经过计算机科学成熟阶段出现的“高级语言”,它们即便与自然语言相接近,且能为计算机所接受的语意确定、规则明确、自然直观,但它们始终是抽象的,代码和代码能实现的效果自然也不可等而视之。
作为与传统计算机语言对应的存在,低代码的表现形式是“可视化编程”、核心则为“代码复用”,通过可视化、模块化、拖拽式的特性,来代替传统开发方式中大量编写代码进行开发。在低代码的概念中,模块化组件代替了编程语言中一行行的代码,而可视化的设计则让抽象思维变成了更容易理解的搭积木。
简单来说,程序员就相当于是饭店里的厨师,是通过手艺来做出合格的菜品,而低代码平台则相当于是提供预制菜,生产的是完全没有厨艺的消费者也能上手的半成品食物。既然预制菜能火、低代码显然也有爆发的理由,并且低代码确实从一定程度上降低了编程的门槛,即便不具备编程技能的“小白”也能参与到开发过程中。
根据Gartner公布的相关数据显示,APP开发服务的市场需求增长速度至少是目前全球IT交付能力的5倍,而低代码则可以帮助软件开发者填补这一缺口,让用户能够自己开发系统解决方案。特别是在此次疫情加速的数字化进程中 ,低代码更是能够帮助相当多的传统企业完成数字化转型,以便企业能够对不断变换风向的市场做出即时反应、适应新的市场环境,并最终换取竞争优势。
甚至于对互联网厂商而言,低代码也有着不可或缺的意义。众所周知,“996”就是从互联网行业流传出来的,而这背后反映的是互联网厂商面对日新月异的市场环境,只能通过堆积人力的方式来加快项目的交付、以实现快人一步的效果。除了996这样明显不科学的策略,“敏捷开发”这样一个将项目的构建切分成多个子项目,以实现小步快跑、快速迭代的方式也被广泛应用。
即便敏捷开发思想的出现加速了互联网产品的完成速度,但依然满足不了厂商的需求,到目前为止,互联网行业都是加班问题的重灾区。这是因为敏捷开发尽管能够提升效率、但这还不够,低代码的出现不只是让专业开发人员的进度更快,还可以让业务人员也参与到开发应用中。
但非常遗憾的是,低代码的一大问题就是“中看不中用”,并且仅仅这一个问题就阻碍了低代码在企业级用户中的普及。由于低代码的目标是让更多非专业人士也有参与到应用开发项目中的能力,为了实现这一点,低代码平台将过去代码开发过程进行抽象、并形成可配置的各类组件,再通过添加组件和配置组件即可实现系统开发。但问题也出在了这里,低代码为了实现普惠价值而顾此失彼。
虽然模块化开发听起来很潮,但将不同代码实现的功能模块化、通用化的代价,就是精确性下降。毕竟在低代码平台呈现给开发者的是不再是一行行代码,而是一个个用以实现不同功能的模块化组件,就像是预制菜的味道无论如何比不了正规餐厅一样,最终呈现出的是通过低代码平台做出的应用,在性能上就是弱于传统开发的同款产品。
要知道,在如今这样市场竞争极为激烈的互联网行业,如果最起码的用户体验都无法保证,那么再好的创意也会被浪费。仅仅是这一条,就会让相当多的企业对低代码望而却步。再说了,低代码平台通常采用组件式开发,应用组件相当于“黑盒”,企业用户再次开发时如果不使用原先的低代码平台,就需要重新梳理理解代码、重新编程,这就代表企业与低代码平台的捆绑性极强,而这也会被企业用户所警惕。
换而言之,在目前低代码开发无法媲美传统开发方式的情况下,企业用户显然更倾向于维持现状。
标签: