慣性聚合 高效追蹤和閱讀你感興趣的部落格、新聞、科技資訊
閱讀原文 在慣性聚合中打開

推薦訂閱源

博客园 - 司徒正美
V
V2EX
T
Tailwind CSS Blog
有赞技术团队
有赞技术团队
aimingoo的专栏
aimingoo的专栏
Apple Machine Learning Research
Apple Machine Learning Research
IT之家
IT之家
Blog — PlanetScale
Blog — PlanetScale
A
About on SuperTechFans
月光博客
月光博客
T
The Blog of Author Tim Ferriss
宝玉的分享
宝玉的分享
Martin Fowler
Martin Fowler
博客园 - 聂微东
The GitHub Blog
The GitHub Blog
V
Visual Studio Blog
WordPress大学
WordPress大学
酷 壳 – CoolShell
酷 壳 – CoolShell
Engineering at Meta
Engineering at Meta
GbyAI
GbyAI

阮一峰的网络日志

科技爱好者周刊(第 396 期):互联网通信的替代方案 科技爱好者周刊(第 396 期):互联网通信的替代方案 - 阮一峰的网络日志 科技爱好者周刊(第 395 期):软件开发的第三种方式 科技爱好者周刊(第 395 期):软件开发的第三种方式 - 阮一峰的网络日志 科技爱好者周刊(第 393 期):脑腐状态 科技爱好者周刊(第 392 期):axios 投毒与好莱坞式骗术 科技爱好者周刊(第 391 期):AI 的贫富分化 科技爱好者周刊(第 390 期):没有语料,大模型就是智障 套壳中国大模型撑起500亿美元估值?扒一扒 Cursor 的"套壳"疑云 科技爱好者周刊(第 389 期):未来如何招聘程序员 科技爱好者周刊(第 388 期):测试是新的护城河 零安装的"云养虾":ArkClaw 使用指南 科技爱好者周刊(第 387 期):你是领先的 科技爱好者周刊(第 386 期):当外卖员接入 AI 字节全家桶 Seed 2.0 + TRAE 玩转 Skill 科技爱好者周刊(第 385 期):马斯克害怕中国车企吗? 智谱旗舰 GLM-5 实测:对比 Opus 4.6 和 GPT-5.3-Codex 科技爱好者周刊(第 384 期):为什么软件股下跌 科技爱好者周刊(第 383 期):你是第几级 AI 编程 Kimi 的一体化,Manus 的分层 科技爱好者周刊(第 382 期):独立软件的黄昏 AI native Workspace 也许是智能体的下一阶段 科技爱好者周刊(第 381 期):中国 AI 大模型领导者在想什么 科技爱好者周刊(第 380 期):为什么人们拥抱"不对称收益" 科技爱好者周刊(第 379 期):《硅谷钢铁侠》摘录 我如何用 AI 处理历史遗留代码:MiniMax M2.1 升级体验 科技爱好者周刊(第 378 期):预测是新的互联网热点 科技爱好者周刊(第 377 期):14万美元的贫困线 科技爱好者周刊(第 376 期):太空数据中心的争议 科技爱好者周刊(第 375 期):一扇门的 Bug 终于有人做了 Subagent,TRAE 国内版 SOLO 模式来了 科技爱好者周刊(第 374 期):6GHz 的问题 VS Code 使用国产大模型 MiniMax M2 教程 科技爱好者周刊(第 373 期):数据模型是新产品的核心 国产大模型接入 Claude Code 教程:以 Doubao-Seed-Code 为例 科技爱好者周刊(第 372 期):软件界面如何设计 大模型比拼:MiniMax M2 vs GLM 4.6 vs Claude Sonnet 4.5 科技爱好者周刊(第 371 期):一个乐观主义者的专访 科技爱好者周刊(第 370 期):正确的代码高亮 错误处理:异常好于状态码 科技爱好者周刊(第 369 期):Tim 与罗永浩的对谈 科技爱好者周刊(第 368 期):不要这样管理软件团队 一天之内,智谱和 Anthropic 都发了最强编程模型 科技爱好者周刊(第 367 期):Nano Banana 的几个妙用 科技爱好者周刊(第 366 期):旧金山疯狂的 AI 广告 科技爱好者周刊(第 365 期):流量变现正在崩塌 科技爱好者周刊(第 364 期):最难还原的魔方 科技爱好者周刊(第 363 期):最好懂的神经网络解释 科技爱好者周刊(第 362 期):GitHub 工程师谈系统设计 科技爱好者周刊(第 361 期):暗网 Tor 安全吗?
軟件吃軟件,編程工作會越來越多嗎?
阮一峰 · 2020-05-27 · via 阮一峰的网络日志

1、

最近,國外有一篇文章,標題很有趣,叫做《軟件吃掉軟件》

作者認為,大型軟件和通用軟件越來越強大,將會取代小軟件和專門軟件,相當於把後者都吃掉了。

他以自己的經歷舉例,雲服務就取代了很多小軟件。

"我親眼目睹了這種情況發生的速度。我的第一份工作是在一家小型創業公司,我們擁有大量的物理服務器。現在,很難想象有任何一家 Web 創業公司會直接管理服務器,人們都是在亞馬遜 AWS 控制台上點擊幾個按鈕和鏈接。"

框架的發展,也使得從頭編寫代碼的需求越來越少。

"程序員曾經需要從頭開始構建東西,但是軟件庫的發展速度超過了我們的使用速度,甚至軟件可以自己生成新的軟件,這也是為什麼你看到如此之多的"無代碼"或"低代碼"解決方案突然出現的原因。現在,自己編寫代碼的理由越來越少,你要做的只是將不同的產品集成在一起。"

他的結論就是,軟件自動化技術的發展,可能將會減少對軟件工程師的需求,未來的程序員可能會比現在少。

2、

我對這個話題很感興趣,因為這是在預測未來的重大變化,而且跟就業趨勢直接相關。如果未來軟件的規模化和自動化,會抑制對程序員的需求,那麼就不應該鼓勵年輕人都來當程序員。

Hacker News 論壇對這篇文章進行了熱烈的討論。大部分人(都是職業程序員)的看法是, 這種觀點已經說了幾十年了,根本是杞人憂天,實際情況恰恰相反,程序員變得越來越多。

"10歲時,我開始用 Qbasic 編碼。我告訴爸爸,長大後想成為一名程序員。他告訴我,計算機可能很快就會實現自動化,就像他的工程行業一樣,那時我會不得不找另一份工作。

但是,23年過去了,市場對程序員的需求不斷上升,並且似乎仍在上升。

我想說,我們離軟件自動解決大部分需求的這種抽象水平,還很遙遠。正如文章所說,k8s、docker、kafka、databricks、redshift 這些新工具,取代了很多程序員。但是,它們其實引發了更多對程序員的需求。

那些必須由程序員解決的問題,只是轉移到了新的地方。"

就像上面引文所說,現實情況是需要編程解決的問題不是越來越少,而是越來越多,導致了程序員的增加。原文提出的兩個論據,都站不住腳。

首先,雲服務確實使得企業免去了服務器管理,但是你仍然需要有了解 docker、kubernetes、數據庫分片和索引、故障轉移、備份、消息隊列等等技術的人員。即使這些東西現在更加集成,更易於組合,但要弄清楚它們如何相互作用,如何設置,仍然是很複雜的一件事。

其次,"無代碼開發"只能解決一些通用的軟件問題,遲早會出現需要定製的情況。那時,就需要有程序員來修改代碼,用戶才能繼續使用。

總之,世界正在變得越來越自動化,而自動化的本質是軟件,所以對程序員的需求只可能越來越多,不可能越來越少。

3、

不過,論壇上面也有少部分人贊同原作者的觀點,認為程序員越來越多隻是過去的情況,未來未必如此。現在可能是軟件開發"突變"的一個時間點,未來的發展可能不同於此前的情況。

市場需要更多瞭解 docker 和 kubernetes 這樣新工具的人,這個是沒錯。但是,主要是大公司才需要這樣的人,小公司用不到 kubernetes。小公司面對的複雜性是有限的,只要使用大公司提供的簡單解決方案即可,需要自己開發的部分幾乎沒有。

而且,如果公司的業務重點不在技術方面(你要知道大部分公司都不是互聯網公司),使用"無代碼方案"是最有效的。因為無需在軟件工程上花費很多錢,就可以快速應用。

歷史上,每當一個領域出現大量需要編程解決的問題,就會誕生一個通用的解決方案,解決掉90%的場景。然後,這個領域對程序員的需求就會快速減少。

"30年前,開發圖形界面 GUI 很困難,Visual Basic 改變了這一點。

20年前,製作一個 Web 應用很困難,PHP 改變了這一點。

10年前,寫一個複雜的網頁佈局很困難,Bootstrap 改變了這一點。

現在,機器學習很困難,PyTorch 正在改變了這一點。

每個棘手的問題最終都會產生一個有效解決方案,解決掉90%的場景。對於大多數公司而言,這個解決方案已經足夠了。剩下的10%場景,其中一部分由某些公司付錢給程序員來解決,另一部分永遠不會解決。"

所以,如果新的領域層出不窮,那麼就會需要更多的程序員。但是,這些領域對程序員的需求都不會持久,一旦產生了解決方案,需求就會迅速降低。

4、

看完了上面的討論,我的想法是,市場對程序員的需求,未來怎麼變化,不能簡單地回答增加或減少,而是取決於兩個因素。

(1)人們需求增加的速度,能否超過軟件自動化的進化速度。

現有的場景最終都會有通用的解決方案,需要僱傭程序員的情況,確實將越來越少。程序員的就業,主要依靠新出現的場景。而且,新場景的增加速度,必須超過軟件自動化的進化速度,否則舊的解決方案也許會自己升級成新場景的解決方案。

(2)軟件開發的難度,必須超過機器學習的進化速度。

程序員的數量,還跟軟件開發的難度有關。難度越低,就會有越多的人從事這項工作。以前,你必須懂得計算機的底層硬件和彙編語言,才能開發軟件,所以程序員很少。現在,軟件開發越來越容易,已經不需要了解底層,只需要懂得某個框架即可,所以越來越多普通人變成程序員。

未來的編程肯定會變得越來越容易,但是,越來越容易的編程,也意味著機器可以輕而易舉地代替人,來完成這些工作。所以,軟件開發的難度必須超過機器學習的水平,否則需求的增加只會導致更多的機器自動編程,而不會導致更多的程序員僱傭。

(完)