不要再學習框架了！

https://zhuanlan.zhihu.com/p/53626164

 

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： 做者說他買了這些書：

• 《程序員修煉之道》
• 《代碼整潔之道》
• 《程序員的職業素養》
• 《領域驅動設計》
• 《測試驅動的面向對象軟件開發》
• 《持續交付》

不是打擊你們的熱情，但這都是一些軟技能書籍。

我曾經在一次 10 小時的飛行中看《程序員修煉之道》這本書，可是由於太無聊睡着了兩三次。初學者也許能從中學到一些東西，但都是剛入行幾個月須要學習的常識性知識。

每一個人的書架上應該都有這類書，以及其餘更經典的書，好比《計算機程序設計藝術》（Art of Computer Programming）。有趣的是，我發現幾乎沒人看這些書，並非由於它們很無聊（軟技能），也不是由於很難學（AOCP），只是由於把它們擺在書架上的儀式感。好像書架上沒有幾本沒看過的編程書，你就很差意思稱本身是個程序員。

棄框架而專轉向軟技能書籍彷佛並非進步。若是你想學習價值更長久的東西，仍是學習《計算機科學》更實用點。

我是說算法和數學。

這還意味着你會接觸功能編程或邏輯編程等範例。我推薦 Haskell，不是由於你須要學習另外一種語言，而是由於這個生態系統中的知識上限很是高，並且它是目前關於函數式編程的論文使用的通用語言。

有些技術比其餘技術更持久。例如咱們仍在使用 POSIX。CPU 體系結構不斷髮展，但 CPU 處理指令和訪問內存的基礎知識沒有發生什麼變化。框架和庫十年河東十年河西，但併發性、並行性、異步性的基本原理不會改變。

做者回復：「軟技能」這個詞用得不許確。

這些書並非關於軟技能的，而是軟件編程：軟件質量、軟件設計、軟件測試、部署、軟件生命週期等。

《計算機科學》並不能教會你軟件編程。

做爲工程師，你不須要學計算機科學，而是編程技巧。

網友 4： 大部分開發者所作的項目都是由其中的利益相關方來決定成敗的。

因爲沒有使用正確的算法致使產品失敗的案例數量，和由於指望不合理或構建錯誤的軟件致使產品失敗的案例數量相比，兩者之間至少存在一個數量級的差異。

溝通尤爲重要，因此關於溝通和架構的書也很重要。

做者回復： 這難道不是選擇誤差的鍋嗎？管理不善的項目確定不會成功。那些算法很差的項目雖然能上，可是存在不少技術瑕疵。

閱讀軟技能書籍就像在工做中接受強制性的反腐訓練。很明顯這很無聊，然而仍是有些人須要它。

查看英文原文：

https://sizovs.net/2018/12/17/stop-learning-frameworks/

今日薦文