程序員所積累的編程知識在十年後將有多少變得沒用？

12-26

看了這篇文章想到的：一名 40 歲「老」程序員的反思

為什麼有 8個人邀請，你們都覺得我很老了么？我還很年輕，悄悄的告訴你們，姚老師比我老，你們該去邀請他。

以前學了現在沒用的技術，有很多，越數越傷心，還是回憶下 2007年的事情吧：

1. 業餘在玩 Flash 遊戲開發，當時頁游還沒有火，我覺得是個機會，市面上很多頁游都是八位機的水平，估計他們以前都沒什麼遊戲開發經驗，所以大家都持懷疑態度，我想看看 Flash 的 2D 效果能做到什麼程度，於是花了了兩周時間做了 Flash 下的第一個小遊戲：

Flash Game - Final Weapon 。。。　　

嗯，模仿 PopCap 的 heavy weapon 加了些有趣的元素，比當時所有市面上的 Flash 遊戲效果都好一大截，至今為止，仍然有很多市面上的 Flash 遊戲沒達到這個 Demo 的效果。

2. 帶領一隻六人團隊開發 XBox 360 的預研項目，把公司一套 3D引擎移植到 XDK 的 D3D9下面，D3D8 到9 跨度很大，廢了比較多的時間，覺得 D3D9 才是未來。當時 360 的性能並沒有說的那麼好，單核性能差不多只能到我筆記本單核的 50% 左右，但是它有六個核，和原有引擎的單線程體系差別比較大，因此性能十分堪憂，這個坑填了很久。原有引擎很多基於 SSE 的運算代碼全部不能使用了，花了不少時間改寫成為 PowerPC 的 AltiVec 指令，最終才將整個引擎終於在 360 上從「不能用」變為「能夠一用」了。當時寫了篇關於 360 的優化文章：

PowerPC 彙編入門與優化。

3. 研究遊戲同步技術，當時國內沒人覺得遊戲還有「同步」問題，沒有任何參考資料，2007年遊戲市場上清一色的 MMORPG 遊戲，大家覺得只有做ＭＭＯ才是掙錢的。我看當時網遊里 95% 的 RPG遊戲，在對比單機遊戲上只有 39%的 RPG比例，覺得十分不合理，玩家遲早要厭煩，RPG壟斷的局面必然被打破。但是傳統 RPG那一套在快速動作遊戲上基本沒法行得通。我不斷的抓包，推敲模擬傳統區域網遊戲和國外快速動作遊戲的同步方式，寫了篇文章：《幀鎖定同步演算法》配合之前寫的《網路遊戲同步法則》以及《影子跟隨演算法》，基本上從兩個方向討論遊戲同步的兩大核心方法：幀同步和狀態同步（客戶端預測插值）。

4. 學習策劃知識，翻譯 MUD之父 Richard Bartle 的《MUD玩家分類理論》，當時遊戲「成就系統」在國外剛剛興起，國內遊戲還沒有這個東西，覺得十分不錯，我又翻譯了《成就系統最佳實踐》。

5. 弄 server 內存分配優化，參考 kernel 的 slab 內存分配演算法，於是優化並重新設計了一套 slabtree 分配演算法，給服務端整體內存分配性能提升了一倍，不再受運行時間和碎片的影響。大致原理見：如何設計內存池？ - 知乎

10年後：

1. Flash 基本掛掉了，沒人再提了，不過如今頁游還是在發展，只是遠沒當初那麼火爆，當年學習 Flash 的程序員都紛紛 cocos 和 u3d了，現在做頁游想招聘一個 Flash 程序員更是難上加難，不過 Flash 的 API 我覺得設計的真的很漂亮，我見過 2D 引擎里比較上乘的介面設計了，今天很多用 H5封裝的遊戲引擎，比如白鷺引擎，沒事掃了一眼，他們從對象樹到 API名稱，還是再模仿 Flash 的介面，可見影響力有多大。

2. 360也掛掉了，當年遊戲機清一色的 PowerPC （主機）和 mips（掌機，PSP）架構，如今換成了 x86（主機）和 arm（掌機）結構了。D3D9 也早已被淘汰。　

3. 同步技術到今天都還在很多討論，作為研究的比較早的人，我的三篇文章曾經幫助了不少遊戲解決他們的同步技術。《街機三國》的製作人跟我說，當時做 DEMO就是卡在同步上，後來看到了我的《幀鎖定同步法》解決了《街機三國》的同步問題，最終項目得以立項，然後他們就發財了，我得到一句真誠的「感謝」。聽說《王者榮耀》也還在用基於「幀同步」的改良方式。

4. 當年花過好幾年的時間學習策劃知識，業餘也喜歡自己兼任策劃和程序做些小遊戲，但如今成就系統早已不是什麼新東西，巴圖的理論也出現了更為科學先進的玩家分類方法的論文，加上 2009 年以後我就不做遊戲了，這些知識基本也就白費了。

5. 後來發現和 tcmalloc 很像，用了 7年這套代碼，比 libc 自帶的 malloc 強太多了，一路都是最好用的內存分配演算法，後來我自己忙其他項目懶得添加新特性和繼續優化就換成 jemalloc 了。當年「內存分配」這個技術，但凡有點經驗的人，都會來兩手，也是比較關鍵的模塊之一，如今好玩看看就行，自己重新實現邊際效用太低。

----

總結下，翻翻歷史，以前學過現在沒用的技術實在是一大把，我承認技術是有「道」和「術」的區別，我寫了十多年代碼的時候以為「術」容易淘汰，而只有「道」就能長存，一旦掌握了恆久不變的道，就可以以不變應萬變；而又寫了十多年代碼以後發現從更長的尺度上來看，並沒有一成不變的東西。

道法精深，短期是可以幫助你儘快的掌握運用新的「術」但是隨著具體實踐的不斷發展，人類認識世界的範圍逐步擴大，理論體系這個上層建築的「道」也需要不斷修正，推陳出新，適應新的實際情況。

早期基於的端游開發經驗，幫我在 Flash 平台上可以更短的時間內掌握要點，並做出超過同期水平的東西。手遊興起後，我雖然沒趟這灘渾水了，但看到很多第一批成功的團隊，也都是早年在端游或者頁游上有經驗的人。

另一層面上，道也不是一成不變的：以前積累的各種單核技術下的「道」，碰到 360 這種 6核cpu，每個核都不行的體系，基本全廢了；以前寫代碼，每一行我都想追求極致性能的做法，後面變得沒那麼重要了；內存分配演算法，在某一階段內自己可以做到領先，但不能持續了解最新相關方法，不持續迭代，興趣轉移了，隔段時間也就被 jemalloc 超過了，所以也並無一成不變的演算法。

總之，基本原理要掌握，不能成天只搞具體技術忽視理論提高；也不能痴迷純粹的「理論」，還是要勇於實踐掌握新進的「術」才能更好的迭代進化你自己的「道」，否則空有理論，只能坐而論道了。這不，我一把年紀了，最近幾個月還在玩 beautifulsoup4 做爬蟲呢。

並沒有什麼「一成不變」的「基本原理」可以讓你學一次就吃一輩子的。

錢學森不是說過么，脫離工程的理論，是沒有價值的。

---

如果 40 歲的 IT 業工程師，對人類的整個技術文明的認知是下面這樣子，那也就是個死搬磚的：

醫生到了40歲不用擔心他對血管系統的知識會蒸發，同樣的，律師、水管工、會計、英語老師，也是如此。他們積累的知識是相對穩定的，並隨著年齡會給予他們相應的尊重和補償。但是在編程領域，20年的經驗，似乎並沒有賦予同樣的優勢。

十年前我在中國做的補牙，在美國看來都是完全淘汰的技術。三年前我兒子不得不進行的手術，在美國這裡也是不推薦的手段。稅法，房屋標準，對人腦外語學習的認知，這些知識你真覺得 20 年不用變？

醫生，律師、水管工、會計、英語老師，他們能積累下來的知識和必需忘記的知識，和程序員能積累的知識和必需忘記的知識，都是極為類似的。

我們 team 里幾個老工程師敘舊喜歡談談打孔帶的時代。現在一個是 GPU 編程專家，另一個一點 UI 工作都不做，但是每天照樣有不斷的 commit。

如果在人類的技術體系中對程序員做出準確定位，那麼你會發現，程序員這個行業的一些「特性」其實是一類行業的共性。有時候我們感慨程序員的特殊性，其實是把程序員歸錯了類。程序員是工具設計者。如果你去和其它工具設計者比較，程序員的特性就更少了。

很多答主都提到了，編程技能會變，但是基礎理論基礎知識不變，就永遠不過時，比如數據結構，工程原理，演算法之類。

我補充一個。

大家似乎很少會考慮到一點。

即使是新技術的產生，多半也是依託於現有的技術，或者和現有的技術相似。

打個比方，二十年前python，java絕對是大部分程序猿所陌生的。更多程序猿對C,C++更熟悉。因為python和java誕生比較晚。

可是一個程序猿學了C或者C艹，他們再學後兩種會很困難嗎？

一點不難。相反我看見很多程序員大呼簡單。

你們真地別忘了，設計Python，java的人本身也是頂級的程序員啊！他們在設計這門語言的時候，更多會參考它們的前輩們的成果。
為什麼要開發一種新的技術？當然是因為現有的技術已經無法滿足現有的需求或者有缺陷。

但是他們不會那麼傻，直接硬生生地從最原始中開闢一條道路。而是站在前人的基礎上提出新的技術。

所以新技術怎麼變，都是依託於舊的技術。
換一句話說，新技術並不是專門為難現有的程序員，而且很大可能反而專門讓現在的程序猿更快地學習，更輕鬆地實用。

只要一個程序猿不太懶，花點時間自我學習，更新一下自己的知識，也不會怕丟飯碗了。

雖說如此，還是建議，作為一個程序猿應該不僅僅滿足與會寫業務，這樣只會不斷地把業務熟悉到不能再熟悉。而是紮實自己的基本功，學習一些深層次的原理，無論對工作還是日後拓展都有好處。

挺多都會沒用，但是關鍵的東西都有用。

先讓時間倒流到10年前，2007年，那時候我還在微軟。

主要工作用C#開發網路爬蟲和Web Service；
我寫代碼也喜歡研究一些驚奇花哨的寫法；
我閑暇時候還研究研究F#，號稱.NET上的函數式編程語言語言，為了理解什麼是Monad還廢了好幾天的時間；
微軟還在倡導使用基於 .NET的Silverlight技術，可以理解為是一個微軟版本的Flash，我記得當時著名的微軟技術教育者Jeff Prosise對我們說：「JavaScript is not the future. This (Silverlight) is the future.」
那時候jQuery剛剛出現沒多久，但是，公司各個部門自己都搞了類似的UI庫，所以也不願意突然換成jQuery；
我在面試的時候，往往讓對方描述一下一個網頁從在瀏覽器地址欄回車到全部渲染完發生了什麼，沒有多少人能答得完整。

現在，2017年，我已經不靠微軟吃飯了。

C#依然活著，但是我已經不用了，離開微軟體系之後，真的完全用不上；
我只想寫枯燥的代碼（枯燥在這裡是褒義詞），也就是說，我寫的代碼，要傻子都能看懂，我不想有一天有人來問我為什麼這麼寫；
我繼續研究函數式編程，不是用F#，而是用JavaScript;
JavaScript如日中天，Silverlight死得不能再死，要是再見到Jeff Prosise，我一定要問一問他的感想；
jQuery已經經歷了成為業界標準又逐步被後起之秀React、Vue和Angular蠶食的過程；
我已經放棄在面試的時候去問太難的題目了，過去十年已經證明犯不著，我只要和人聊幾句就知道這人行還是不行。

你看，這就是結論。

語言會凋零，語言會隨著你工作的變化而顯得不重要，就像C#；
代碼寫作水平依然是硬功夫，就應該寫通俗易懂的代碼，枯燥的代碼；
編程思想會持續很長時間，比如函數式編程；
特定某個企業推動的技術會凋零，信他們說得「這就是未來」你就輸了，比如Silverlight;
框架會變得過時(比如jQuery)，因為新的框架(比如React/Vue/Angular)總是會長江後浪推前浪；
然而，你處理關於人的問題的功力，卻是應該不斷增長的。

謝謝，歡迎關注進擊的React - 知乎專欄。

寫點政治不正確的東西吧，我想一定會被人拍磚，還是匿一下。

看到這個問題，我挺悲涼的，編程學習10年之後，將有多少變得無用，在我看來如果一成不變的話，基本沒啥有用的了，一個程序員崗位之所以有價值，是技術實現的產品有價值，而你的技術正好維護這個產品來體現你的價值，換其他人也不一定比你差！！所以我看到太多技術大牛離開了某個行業，無非是在原有崗位競爭中沒有勝利，崗位果實被他人摘取而已。我不是鄙視，我是悲涼，大家都說階級固化，程序員崗位（或者社會上任何其他工作）何嘗沒有固化？

10年前流行的技術，有深度的技術很可能在今天沒有對應的崗位了，市場上不需要了，或者不缺了，再或者有其他人在這個崗位了，那些深入研究某個領域技術的大牛能否體現價值呢？答案是否定的，你的價值是市場崗位定價的，不是自身能力定價的，真的論技術能力，我敢說太多大牛比我現在所在公司的人搶很多，為什麼他們要不混得很差，要不沒有他們收入高，在我看來無非是抓住了歷史上某個時間機遇，佔住了崗位，然後跟著成功的產品水漲船高。

程序員必須時刻保持學習才能在不斷抓住新的機遇，如果某一天產品倒了，還能找到新的保值崗位，坦白說這很難，越是薪酬高的程序員越難，因為高薪酬的溢價很大程度上是之前成功產品的變現，而不是能力價值，很多牛人不明白這點，認為寫代碼寫的好，技術研究的深入就能獲得高溢價，其實不然，在我看來，代碼寫的好，技術研究的深入只有在市場正好需要這樣的技術時，才能體現它的價值，否則可能再深的技術也很難變現了，而一旦技術普及，牛人沒有佔住崗位，就很快失去競爭力，必須去尋找下一個技術熱點快速切入。

IT行業發展如此之快，以至於每個技術窗口期可能就2-3年，10年已經2-3波技術熱點了，更別說10年一成不變的技術，所以我認為10年編程累計的經驗如果不能快速切換，將很快失去市場競爭力。

所以重點來了，程序員核心能力是什麼？紮實的基本功能讓你必須快速學習，在必要時快速轉換技能樹，能夠抓住大勢，對技術發展有預判，如果走運抱住了大腿，一定經營好你的人脈、提升管理優勢、不要以技術牛人居功自傲（我見過太多創業cto被幹掉，就是因為功高蓋主），不忘記持續充電，因為也許哪天大腿就沒了，你還有能力去找下一條大腿。

ps：這裡的大腿不是抱住某個人，是某個成功的能賺錢的產品，不管是你做，還是其他人做，某個產品都可能過時的，過時了就要換大腿了。

編程知識可以分為兩類：

1，經驗型知識；

2，原理型知識。

先說結論：經驗型知識貶值速度要快於原理型知識。

為了證明這個結論，我們與其預測十年後有什麼只是變得沒用，不如看一下過去的若干年哪些知識變得沒用了（也不能說沒用，只能說貶值）。

拿時下最火的Web前端工程師這個職業來說，從過去到現在，什麼是經驗型知識，什麼是原理型知識呢？

# 經驗型知識（What/How）：

1. 瀏覽器兼容性和系統兼容性知識：比如對IE5.x - IE7的各種兼容性知識，特別是CSS hack，低DOM級向高DOM級的API兼容，非同步請求方式的兼容（AJAX/CORS）等等；比如針對iOS 5/6以及Android 1.x/2.x/3.x里瀏覽器各種奇葩bug的兼容（說多了都tmd是淚水）；比如低版本Node需要繞開的那些坑。

2. 由於技術和標準演進導致被淘汰的方案：比如table布局；比如HTTP 1.x；各種緩存和離線應用的老版本的技術方案；

3. 跟平台強綁定的開發經驗：比如win RT開發的那一套前端解決方案；比如宿主平台的擴展開發；比如針對魅族/紅米等平台瀏覽器開發人員手抖造成的bug的填坑。

4. 第三方庫/框架的使用經驗：比ExtJS/AngularJS1等等（這裡指的是對API使用的經驗）。

# 原理型知識（Why）：

比如如何根據業務需求選擇業務模式；

比如在做包括但不限於NodeJS研發的過程中，對HTTP，對Stream，對系統調用，對文件系統，對進程管理的深刻理解；

比如在研究ECMAScript以及衍生語言的過程中，對語法/語義以及編程方式深入理解；

比如了解框架設計的原理，在業務開發的過程中參悟各種設計模式的工程意義；

比如在前端工程化的過程中培養自己的工程化思維，了解構建/持續集成/DevOps真正的意義所在；

比如形成完備的軟體開發的實踐習慣（TDD），積累協同開發的經驗，積累開源代碼的維護經驗等等。

------

當然，原理型知識也不是說就一定會一直有用下去。他怕的是類似於圖靈機那樣的技術革命，但是相較於經驗型知識，原理型知識的確會「扛貶值」一些。

我上面列舉的這些不涉及對演算法/數學能力等硬知識的歸納，不必多說，這些是最不可能變得沒用的知識（PS：沒事兒我還刷刷LeetCode呢……）

插一句：隨著人工智慧的發展，任何一個向前看的程序員最好都能涉獵相關知識，至少對於機器學習、深度學習等前沿知識做適當的了解。

我司有一個十幾年的老C++，我很佩服他，因為他一直保持著旺盛的學習態度。做客戶端（iOS/Android）研發，使用Go語言重構推薦系統，沒事兒就抱著一本《統計學習方法》推公式，沒事兒玩玩Tensorflow，自告奮勇為公司搭建BI系統……等等等等。

他之所以能對新的技術入手這麼快，是因為他經常追本溯源地看新技術背後的原理是什麼，做到了融會貫通。

嗯哼，對先進編程知識和科學技術的了解，是一個好的程序員的基本素質。這就好比你去了一個新的國家，如果你連對方用於溝通交流的語言都不會，那麼你必將被淘汰。

今天是520，希望大家能持續對編程的熱愛，這樣才不會擔心腦子裡的知識會不會變得沒用。

對了，再補一句：我們切記不要成為API工程師！

那時候我還在上海，同事們都知道我曾經做過律師。

吃飯的時候他們問我《勞動法》，我連連擺手，「新《勞動法》出台了，我都沒怎麼仔細看，你問我我把你帶溝里去了，呵呵……」事後證明，我太特么機智了，我同事講得比我溜多了！回頭我無聊查了一下，要按我記憶中的講，這「黑律師」的名頭就坐實了。

去年，我想重新殺回家裝行當，象徵性的做了點市場調查——我本以為對家裝行業我是了如指掌——然而，現實狠狠打臉，這才過去幾年？市場已經徹底變了。幾乎每個裝飾公司都有展廳，主推全裝，包干報價……這些都是我們那時候想都不敢想的事！我覺得我太特么機智了，知道先做市場調查，（^_^;）

我講這些什麼意思呢？

其實我就想告訴親愛的程序猿同學們：

不要把程序猿這份有前途的工作，想像得有什麼不一樣！

就一份工作而已，遵循所有工作的基本特點，遵循這個時代發展的基本特點，遵循……好吧，排比不出來了，呵呵。但意思就這個意思，不知道你懂了沒有？

看你一臉懵逼的樣子應該沒懂。

都已經21世紀了，同學，知識日新月異，更新換代的頻率早就不是農耕時代或者工業時代那一套了，一個人必須保持終身學習，才可能不落伍：不要以為這是程序員的特權！

哪個職業不是這樣？

還有些人說醫生，呵呵，就我這個外行，兩個孩子的爹，帶小孩做兒保都看出來了：不過才八年，育兒理念就已經升了一個級。包括那些新填的設備……對了，特別是醫院的IT化，牛逼，服了！你說，這些不需要學習？

例子就懶得舉了，信就信，不信拉倒。

嗶嗶了這麼多，還沒說：程序員所積累的編程知識在十年後將有多少變得沒用？

我入行程序員整整九年半，仔細的想了想，還真說不出來什麼學到的什麼知識現在變得沒用的。培訓的時候學的是WinForm和JSP，但相關的知識我直接套http://ASP.NET上面，感覺幫助還是蠻大的。然後折騰http://ASP.NET WebForm，什麼ViewState、頁面生命周期、DataReader/DataSet，好像現在用的是http://ASP.NET MVC，但那時候學會的HTTP無狀態協議、GET/POST、分層/封裝、資料庫操作，現在都還在用著啊……

最最關鍵的是，我學MVC奇快無比。現在我都還記得很清楚，看的那本書經常把MVC和WebForm做比較，我覺得非常暢快，甚至還加深了我對WebForm的了解？！

與之相對的，我剛入行的時候，MB的，看什麼都覺得不懂！捧著一本書，經常不知道它在說什麼，最恨的就是書里那些看不懂的詞，什麼強類型、解釋執行、編譯器、運行時……不知道這些詞從哪裡冒出來的，啥意思啊？有時候書里會做類比，講引用的時候說指針，講垃圾回收的時候說堆棧溢出……天啊！你不說還好點，你這麼一說，我腦子更特么一團漿糊：本來引用就理解不了啦，你還給我加個指針！你這是要玩死我啊？

大家明白了點什麼不？

知識是有傳承的。

無古不成今，你以為沒用的知識並不是你想像的那樣變得沒用，它只是融入了你的腦海，以另一種形式存在。

我也是最近才發現這一點的。

一是我做代碼直播（在鬥魚直播寫代碼是一種怎樣的體驗？ - 知乎）。因為要照顧觀眾，有時候我就想把道理講細一點，所以應該緩一緩。但我發現，我有點緩不下來？比如，代碼寫完，我基本上不設斷點不調試，報錯了直接看錯誤提示，然後就八九不離十的能找到錯誤原因……

開始我以為這是因為所有代碼都是我一手寫的，我很熟悉的緣故。後來發現不是這麼一回事，因為我還得在一起幫上給人「一對一」的幫忙。很多時候是趕鴨子上架啊，什麼亂七八糟的問題都有，我又只會ASP.NET（話說誠徵愛心大神入駐一起幫，幫幫這些菜鳥吧，有時間幣獎勵的喲，雖然現在還沒想好時間幣有啥用，呵呵），腫么辦？硬著頭皮上唄。

然後，我就發現奇蹟了：我特么真是太機智了，瞎貓都能撞到死耗子耶！ヽ(￣▽￣)?

怎麼回事？其實我就是幫他們理思路。比如今天幫忙看的這個：

小夥子用的是IIS上建FTP站點，我以前從沒這樣玩過。但他都愁了好幾天了，無頭蒼蠅一樣，不能拖了，於是我遠程看了他的操作，還有錯誤提示，憑「直覺」（只能這樣說了），這就不是他想的什麼操作系統的問題。

這就想你探路一樣，你能首先確定個大方向，複雜度一下降好幾個量級啊！學術點說，這是不是就是那「剪枝」能力？我看AlphaGo的說明望文生義撿到的一個詞。

然後就按我的方向「嘗試」啊，在伺服器上本機連本機能不能行？能行。那基本上就定了，網路問題。網路為什麼有問題，IP地址寫錯沒？沒有？真的沒有？用的IP是不是獨立IP？不是。這不就對了么！

真的是瞎貓碰到了死耗子？

那怎麼這隻瞎貓總能碰到死耗子呢？

很多同學沒有意識到：

知識會內化成一種能力。

而這是知識最好的結局。

其實今天這個社會，知識是相當廉價的：信息爆炸，知識俯首可得，難得的是能力。

插一句，今天我們的記憶方式都應該相應的調整：大部分時候，我們就記一個「索引」就夠了，剩下的，google幫忙，OK齊活！

有一個被用爛了的段子：張無忌學太極，忘完了也就學會了。我以前覺得搞笑誇張演義，後來越琢磨越覺得就是這個道理。

最後，還是回到上海吧。

那時候和公司的一位老外聊天，他說他爸退休後怎麼怎麼高收入別人搶著要，我就問了他：「你爸這個年紀了，他的知識結構跟得上么？他憑什麼呢？」

他說了一個詞，我一直記得，因為一直沒想到一個特別貼切的中文表達：common sense。

+++++++++++++++++

本回答收錄於：野生程序員 - 收藏夾 - 知乎

+++++++++++++++++

再打個小廣告，O(∩_∩)O~

註冊·一起幫（包含邀請人：葉飛，邀請碼：1786）

我自己個人開發的一個網站，開發過程全程直播並有錄像（自由飛：在鬥魚直播寫代碼是一種怎樣的體驗？）

設立的初衷就是為了降低自學編程（也包括各種電腦軟體使用等）的難度，尤其是一些對新人來說「莫名其妙的」問題（比如配置不對、連不上資料庫之類的），問題本身沒多少技術含量，但確實新人自學過程中的攔路虎，自己瞎折騰不知道要花多少時間，但如果有人遠程桌面幫忙看看，很快就可以解決。

有興趣的同學註冊看看吧？

註冊·一起幫（包含邀請人：葉飛，邀請碼：1786）

@程墨Morgan 給出了一個10年職業程序員看到的變遷。我這裡給一個10年前剛入門，到現在有幾年工作經驗的視角吧。

10年前（2007年），正好是我第一次寫「大型」項目 - 一個手機軟體下載網站。這裡整理一下當時學到的技術現在究竟怎麼樣了：

HTML/CSS/JavaScript

應該不會有人認為10年後的今天這三樣變成沒用的知識了吧？我很難想像有任何人能不掌握這三個代表還能成為牛逼的前端工程師。

稍微有點區別是，這三個代表現在的規範變了。HTML和CSS增加了許多特性，所以當時學的基本是現在的子集。

JavaScript變化最大，從當時的ES3到現在的ES6。但我認為去適應新特性和語法的變化所付出的學習成本是很低的，比較難適應的是整個前端開發模式的變化 - 從當年的伺服器端的模板渲染到現在大前端的工程化（當時我以為JS最大的作用就是做QQ空間特效，所以戲稱他為QQ空間語言Orz）

jQuery 1.0 or 1.1（不記得了）

現在前端再談jQuery似乎確實是比較過時了。但jQuery即使在今天作為一個utility的lib依然過的不錯。有沒有讀過jQuery（或者任意utility lib）代碼依然是一個簡單粗暴的評價前端工程師水平的點。

http://ASP.Net 2.0

從這個網站之後，我就再也沒寫過C#代碼。所以其實http://ASP.net本身的知識對我來講確實是再也沒用過。而且那時候流行的後端模板渲染，現在也很少了。但沒記錯的話，當時http://ASP.net已經是基於MVC的架構，所以框架上的東西，到現在也不算是過時（13年工作的時候我還寫過Spring MVC）。

資料庫

實際上我現在已經不記得當時用的什麼資料庫了。。。不過既然是http://ASP.net的話，應該是SQL server才對。SQL顯然不是過時的技術，只是現在多了像Mongodb這種NO SQL的選擇。所以當時的知識依然是現在所需要的子集。

ATLAS (Ajax)

額，現在知道ATLAS這貨的人估計比較少。簡單來講他就是http://ASP.Net版的Ajax框架。而Ajax完全是現在Web開發的標配。

總結一下

雖然我學的都是偏應用層的東西（不敢跟程序員的那三大浪漫比），但10年前累積的絕大部分編程知識現在依然用著。小部分現在再也沒用到的東西，也讓我更深刻的體會到了他們被淘汰的原因和現在方案這麼設計是為了解決什麼問題。

功利的講，大家都希望能學到那些「永恆不變」的知識，都擔心自己現在學的技術將來被淘汰掉。我個人認為做到兩點最重要：

1. 不要光學怎麼用（光學API），而是要去學這種設計背後解決了什麼問題。

2. 不要給自己定死一個Title（「前端工程師」，「後端工程師」，「Python工程師」），就僅僅局限於這領域。作為軟體工程師，我們的最終目標是解決問題。框架也好，庫也好，語言也好，只是解決問題的手段而已。我的價值在於能解決工程上的問題。至於這個問題是前端的，後端的，Python的。說實話，I don"t care。

今年剛好是我編程第20個年頭，也來湊個熱鬧吧。
老規矩先說結論：絕大部分知識都還有用，如果你大部分知識都沒用了，那通常是因為你換工作了而不是技術沒人用了。
看到很多人說什麼10年前的東西不用了，我想請各位再看一次這些朋友的答案，然後回想下，他們說不用了的那些技術，是全行業都不用了么？
今年是2017年，我們想想，10年前出現了什麼呢？jquery是06年的，hadoop也大約是06年的。好吧，肯定有人說了，10年前有這個技術不代表我當時就會學啊，那我們往前看，20年前，1997年，我們有什麼呢？VC++6發布了，額，現在想想簡直是陰魂不散啊，到現在還有很多學校在教vc6。你以為只是學校裡面用么？那你太天真了，我接觸的就有公司還在用（當然也還有vb6）。恩，如果沒記錯的話，考級也還在考這個吧。
現在真正意義上的主流使用的語言，平台框架，哪個沒有很多很多年的發展呢？
當然，如果拋開工具，只談思想，框架，模型，那更新就更慢了，這裡不多說。
當然，就像結論中說的，對於一個具體的程序員來說，如果你10年都在同一個崗位，開發著同一樣東西，恩，你應該不會來知乎看到我們討論這些。每個人都是要進步的，尤其是在這樣的一個時代，最新的技術就像是一種符號，代表著一個行業的活力。時尚設計師每年都要拿出新的趨勢，谷歌每兩三年就要炒熱一個技術領域（機器人，無人車），人工智慧演算法不到5年就要大換血。程序界呢？好像有點比上不足比下有餘，至少相對於傳統的工科，比如機械領域，那是顯然的快速更新，畢竟他們已經有100年沒什麼新理論了。但就在我們追捧這個指標的時候，我們有沒有想過這真的是一個好的指標么？如果一個程序員說，5年我用的技術就都更新了，那我是不是可以理解成，他做出來的程序，沒有一個用戶用了5年的呢？因為他的程序已經不需要他維護了。
確實，學習更新的技術、發展更好的生產力是美好的，應當鼓勵的。但當我們把這些拿出來攀比、評判的時候，是不是就已經開始畸形了呢？
所以我覺得，大家真的沒有必要在這裡為什麼學過的東西有沒有用患得患失，你就算是個跑業務的，10年之中換幾次工作你當年學習的某個領域的背景知識都會更新。無論你學的是什麼，10年的努力都會讓你受益匪淺，恩，當然，10年的倦怠也一定會讓你遠離行業中心。

我想我的回答應該比較具備典型性。因為我轉行了。

這個問題我十五年前想過。

十五年前，拿著delphi做企業自己的管理系統，還是C/S結構的，中間層都沒有，直接連資料庫，SQL直接寫死

後來人手不夠，找了一個剛畢業的孩子，啥都不會那種，三天就上手了

然後我就開始想，這些東西，三天就能學會，以後我們怎麼面對職場競爭？

隨著公司一天一天變大

單伺服器變集群、小機、雲

win32變成多平台

內部網變公網，乃至國際互連

單一編程語言編程多語言混合編程

從沒有項目管理到各種管理方法論都趟了一遍

一轉眼十五年過去了

我也不再寫代碼了，甚至工作領域都轉到了零售管理，完全和技術無關了。

對於現在的我來說，如果正面回答題主的問題——多少變得沒有用——會給出一個無比長的列表

因為，這些「術」的東西，對我現在的職位來說，統統都沒用了。

但我仍然是公司各個管理區域營運團隊中最和別人不一樣的，沒有之一。

1、工具思維，手巧不如家什妙，做程序員，開新坑先要技術選型，做管理，過程中如何實現過程監控和快速反饋，也要先找好管理工具，別人開始做事的時候，往往我還在琢磨工具，但一般來說都會後發先至。比如門店日常營運標準執行，別人已經組織好了檢查團隊，神秘人合同也簽好了，我還在想視頻監控和圖像識別，等我想明白了，給IT部門提報了需求，人家已經檢查了好幾輪，然後系統上線，大家的效率陡然提升，他們之前的動作都變成無用功。

2、快速學習，學習能力是所有人都需要的，但程序員的學習能力要求不同，加上快速二字比較妥當，因為程序員的學習需要和實踐高度統一，面對一項全新的技術，一天讀文檔入門兩天寫代碼試水三天基本上手一個禮拜就要出活兒是非常正常的速度，這就要求程序員的學習，必須快速抓住核心、理清脈絡，枝枝蔓蔓的細節知道哪裡有答案就可以了，剩下的就是在實踐中逢山開路遇水架橋掉坑了就認栽，先爬出來然後罵街，而這種學習的習慣形成之後，無論在哪個領域用起來都能把別人嚇一跳，感覺你跟萬事通一樣——啥玩意都知道——其實台上一分鐘，台下十年功，他們都不知道這根本就是程序員的日常。

3、全面思考，做管理少不了謀算，但是程序員出身的謀算更深，一件事情在規劃的時候，程序員出身的，寫出來的預案能比別人多一成，前因後果過程方法每一個細節都有，一些八百年可能都碰不上的點狀異常，都會有多少的提及和處理準備。別人笑我太瘋癲，我笑別人看不穿，他們哪兒知道一個邊界條件沒考慮到，少抓了一個異常，然後被測試團隊堵門嘲笑的恐怖……更恐怖的是，當真的發生了罕見的問題，而你居然有預案，「半仙」的標籤就被貼的結結實實了。

4、系統視角，做開發，除非只想做個看需求寫代碼的最底層碼農，否則對業務「知其然知其所以然」的要求遲早會擺在你的面前，經歷了這一遭，基本上企業就看了個通透，商業模式、管理模型、業務流程、歷歷在目，這比什麼MBA的案例分析都深刻，程序員，尤其是職位比較高的程序員，在轉職業務崗位之後，一般會首先乾的是爭取對業務本身有一個系統性、全局性的視角，而這往往會開展業務找到更深刻的切入點提供巨大的幫助。

以上是我覺得當年的積累對我現在幫助最大的地方，其他的真的用處不大了。

其實，以上四條，都是好壞參半

工具思維，有可能你起步會比別人慢，所以，要掌握一個度，或者學會兩條腿走路

快速學習，有可能會不由自主扎到業務細節當中，而管理崗位是有一個下屬團隊干這個事兒的，管理者太深的紮下去，未必好，這事兒，得仔細權衡

全面思考，會不會迷失在各種異常當中，業務和管理的主脈有沒有抓住？這個很重要

系統視角，信不信隨你，看問題思維層面太高了，會習慣於妥協，因為有的時候，你看到了整個業務流程的互相制約，反倒把當下手頭業務環節的異常合理化了，會少了戰鬥精神，而管具體業務，不會PK絕對是不行的。

以上。

大抵如此吧

我們開發者的知識和技能分了三個層次：

信息與知識
專業技能
底層認知和思維框架

以C++中的純虛函數來說明這三個層次。

C++中純虛函數的定義，就是知識。

你運用純虛函數設計一組類（比如Shape），解決對某一類對象的管理和抽象調用，讓代碼簡潔、易理解、易維護，提升了代碼質量、運行質量，降低了維護成本。這就是專業技能。

而你能通過純虛函數，學會抽象思維、分類、泛化與特化等思維方法，這就是獲得了底層認知。這些認知，放在新出現的技術上、問題上，依然適用。比如你不用 C++ 了，用 Kotlin ，這部分認知可以無縫遷移，反過來幫助你迅速把 Kotlin 玩兒得很順暢。

所以，其實不用太關心你學到的具體信息和知識在十年後有多少會變得沒用，而要重點關心你是否在學習這些知識、運用這些知識解決問題的過程中建立了自己的認知習慣和思維框架。這些東西，是半衰期很長的，不誇張地說，極有可能讓你終身受益。

十幾年前，我正用 VC++, WTL 寫 ActiveX。

那是個 windows 程序，幾千個商業用戶使用，分布在世界各地，各地還有分公司，開發自己的商業模塊，我們公司負責主程序。

VC++寫的框架里嵌套了IE的控制項，IE調用ActiveX控制項，並檢測是否有最新版本，自動升級。這也是為什麼要用ActiveX。至於WTL，當時網路慢，WTL寫出的UI省空間，所以用它。

後來我們老大發現，分公司的人C++不行，經常寫bug，把整個程序搞崩潰，痛定思痛，在框架里又嵌套了個 Web 控制項，讓大家用 HTML，javascript寫模塊，從此就告別了C++寫UI的刺激生活。這部分重構還是我負責的。

當然，現在我不寫這些東西了，技術細節也忘的差不多了。

但是，再看看那時面對的問題，是不是有些眼熟？

IE控制項，ActiveX，WTL，HTML，說到底，就是為了熱更新。

持續集成，持續交付，熱更新，當前的 app 也有著各種各樣的解決方案，而且原理上，和十幾年前我們的系統也一脈相承。

技術變了，平台變了，但問題的模式沒變。

技術細節，會隨著技術消亡，但留下來的是分析問題，解決問題的能力。

學一個類庫，可能一兩年有用。

掌握個框架，可能三四年有用。

背會個標準，可能五六年有用。

學會門語言，可能七八年有用。

大學裡的基礎課，可能十年以上都有用。

那又如何？

框架有坑，今天你踩了，就算以後沒用，你也得想法給它填了，日子要過，項目要交，只要今天有用，那就要學！

Javascript 那麼多坑，前端庫如過江之鯽，還不得吭哧吭哧的學，誰也不敢說，這技術十年後可能用不上，所以就不學了。

技術是變著法的解決問題，一個技術消失，意味著有更好的解法了，不必糾結，把眼光放在分析問題，解決問題上，往往會有更好的提高。

非數學的部分基本都淘汰了或者大幅貶值了，數學的部分（如演算法和數據結構）從以前的經驗看比較保值，但以後也不確定。

API和語法背誦玩就是等著扔掉的，這應該是所有人的常識，也是學編程之前需要從心裡接受的事情。

你積累是知識點，套路，技巧，那很快就會沒用

你積累的是思想，是業務深度，是工作方式，很久才會沒用

你積累的是系統的知識體系，是樂於挑戰的精神，是去偽存真的能力，開放的思維方式理論結合實踐的習慣

那一輩子有用

本身有用沒用這事情就沒價值，總是在趁著有用的時候養養家，打打魚，看天發財

那什麼都沒用，就錢有用，何必非得寫代碼。

十幾年了，正好應該可以有資格回答了。

十五年前在大學裡拉私活做，用的是Java（網站）和C（Brew，2002年的手機app，當然當年叫「嵌入式編程」）那時候剛開始有軟體學院。我自己的看法是學的東西比起計算機系更實在，更有用，更能拿來幹活，於是資料庫可以考到90多而計算機組成不到70，完全是實用至上的想法。最極端的是項目管理課的大作業Demo，直接外面扒了個很有設計感的網站純靜態頁面做了個假的workflow，用最近流行的話可以算是PPT造網站。

十二年前在一個小創業公司，做的是政府項目，寫著C#和SQL，漸漸發現代碼做的好不好其實關係不大。。。因為上線演示之後真去用的寥寥無幾。非常羨慕只大我們幾歲的區鎮府信息化副主任，有房有車平時的工作就是向我們提需求做完了去給主任演示。覺得自己漸漸摸到了世界運行的規則。

九年前進微軟不久。之前的公司雖然做得很開心，但是覺得按照收入想在上海買房是遙遙無期，於是還是從了大公司。一直對「實在」的追求，以及對數據結構演算法的不在意讓我只（no offense）拿到了SDET的offer，寫著VB和C++讓我的心情很不爽，卻為了房子而不得離開。於是寄情於infrastructure和workflow的改進。

六年前在美國微軟，在努力的做Windows 8，工作語言卻變成了JS，當年對著IE腹誹的夜晚依然存在腦海。儘管我們已經很幸運，只需要確保在最新版本上運行。Workflow的改進也即將結果——後來獲得了微軟公司級別的大獎，現在照片還掛在公司的Hall of Fame網站上。

三年前借著workflow改進的經驗終於把SDE的帽子戴回來，用著Typescript + C#，順應政策，做了Windows 10新流程的相關工具，可自己知道，差不多該走了——老婆又懷孕了，而微軟只有一個月的陪產假。

今天，在Google用回Java，但大多數的代碼用了Dart。和一群比我至少小五歲的聰明人干著一樣的活，再一次慢慢的有了手中掌握的感覺。路還長，越來越覺得自己還可以再干20年。

卡在青年和中年的線上，我也開始喜歡總結了：

1. 框架，甚至是語言，都不是自己賴以生存的東西。多做幾種活之後，自然不會依賴於一個環境。

2. 對未來的期待，往往會受到當時眼界的束縛。時刻準備著生命中新的變化吧，變化足夠大的話，到來的時候會輕鬆顛覆自己的看法。

3. 興趣對這一行真的很重要。毅力有用，但是沒有驅動力的話，撐不了多久。發現自己興趣消失了，是最可怕的事情。要麼找到新的興趣點，要麼就離開吧。人生這輩子，如果有一半的時間做一天和尚撞一天鐘，真的很可怕。

4. 家庭不應是職業發展的阻礙。如果越來越覺得是，可能需要想一下，我們是不是拿它當了借口。壓力肯定有，變成動力不是更好？

今天的西雅圖，熱。

你現在積累的知識和技能不要說在10年之後，5年之後都未必是有用的。但並非只有程序員是這樣。
還記得之前知乎就有過一個工作被機器取代是如何一種體驗。大家說了很多過去的，現在的和未來的例子。社會在進步和發展，那當然過去的知識和技能會慢慢落後於行業和整體社會的發展，這是非常正常的事情。醫生，律師，水管工，英語老師也同樣需要不斷學習新的東西，積累經驗才能提高自己。
但為什麼程序員覺得自己的技能需求變化尤其之大呢？因為行業發展的速度太快了啊。程序員之前會這麼覺得，最主要是現代軟體工程的發展速度實在太快了，需求上升實在太快了，發展速度快，自然舊的一些技術知識和技能點會被淘汰掉。
有沒有一些不會被淘汰掉的呢？當然，舊的技術細節容易被淘汰掉，但是計算機科學和軟體工程的核心思想，理念和理論是不會淘汰的。除非出現了極為跨越式的進展，徹底革新了這些核心的思想和理論。在某種程度上說，近些年的軟體工程變化也是有一定本質上的，主要原因是硬體的發展使硬體成本大幅度下降，軟體的需求大幅度增長，對工程師協作開發大型軟體的要求大大提高但實現細節越來越弱化。這在某些領域可能是本質性的變化。
這還只是在傳統軟體工程領域的發展帶來的變化，機器學習現在的跨越式進步，主要是深度學習帶來的，真正全方位影響社會的時候還沒真正開始呢。VR/AR對整體社會的全方位影響也還沒有真正開始呢。機器人技術各方面取代和增強人類才剛剛開始呢。醫生不需要學習新技術嗎?手術機器人不需要去學習如何操作互動嗎，AI診斷不需要去學習如何利用輔助嗎，增強現實輔助手術不需要去學習嗎。
當然，話說回來，程序員要學的東西可能更多，變更更快。但這是因為站在風口浪尖上，這是好事不是壞事。因為很難碰上「系統性風險」，比如普通工人面對工業機器人，司機面對自動駕駛，翻譯面對機器翻譯這樣無可奈何的事情。程序員只要持續學習總有東西可以學習，總可以進步隨著世界一起發展，但一個高技術工人，有一天被工業機器人取代的時候，他再願意努力，又哪有努力的方向呢？
最後，程序員最好是系統性的學習整個體系，培訓班培養出來的還是很容易被淘汰，因為那些往往只學習到了具體的技術細節。科學，工程，技術，事實上是三個領域，不好好學習計算機科學和軟體工程的話，在計算機這麼個日新月異的領域，技術細節很容易被淘汰的狀況下，必然會無比憂慮。你看科班出身的人大多不覺得技術更新換代是什麼壞事情。

總的來說越靠近上層，迭代速度越快，而下層接近硬體部分更新較慢。只要馮諾依曼體系還在，操作系統部分的大框架就很穩定。如果做上層軟體則需要注意積累設計思想方面的知識，這個放在哪裡都通用。
最後說明一下，一入編程深似海，從此必須要持續學習，更新自己的知識結構。所有的不變和變化都是相對的。

1、基礎的東西不會變，有時候不是因為基礎的東西好，而是太多公司或者人力鋪張在這上面了，已經形成了產業或者標準，比如類UNIX、TCP/IP，比如C、HTML、SQL等等。

2、庫或者框架總會不斷被淘汰或者更新，因為會有更好的出來替代，所以浪費時間學習某個公司或者組織的庫是沒用的，只是應急或者用到的時候學點就行了，夠用為準，多餘的細節的不用學，學了成了某個庫或框架的專家也沒用，因為會被淘汰。

3、思想不會變，比如面對對象、函數編程、設計模式，不管什麼語言都通用的，花時間在一種語言上學通，就可以複製到其他地方。

4、語言有無數種，但是任何一個叫做程序的東西都必然有以下這些東西：各種數據類型、循環、迭代、判斷、分支、數據封裝、資源管理、調用等等。所以學會一種語言再學另一種只要學會這些骨架的東西就能快速通關。

5、演算法也不會變，什麼遞歸、排序、集合、搜索、各種樹、散列表等等，這些永遠不會過時。

6、一個程序員起碼得會一種靜態語言，一種動態語言，一種資料庫，若干生產力工具的使用吧？儘管這些具體的東西會淘汰，但是基礎萬變不離其宗。

一個程序員掌握所有底層必須學的東西，沒有十年八年根本不可能做到，所以花在底層積累的十年一定不會變得沒用，但是如果你只想快速上手，大把時間花在上層建築，想走捷徑，那就會浪費時間走彎路，自己也會因為知識淘汰而感到沮喪。。。

一切都有可能過時，包括思想，只有學習是永恆的。