Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

软件工程,还有未来吗?

Posted on 09/27/202609/27/2026 by 四火

我是 08 年毕业的,到现在,已经过去了超过 18 年。但是,我开始学软件的时间,要早得多,并且是从 VB 开始的,正儿八经接触的第一门编程语言是 C,毕业使用的是 Groovy on Grails 做的网站(可远不如现在的毕业生们使用的高大上技术了),在这篇文字里面有所介绍。如今在 AI 火遍全世界的年代,我会想起当时我是怎样学写软件的,更感慨的是,对于选择软件工程师作为职业的我来说,真的幸运地赶上了好时代。这个时代的激动人心,是前无古人的。

跳出琐碎的具体事件,如果我们站到非常高的视角,想想整个世界软件工程的演进,可以分成这么几个阶段:

首先是五六十年代的手工业时代,硬件是催化剂,随着硬件性能提升,极易崩溃的软件称为了瓶颈,这才有了把工程化从传统产业搬到软件上的第一个阶段。在这个阶段末,北约会议中提出了 “软件工程” 的概念。

接着是结构化编程时代,相当于是七八十年代,标志性的事件是 C 语言和 Unix OS 的诞生,Dijkstra(就是那个最短路径算法的作者)提出了 goto 语句的害处。从此大家都认可软件应该自顶向下、模块化编写。这段时间很多的观点也是我大学里面逐步接触到的。

接着九十年代到 2010 年代中期,互联网行业爆发,软件工程飞速发展,跨平台的 Java 语言诞生,敏捷的概念开始兴起。这段时间最浓墨重彩的两个词是 OO(面向对象)和 Web,我觉得从我的技术背景和积累来看,主要的知识内容就是那个年代产生的。

第四个阶段就是 2010 代中到 2020 年代初,大致可以归纳为云计算和云原生时代。这也算是记忆犹新,不过我自身的这方面的技术更新并不快。其中标志性的事件,我认为就是 Docker 和 Kubernetes 的开源。职业路线上,慢慢专注于 platform 和 infra 以后,我已经较少开发纯 web 的项目或者软件了,技术方面涉及云原生的可以说越来越频繁。

第五个阶段,处于刚兴起的一个大阶段,就是AI 驱动的时代,这可以说是说算是从 2022 年的 ChatGPT 爆发开始算起,依然非常早期。华尔街和资本把它炒的火热的程度,兴许可以说仅次于当年的互联网泡沫。自然语言开始成为编程语言,开发效率爆发,编程语言的 “语言” 特性本身,逐渐变得廉价,代码生成成本越来越低。

如果把这几个阶段的技术摆出来,再从一个随着时间演进的高屋建瓴的角度看,还能发现一些变化的规律:

第一个是抽象层级越来越高。

比如一开始是硬件机器语言、汇编语言;然后结构化编程阶段的 C 和 Unix,屏蔽了许多硬件指令的复杂性;接着就是互联网阶段的 JVM,做到一次编写,到处运行这样跨平台;而云平台的 Kubenetes+Docker 则是让运行环境和资源一并打包;到了 AI 则是让人类语言翻译成传统编程语言这一步都省了,基本上的最高的抽象层级了,也是最接近人类思维模式的形式。

第二个是软件复杂程度的爆炸。

从最早的直接接触硬件的操作,到逐步引入高级编程语言、面向对象等等对抗软件复杂度,再到治理方面使用 Kubernetes 等编排技术整合各种各样的微服务,最后是 AI 时代使用大模型来接管人类大脑对于软件整体体系的认知。

在 AI 的这个阶段,软件工程师的价值在哪里,这个行业的未来会怎样,和很多这行的人一样,我也在反复思考这个问题,比如这篇。

关于这个问题,如果尝试站得高一点,拨开那些具体技术和实践的迷雾,只是从软件工程和软件工程师的本质去思考问题,那么软件工程这一个行业,很很多工程行业一样,其实并没有什么特别的——技能会被替代,行业反而会持续进步。每一类具备普遍性的问题,每一种能够得到大规模使用的技术,都会关联到一种职业。所以,如果思考软件工程师这个职业是否会被淘汰掉,不如思考软件工程这个技术领域是否会被淘汰掉?进而再思考,软件领域所解决的问题是否会被淘汰掉?

显然,是否定的。

我来尝试解释一下。来想想看,软件工程诞生的动机是什么?一个词来概括,就是复杂性。人类的需求是社会进步的动力,这是无止境的。而正是因为需求不断进展,软件不可避免地变得越来越复杂,人类就迫切需要一个可以重复和实践的办法,来保证软件交付的时间和质量,这才有了软件工程。

再来思考未来,未来的软件是怎样的暂且不论,可以确定的是,未来需要软件解决的问题依然在变得更为复杂,那么未来软件的本身也自然需要更为复杂,于是,为了保质保量交付,为了社会化大规模实践和推广最佳的方法,软件工程就需要持续存在,并且也将更为复杂,专业门槛只会更高。这就是最本质的软件工程和软件工程师不被淘汰的逻辑。只不过,那时的技术未必是现在的技术,那时对于工程师的要求未必是现在对于工程师的要求。这一点结论,其实和 AI 本身没有关系,也可以是其他技术手段,只不过 AI 恰好成为了这个时代扣动扳机的那个角色。

再把视角缩回到 AI。我们时常听到 AI 替代论和 AI 自我进化论。在某些领域,AI 确实会不断替代当前软件工程师在软件工程中所扮演的许多角色,很多技术问题也能够通过 AI 完成解决,而 “人” 只需要很低程度的参与;不过,也有很多领域,广泛存在确定的逻辑壁垒,让 AI 自我迭代和强化变得非常困难。具体说,AI 自己来生成代码,并且使用它来进行训练,不断强化,它就会缺乏人类真实的应用场景,本质上也无法产生针对真实的改进和创新。这种模式,一定程度上可以视作封闭系统的自我更新,极易放大微小的误差,最终结果天差地别,形成不可思议的谬误。

把时间维度放到未来几年到十几年来看,我觉得 AI 还是更适合作为一个辅助者的身份,软件工程师来做抽象,做统筹,做高屋建瓴的规划性工作,让 AI 成为一个辅助者、好帮手,帮助完善内容,作为智囊团提供建议和实施者搞定经过人类审核分派的具体任务。社会依然需要软件工程师这样的角色,甚至需要更多,只不过他们的技能树可能会发生大幅变化。软件工程师对于问题的简化能力、抽象能力、规划能力,将得到前所未有的重视。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 本地部署 Minikube + Docker 记录
  2. 关于近期求职的近况和思考
  3. 聊聊商业模式——Atlassian
  4. 聊聊商业模式——阿里巴巴
  5. Run:ai 学习记录

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

AI Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 投资 数据库 时间 曼联 测试 生活 程序员 管理 系统设计 缓存 美股 英语 设计 评审 谈谈 Ops 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (14)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (7)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (9)
  • Product Design (5)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (26)
  • Career Growth (57)
  • Life Experience and Thoughts (41)
  • Video Games (4)
  • Business and Investment (9)

推荐文章

  • 聊一聊分布式系统中的时间
  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • Anonymous on 回国感悟
  • 四火 on AI 到底会怎样取代我们的工作
  • Anonymous on AI 到底会怎样取代我们的工作
  • 四火 on AI 到底会怎样取代我们的工作
  • 四火 on AI 到底会怎样取代我们的工作
  • Decisivem on AI 到底会怎样取代我们的工作
  • Anonymous on AI 到底会怎样取代我们的工作
  • Decisivem on 聊聊商业模式——阿里巴巴
  • 四火 on 聊聊商业模式——Atlassian
  • bob on 聊聊商业模式——Atlassian
© 2026 四火的唠叨 | Powered by Minimalist Blog WordPress Theme