AI前線導讀： 作爲開發人員，我們需要跟上技術發展的步伐。每天，我們都在學習新的編程語言、框架和庫。但是，技術和時尚一樣，正在以光速變化。本文作者認爲，這是一場沒有贏家的比賽，因爲技術的發展沒有終點。因此，他建議大家停止學習框架，而是把最寶貴的時間花在可遷移的技能上。本文的英文原文在Hacker News上獲得了接近 500 個點贊。其實每過幾年都會有類似的文章出現，然而程序員卻依然疲於學習新的框架，希望本文能給你帶來一些啓發。
更多幹貨內容請關注微信公衆號“AI前線”（ID：ai-front）
我們是開發人員。我們需要跟上技術發展的步伐。每天，我們都在學習新的編程語言、框架和庫。我們知道的現代化工具越多越好。
跟蹤Angular、React、Vue、Riot、Ember、Knockout的最新進展很有意思。
但是，我們在浪費自己的時間。
時間是我們擁有的最寶貴的資源。時間是有限的，不可再生的，你無法多買一點。
技術和時尚一樣，正在以光速變化。爲了趕上其發展速度，我們就需要跑得很快。這場比賽沒有贏家，因爲它沒有終點。
來自Martin Scorsese 2013年拍攝的《華爾街之狼》
我的導師曾給我上過這樣一課。
導師：“Ed，你在做什麼？”
我（驕傲的）： “我在讀一本有關使用GWT構建現代Java應用的書。”
導師： “爲什麼？”
我： “作爲一名Java開發人員，我需要緊跟潮流。GWT是流行趨勢。”
導師：“在GWT之前，你讀過什麼技術書籍？”
我： “一本關於Apache Tapestry的500頁的著作。 Tapestry那時是流行趨勢。”
導師：“Tapestry現在還流行嗎？”
我： “不流行了。現在流行GWT。”
導師：“你還可以重用Tapestry的技能來解決當前的問題嗎？”
我： “不能，現在沒人用它了。”
導師：“Tapestry的知識能幫助你更好地理解GWT嗎？”
我： “不，不能。但我看到了一些重疊的模式。”
導師：“那是設計模式。它們能幫你解決當前的問題嗎？”
我： “是的。可以解決其中許多問題。”
導師：“技術變化無定，但有很多共同點。確定好優先級。將80%的學習時間投入到基礎知識上。剩下的20%用於框架、庫和工具。”
我： “嗯…僅20%用於框架、庫和工具？”
導師：“是的。反正你在工作中解決問題的時候會學習它們。”
我： “謝謝。”
導師：“你以後會感謝我的。”
這個建議改變了我的生活。我從我的書架上拿走了所有介紹框架的書。這些書從50本降到了0本。我總算鬆了一口氣！
我買了一套常青樹著作。這些書佔據了我80%的學習時間。
我還買了一本關於當前技術的書。Lindy效應表明，Spring框架一定是項不錯的投資：
技術未來的預期壽命與其當前的年齡成正比。它每多活一段時間，預期壽命就會延長。
一項技術在市場上存在的時間越長，投資就越安全。
不要急於學習新技術——它有很高的死亡機率。
時間會證明哪項技術值得投資。時間是你最好的導師。學會等待。
10年過去了。我爲50個不同的軟件項目提供了幫助。由於這些建議，我學到的所有東西都可以跨公司、團隊和領域遷移。我的知識到今天仍然有用。我沒有浪費時間。
除非你能看透表象，否則所有的項目看上去都不同：
- 編程語言不同，但設計類似；
- 框架不同，但會體現出同樣的設計模式；
- 開發人員不同，但與人打交道的規則一致。
記住——框架、庫和工具變化無定。時間寶貴。
來自Andrew Niccol 2011年拍攝的《時間規劃局》
把最寶貴的時間花在可遷移的技能上——那些永不過時的技能。
- 不是微服務框架，而是演化架構；
- 不是新的編程語言，而是整潔的代碼、設計模式和DDD；
- 不是LeSS、SAFe，而是精益生產原則；
- 不是Hystrix，而是容錯模式；
- 不是Docker，而是持續交付；
- 不是Angular，而是Web、HTTP和REST。
HackerNews熱門評論
在Hacker News上，這篇帖子引起了熱烈討論，然而，並不是所有人都認可作者的觀點：
網友1：學習框架的一個好處是，你可以理解作者的內心，另一個好處是你可以看到作者最初的抽象模式和想法。
學習Rails教會了我元編程、可逆數據庫遷移、ACID以及ORM的優缺點。學習使用C＃構建XAML應用程序讓我瞭解了雙向數據綁定、MVVM、DSL和套接字通信。學習 React 和 Redux 讓我搞懂了協作線程、函數式編程、事務狀態管理和測試前端功能，而不使用 selenium 和 webdriver。
現在，我已經“知道”了大部分這些知識，但此前並沒有將它們應用到現實世界中。在精心設計的框架中實現這些經驗，教會了我很多理論以外的關於實際應用的知識。
網友2：框架有好有壞。
原文裏提到的 GWT 我用過，體驗非常糟糕。當我在GWT最初發布時試用過，它只適用於演示代碼/頁面。
解決任何更復雜的問題都要求我搞懂Java、JavaScript以及他們用來將 Java 代碼轉換爲“生成JS”代碼的代碼/系統/進程。對於我有限的大腦，這個問題的複雜性是O（n ^ 3）。
也許這種狀況已被改變，2017年我看到他們又發佈了一個新版本。
Python 作爲一種語言/框架在我看來非常好，它非常容易學習、調試、創建複雜的系統並根據需要深入挖掘。
網友3： 作者說他買了這些書：
- 程序員修煉之道（The Pragmatic Programmer）
- 代碼整潔之道（Clean Code）
- 程序員的職業素養（The Clean Coder）
- 領域驅動設計（Domain-Driven Design）
- 測試驅動的面向對象軟件開發（Growing Object-Oriented Software, Guided by Tests）
- 持續交付（Continuous Delivery）
不是打擊大家的熱情，但這都是一些軟技能書籍。
我曾經在一次10小時的飛行中看《程序員修煉之道》這本書，但是因爲太無聊睡着了兩三次。初學者也許能從中學到一些東西，但都是剛入行幾個月需要學習的常識性知識。
每個人的書架上應該都有這類書，以及其他更經典的書，比如《計算機程序設計藝術》（Art of Computer Programming）。有趣的是，我發現幾乎沒人看這些書，並不是因爲它們很無聊（軟技能），也不是因爲很難學（AOCP），只是因爲把它們擺在書架上的儀式感。好像書架上沒有幾本沒看過的編程書，你就不好意思稱自己是個程序員。
棄框架而專轉向軟技能書籍似乎並不是進步。如果你想學習價值更長久的東西，還是學習《計算機科學》更實用點。
我是說算法和數學。
這還意味着你會接觸功能編程或邏輯編程等範例。我推薦 Haskell，不是因爲你需要學習另一種語言，而是因爲這個生態系統中的知識上限非常高，而且它是目前關於函數式編程的論文使用的通用語言。
有些技術比其他技術更持久。例如我們仍在使用 POSIX。CPU 體系結構不斷髮展，但 CPU 處理指令和訪問內存的基礎知識沒有發生什麼變化。框架和庫十年河東十年河西，但併發性、並行性、異步性的基本原理不會改變。
作者回復：“軟技能”這個詞用得不準確。
這些書並不是關於軟技能的，而是軟件編程：軟件質量、軟件設計、軟件測試、部署、軟件生命週期等。
《計算機科學》並不能教會你軟件編程。
作爲工程師，你不需要學計算機科學，而是編程技巧。
網友4：大部分開發者所做的項目都是由其中的利益相關方來決定成敗的。
由於沒有使用正確的算法導致產品失敗的案例數量，和因爲期望不合理或構建錯誤的軟件導致產品失敗的案例數量相比，二者之間至少存在一個數量級的差別。
溝通尤其重要，所以關於溝通和架構的書也很重要。
作者回復：這難道不是選擇偏差的鍋嗎？管理不善的項目肯定不會成功。那些算法不好的項目雖然能上，但是存在很多技術瑕疵。
閱讀軟技能書籍就像在工作中接受強制性的反腐訓練。很明顯這很無聊，然而還是有些人需要它。
查看英文原文：Stop Learning Frameworks