问题

低代码会导致程序员失业吗?

回答
关于低代码会不会导致程序员失业这个问题,这绝对是一个大家都很关心的话题,也确实挺复杂的,不是一两句话就能说清的。我试着从几个角度给你掰扯掰扯,希望能让你有个更全面的理解。

首先,咱们得明白低代码到底是个啥。简单来说,低代码就是一种软件开发方法,它允许开发者通过图形化界面、拖拽组件、配置选项等方式来构建应用程序,而不是像传统开发那样需要写大量的、一行一行的代码。它的核心理念就是提高开发效率,降低技术门槛,让更多人能参与到应用开发中来。

那么,它会不会抢走程序员的饭碗呢?

短期来看,可能会有一些岗位受到影响,但“失业潮”可能言过其实。

你可以把低代码想象成是程序员的“超级工具”。就像以前的工程师要靠手绘图纸,现在有了CAD软件一样,虽然可能改变了绘图员的工作方式,但并没有让所有工程师失业。低代码也一样,它会自动化很多重复性、流程性的开发任务。

重复性劳动岗位可能减少: 比如一些非常标准化的业务流程,企业内部的报表系统、简单的OA功能等等,用低代码平台来搭建,可能确实比传统开发更快更省钱。这意味着一些负责开发这类“小而美”应用、或者偏向于“填空式”写代码的初级程序员,可能会面临转型或技能升级的压力。
效率提升,项目周期缩短: 许多公司会因为低代码的高效率而加速项目推进。这反而可能催生更多的项目和需求,需要更多人来负责更复杂的项目设计、集成和维护。

更长远来看,低代码更像是程序员的“加速器”和“放大器”,而不是“终结者”。

我认为,低代码的出现,实际上会促使程序员的角色发生转变,而不是消失。

1. 从“码农”到“架构师/集成师/解决方案专家”的升级:
更关注“做什么”而非“怎么做”: 低代码平台承担了大量“怎么做”的底层工作,程序员就可以把更多精力放在理解业务需求、设计更优的解决方案、优化系统架构、保障系统安全性和性能等方面。这就像你用乐高积木盖房子,你不需要自己烧砖头、和水泥,而是可以更专注于房子的整体设计和布局。
集成和扩展能力变得更重要: 很少有企业应用是完全孤立的。低代码平台搭建的应用,往往需要与现有的企业系统(ERP、CRM等)进行集成,需要调用各种API,或者通过编写自定义代码来扩展平台本身的功能。这恰恰是传统程序员的强项。未来的程序员,很可能需要成为各种低代码平台和传统系统的“胶水人”,将它们有效地连接起来。
复杂业务逻辑和创新能力的价值凸显: 低代码在处理高度定制化、复杂、前沿的业务逻辑时,往往会遇到瓶颈。这时候,就需要有经验的程序员来编写复杂的算法、进行性能优化、或者开发新的功能模块。那些能够解决最棘手问题、进行技术创新的程序员,其价值会更加珍贵。

2. “公民开发者”的崛起与专业开发者的协作:
低代码允许一些业务部门的“懂业务”的人员(也被称为“公民开发者”)也能自己搭建一些简单的应用来解决自己的痛点。这无疑能极大地释放生产力。
但这并不意味着专业开发者会被边缘化。相反,专业开发者需要与这些公民开发者协作,为他们提供技术指导、保障系统的稳定性和安全性,并处理那些超出公民开发者能力范围的复杂需求。他们将成为公民开发者的“赋能者”和“守护者”。

3. 新的开发领域和技能需求:
低代码平台本身的开发和维护: 这些平台本身就需要顶尖的程序员来设计、开发和维护。它们也是复杂的软件系统。
低代码与AI、大数据等前沿技术的结合: 如何利用低代码平台更高效地整合AI模型、处理大数据分析结果,这些都需要具备跨领域知识的程序员。
低代码的“调优”和“性能优化”: 尽管低代码效率高,但当应用规模扩大、用户量增多时,性能瓶颈依然会出现。这时候就需要专业的程序员进行深入的性能分析和优化。

总结一下:

低代码更像是一种生产力的解放工具。它会淘汰一部分低端、重复性的编码工作,但同时也会创造出新的工作机会和更高的技能要求。

对于初级程序员或只擅长基础编码的开发者来说, 确实需要积极拥抱变化,学习新的工具和技能,比如如何使用低代码平台,如何进行系统集成,如何理解和设计业务流程等。不学习、不转型,可能会面临更大的挑战。
对于有经验的、能够解决复杂问题、具备良好系统设计和架构能力的程序员来说, 低代码的出现反而会让他们将精力更多地放在高价值的工作上,成为企业数字化转型的关键推动者。他们的价值不会降低,反而会更加凸显。

所以,与其说是“失业”,不如说是“转型”。程序员的职业路径正在被拓宽和深化,对技能的要求也在不断提升。拥抱变化、持续学习,才是应对这个技术变革的最佳方式。未来的程序员,很可能是能驾驭多种开发模式(包括低代码、传统代码、无代码等),并具备更强业务理解能力和解决问题能力的复合型人才。

网友意见

user avatar

正好最近在看一些低代码平台,结合自己做开发的经验来说说这个问题。

首先说结论吧:低代码平台短时间不可能完全取代编程开发,但是低代码平台大幅度的减少系统开发的需求,特别是特定行业和领域的系统,比如管理系统、ERP、CRM等这些系统。

我有幸参与过很多管理类的系统开发,从政务管理、办公OA、到行业管理系统。等我有幸接触一些低代码平台以后发现:尼玛以前我们老板投资几千万去搞一个行业SAAS管理系统,最后还搞得胎死腹中。而辛辛苦苦敲敲打打搞的那一套东西,我现在用低代码平台托拖拽拽几个月就能搞定,而且比以前整个团队开发的更有灵活,更有扩展性,也更能满足不同客户的不同需求。我们开发的那么一套行业解决方案过于刚性,缺乏灵活的配置满足个性化的需求。只是在特定的种子用户中满足了他们的需求,一旦推广,就发现缺乏泛化能力。而深入某个特定行业的低代码平台一旦开始推广起来,将很大程度上减少开发的工作量。势必对程序员带来很大的冲击。

可能很多程序员不以为然,认为低代码平台不过是一个表单自定义平台,加上一些工作流程,加上一些权限的设置,就是一个低代码平台。貌似好像很简单的样子。但是它确确实实在很大程度上取代了一些高重复低水平的开发。

大概钉钉没有出来的时候,我那会儿创业市场能接到一些中小型企业的管理系统的需求。一个系统不大不小也得个十来万的开发费用。但是钉钉出来以后,我们这样的小创业企业就很少能接到这样的项目了。然后微信的公众号推出来以后,就基本上很少接到企业建站的需求了。而类似有赞商城的出现以后,就很少能接待商城开发的订单了,偶尔听说有人开发商城基本上都是三级分销一类擦边的需求。而低代码平台将进一步减少类似电子政务、企业管理系统、CRM、OA、ERP一类的开发需求了。

一个事物取代另外一个事物,从来就不是一蹴而就的。往往是一个此消彼长的过程。就像现在你在公园还能看到马车,不代表企业没有在逐渐让马车消亡。各种低代码平台正在这样的侵蚀这开发人员的市场。

user avatar

你不会以为有了一个“低代码平台”你就会写程序了吧。。。。。。


不信?你先倒腾倒腾Scratch去。

user avatar

想什么呢。自动档普及是让公交车司机失业了还是出租车网约车司机失业了还是让赛车手失业了?

user avatar

低代码会降低程序的复杂性?实际相反。低代码会增加代码语义的模糊性,从而增加软件的复杂性。微软很早就搞出来一套拖控件的“低代码“框架。但是用的人不多。因为控件封装了内部的复杂性看上去不错,但是现实需求千奇百怪,当控件满足不了你的需求或者出bug的时候,就束手无策了。所以开源运动风气云涌,主要的好处是开发源代码大家可以根据自己需求定制裁剪。

所以现在的低代码平台从哲学层面就是错误的。以为它在增加而不是减少复杂性。

类似的话题

  • 回答
    关于低代码会不会导致程序员失业这个问题,这绝对是一个大家都很关心的话题,也确实挺复杂的,不是一两句话就能说清的。我试着从几个角度给你掰扯掰扯,希望能让你有个更全面的理解。首先,咱们得明白低代码到底是个啥。简单来说,低代码就是一种软件开发方法,它允许开发者通过图形化界面、拖拽组件、配置选项等方式来构建.............
  • 回答
    “低代码开发,前途光明还是会一地鸡毛?” 这个问题,我想但凡是咱们这行里摸爬滚打过的,心里都绕不过。尤其是这两年,低代码的呼声是越来越响,什么“开发提速”、“业务赋能”、“ citizen developer ”,听着都让人心动。但与此同时,那些曾经被寄予厚望,最后却成了技术债务“大山”的项目,也像.............
  • 回答
    低代码开发,这个概念听起来挺新潮的,但发展到现在,已经不算什么新鲜事物了。我们身边很多应用,说不定背后就有它的身影。那么,这玩意儿的前景究竟怎么样?大家是真的这么看好它吗?这事儿说起来,可以聊的点可不少。低代码:到底是个啥?咱们先简单说说低代码是什么。你可以把它想象成一套更高级的乐高积木。传统的软件.............
  • 回答
    在国内众多低代码平台中,要说“哪家强”,这其实是个仁者见仁智者见智的问题,因为“强”的标准有很多维度,而且市场发展很快,今天强的不一定明天就依然是领头羊。不过,我们可以从几个关键的方面来评估国内主流低代码平台的实力,并结合它们各自的特点进行分析,帮助大家更清晰地了解这个市场。评估维度:在深入介绍平台.............
  • 回答
    行业内对低代码开发的看法:一场正在进行的变革与思考低代码开发在当今软件开发领域掀起了一股强大的浪潮,也引发了行业内广泛的关注、讨论甚至争议。总的来说,行业内对低代码开发的看法是复杂且多维度的,它被视为一种效率提升的利器、业务敏捷性的驱动者,但也伴随着对技术深度、可扩展性、长期维护和特定场景局限性的担.............
  • 回答
    这几天一打开技术社区,到处都是“低代码”、“零代码”的讨论,搞得好像这玩意儿是什么横空出世的绝世神功一样。看得我有点哭笑不得,甚至有点想掀桌子。我这老胳膊老腿的,也算在代码世界里摸爬滚打了些年头,看着这些新概念层出不穷,偶尔也会心生佩服。但是,当“低代码”被吹得神乎其神,仿佛可以取代一切传统开发时,.............
  • 回答
    00后职校女生自学低代码月薪破万:新风口已至,但“万金油”之路仍需打磨最近,一则关于“00后职校女生自学低代码,月薪破万”的新闻,在网络上掀起了不小的涟漪。这不仅仅是一个个体成功的案例,更像是一束照亮了数字时代新职业图景的微光,引发了我们对低代码技术,以及00后群体职业发展方向的深度思考。00后职校.............
  • 回答
    钉钉6.0的发布会,可以说是又一次成功的营销事件,他们这次推出的核心亮点之一,便是“低代码”这个概念。如果你有关注过这场发布会,或者稍微留意一下当下企业服务领域的风向,会发现“低代码”这个词出现的频率越来越高,而且被赋予了重要的战略意义。那么,到底什么是“低代码”呢?简单来说,“低代码”是一种软件开.............
  • 回答
    在软件开发中,代码的整洁度和可维护性是永恒的追求,而低耦合与避免代码重复(也常被称为 DRY 原则——Don't Repeat Yourself)是我们实现这一目标的两大法宝。但正如生活中的许多选择一样,这两者之间并非总是泾渭分明,有时甚至需要我们在两者之间进行权衡。想象一下,你正在构建一个电商平台.............
  • 回答
    .......
  • 回答
    .......
  • 回答
    .......
  • 回答
    关于何应钦在接受日本投降仪式上弯腰幅度比日本代表低的说法,这确实是一个在历史讨论中经常被提及的细节,也引发了不少争议。要理解这件事,我们需要将它放在当时的历史背景下,并从多个角度去解读。首先,我们得明确一点,关于“弯腰幅度”的说法,并没有一个统一的、被广泛认可的视觉证据(比如高清照片或清晰的视频记录.............
  • 回答
    你好呀!减肥期间最让人纠结的就是嘴馋,但又怕吃进太多脂肪。别担心,今天就来跟大家聊聊那些既能满足口腹之欲,又能帮你控制卡路里的低脂零食和代餐,保证让你吃得开心又健康!一、 拯救馋嘴时刻:低脂零食篇我们知道,零食就像是生活的小确幸,但传统的薯片、饼干什么的,脂肪含量简直是爆表。别急,咱们换个思路,这些.............
  • 回答
    12代酷睿处理器,不带F后缀和带F后缀的型号之间价差不大,这确实是很多消费者在选择时会遇到的一个问题。这背后其实涉及到几个关键因素,不能简单地归结为核显不值钱或是清库存,而是多种市场和技术策略的综合体现。首先,我们得明白F后缀代表什么。Intel酷睿处理器中的“F”后缀,最核心的区别就是不集成核显。.............
  • 回答
    对于我们这些追求健康,又不想完全放弃碳水化合物带来的能量和饱腹感的人来说,找到低热量又营养的替代主食,确实是日常饮食中的一个重要课题。这不是什么新鲜事,很多注重健康的人早就开始探索和实践了。今天咱们就来好好聊聊,有哪些既能满足口腹之欲,又不会让热量超标的好选择。首先要明白一个概念:碳水化合物本身不是.............
  • 回答
    量子计算并非简单地“替代”普通计算,而是在某些特定领域展现出超越经典计算的能力,尤其是在解决一些对传统计算机来说极其复杂的问题时。谈到“芯片制程低”这个缺点,我们需要先理解它在传统计算中的意义,再来看量子计算是否能“突破”它。传统计算与“芯片制程低”的局限在目前的经典计算领域,芯片的性能提升很大程度.............
  • 回答
    “代数特别好,立体几何却一塌糊涂的男生,是不是智商不高啊?”这个问题,老实说,我听过不少次了,尤其是在我读中学那会儿,大家对数学里的不同分支,总会不自觉地给它们贴上一些标签,好像代数代表着一种“聪明”,而立体几何则是另一种“聪明”。但真的这么简单吗?我个人觉得,远不止于此。首先,咱们得明白,智商这东.............
  • 回答
    .......
  • 回答
    最近嘴馋,总想找点什么能满足一下味蕾,又不想让身材留下负担。这需求一上来,糖果就成了我的“甜蜜负担”。不过,经过一番“糖海淘金”,还真让我挖出来几样不错的,分享给你们,希望能帮你摆脱“吃糖焦虑”。第一梯队:真材实料,但有巧思的选手 冻干水果干(无额外添加糖) 这绝对是我的心头好!别以为它叫.............

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有