当前位置: 首页 > 科技观察

低代码的兴起,程序员应该拒绝还是拥抱

时间:2023-03-21 19:47:54 科技观察

低代码是近年来兴起的一种企业软件快速开发技术和工具。借助低代码用户,无需编码即可完成企业应用的常用功能,用少量编码扩展更多功能。低代码以其低门槛、高效率、易集成等特点受到越来越多软件开发团队的青睐。Gartner预测,到2024年,四分之三的大型企业将至少使用四种低代码开发平台进行信息应用开发。到那时,65%的应用程序开发将通过低代码完成。面对低代码的兴起,程序员有几种不同的心态:一种是轻视,认为低代码技术不能优雅,只是初学者的小把戏,解决不了复杂的技术问题;一是恐惧心理,担心低代码会取代专业开发人员,淘汰大部分程序员的工作;另一种是抗拒心态,认为低代码平台就是一个黑盒子,非常危险,不稳定因素很多。无法保证迭代升级;还有一种失落感,认为有了低代码的开发工具,程序员不再需要掌握高深的技术,工作中也失去了成就感。作为一名资深程序员,经过两年对各种低代码平台的了解,我想谈谈我对低代码平台兴起的个人看法。低代码平台的代表企业有国外的OutSystems、Mendix等,国内的企业有奥哲网络(TriumCloud)、ClickPaaS、灵马、易创科技、炎黄映动、数视科技、清流、达达云、小黑等低代码初创企业像Payun,还有APICloud、明道云等已经向低代码领域延伸或转型的初创公司,以及大企业的业务模块,如帆软的简刀云、阿里的易到。低代码开发平台按照技术路径架构可以分为三类:一类是基于表单/引擎驱动的模式,通过创建多个表单,使用流程系列,定义报表输出方式,构建基于表单的方式光应用。这类模式技术门槛不高,主要支持基于表单的应用开发,场景有一定的局限性。比较适合简单的短信项目,不适合长期迭代的产品开发,尤其是产品要满足多样化的需求,必须具备高配置属性的时候。比如表单展示,同一个进程不同位置看到的表单是一样的,不能对敏感信息进行差异化展示,不可能做到千面。此类平台包括:清流、达达云、阿里的亿达、易创科技等。一种是基于aPaaS平台模式,包括模型驱动、代码生成、可视化编程等多种具体技术手段和路径。.,底层技术涉及云原生、元数据、多租户等。该类模型技术壁垒更高,粒度更细,复杂度和灵活性更高,能够支持广泛场景下的复杂应用开发,具有服务大客户和中小客户的能力。这种模式面对复杂的场景还是需要写逻辑代码的。尤其是高并发的应用场景,需要投入大量的后端软件开发。此类平台包括:OutSystems、Mendix、奥哲网络(氚云)、ClickPaaS、炎黄映动、数视科技、黑扒云??等,还有一类是基于aPaaS+iPaaS的平台模式。这类低代码平台不仅由可视化模型驱动,而且由代码编译自动生成。无论是前端组件还是后端业务逻辑都可以细粒度的构建,实现高度复杂和灵活的应用场景。.这类平台的iPaaS部分属于领域驱动设计模式,其核心概念:领域、子领域、领域实体、价值对象、领域服务、领域事件等是图形化解决复杂问题的自然表达方式。应用场景可支持aPaaS可视化构建,可视化集成各种业务应用,适应任何高并发应用场景。此类平台包括:灵码PaaS。每个低代码平台都有自己的价值。虽然第一类平台的使用范围比较狭窄,但是程序员们不要对此嗤之以鼻。此类平台特别适合不懂软件的业务实施人员,可以快速响应简单业务调整的个性化需求;对于复杂业务场景的实现,虽然二类平台可以通过可视化的方式构建大部分功能,但是很多数值模型和业务流程模型的构建仍然离不开专业程序员的逻辑抽象能力,尤其是很多复杂的算法逻辑和后台系统架构的构建仍然需要使用源码实现。即使第三类平台可以完全摒弃源代码,图形化构建任何复杂应用,同理,开发者也必须具备面向对象的逻辑思维,以图形化方式构建领域实体、价值对象、领域服务、领域事件,通过连接建立这些元素的逻辑关系。事实上,所有这些平台都只是一个工具,为程序员解决了以下问题:1.提供了大量常用的标准组件和功能;2.以图形方式替换原有的计算逻辑;各种数据模型;4、以图形方式建立各种业务对象;5、以图形化的方式实现界面的布局;6.以有向连接的形式建立计算逻辑与业务对象的关联;7、实现基本语法逻辑的自动识别。这样,程序员就可以从类代码逻辑中解放出来,所有的图灵完备机制都以图形化的方式呈现出来,更加直观。它还可以自动识别大部分语法逻辑并减少错误数量。并通过定义组件标准接口,提高组件复用效率。让软件开发效率有革命性的提高。因此,不用担心程序员的工作被淘汰。Lowcode只是专业开发者更方便、更高效的工具。还有一种态度认为,这些低代码开发平台是危险的黑盒,承担不起在不可控的“黑盒”上开发关键任务的风险,比如平台不稳定怎么办,中途发现问题开发进度解决不了怎么办,升级迭代实现不了怎么办等等。首先,这个逻辑似乎是合理的,所以我会花更多的篇幅来解释为什么这种抵制是不合理的。首先,低代码黑盒运行在开发者熟悉的技术栈上,而这些技术栈与低代码相似,也经历了一个逐渐被人知道、被爱、被鄙视、又被爱的过程。例如,低代码开发平台后端底层技术架构采用C++,后端业务逻辑采用NodeJS,前端采用JavaScript,Android和IOS采用Flutter。这些技术栈保证了低代码开发平台本身的稳定性和可靠性。更重要的是,所有的低代码平台都经过内部反复测试,有大量的应用实践,等足够成熟的时候才会推向市场。其实我们都很喜欢“黑盒子”,尤其是黑盒子,可以为我们节省很多时间。Java及其姊妹语言Scala、Groovy和其他语言依赖于最受开发人员欢迎的黑盒:JVM;而C#和VB.net则依赖于.netFramework来运行。那么,为什么我们信任JVM、.net而不是低代码呢?因为时间会证明这些平台。在2000年代初,.net诞生时也受到了开发者社区的严格审查。但在看到它年复一年地顺利运行后,信任度增加了。开发人员知道C#和.net仍将存在很长时间,Microsoft将继续支持两者。我不知道Microsoft将如何实现我的C#,但我仍然相信它。就像我信任V8引擎来执行我的JavaScript和JVM来执行我的Java一样。当然,我也不能忘记我曾经依赖的其他著名黑盒:Spread、KendoUI、ActiveReport等前端控件。也正是因为有这些控件,才让我们的应用开发效率提高了好几倍。如果你一直从事程序界面的开发,相信你也会和我有同感。事实上,低代码并不是近两年才诞生的技术,而是近几年才引起更多媒体的关注。十年来,太多的案例证明了这个“黑匣子”的真正实力。应用场景从MES、ERP到SCM、SCRM。终端平台还支持PC浏览器、APP、微信、钉钉。所以,也许是时候让低代码对这个不太新的黑盒子更有信心了。另外我们程序员中有很多技术控,喜欢钻研各种高深的技术。确实,技术的积累可以在某些方面提升技术人员的价值。但是有很多技术已经流行起来,平台化了,所以程序员不用重新发明轮子,用起来方便就行了。低代码平台是一个大平台,屏蔽了很多复杂的技术。例如,奇奇PaaS系统实现了基于领域驱动的微服务架构的所有技术,包括:业务流引擎、分布式事务处理、分布式数据交互、异地多Activity。灾备处理、高并发负载均衡、安全与认证机制、微服务健康检测等,程序员只需拖拽、绘制、连接,简单配置即可调用平台提供的技术接口,轻松解决以前需要高超技术人才才能解决的问题。那么,是不是有了低代码平台,开发工作就不需要技术专家了?这种问题不存在,但技术专家的侧重点需要改变。他们不再需要关注系统端的技术,而是更关注业务端的抽象能力。例如:如何从领域实体树中抽象出一组业务需求并定义领域,子领域之间的关系,以及每个领域实体中值对象、领域服务、领域事件的定义。对业务的理解能力、领域驱动知识的积累、对领域实体的抽象能力、对算法的逻辑思考能力,也能把技术专家发挥到极致。当一个熟练的人完成了一个业务系统的技术图纸,以前需要996小时才能工作几个月的系统,使用低代码平台后短短几周就被你征服了,就像首席设计师一样的摩天大楼。悠闲的感觉。总之,技术专家是不可替代的。程序员除了要对代码低头,还要学会抬头看路。时代在发展,我们不仅要跟上时代的步伐,有时候还需要比别人有更长远的眼光,时刻保持一颗好奇的心,和不断学习发现新事物的热情。而不是不加思索、不加理解地抗拒或害怕新事物的出现。大多数人因为看到而相信,但只有少数人因为相信而看到。我希望更多的程序员敢于相信软件生产力的这种巨大变化。开始使用低代码工具,顺应软件开发技术的潮流,并从更高效的开发中受益。