這是一篇譯文，原文在 Hacker News 上獲得接近 500 個點贊。

每過幾年都有類似的文章出現，然而程式設計師卻依然疲於學習新的框架，看完此文希望對你有所啟示。

Update:

1. 本文已經翻譯了「正反雙方的觀點」，不知有什麼好駁的哦。
2. 有人說不相信有「框架很熟基礎卻不會」的人，其實這種人挺多的，參考一下這個
   • 面試一個5年的前端，卻連原型鏈也搞不清楚，滿口都是Vue，React之類的實現，這樣的人該用嗎？

譯文開始

我們是程式設計師，每天都在瞭解最新的技術，每天都在學習程式語言、框架和庫。
因為我們知道的現代程式設計工具越多越好，對吧？

不停地追隨 Angular、React、Vue、Riot、Ember、Knockout 的腳步還真是一件有意思的事情呢。（譯註：反話）

但這其實是在浪費時間！

時間是人類最寶貴的資源。時間是有限的、不可再生的，你可以用錢買任何東西，卻買不了時間。

技術，就像時尚，在以光速在變化著。為了趕上它，我們需要跑的非常快。
但是這個跑道上沒有終點，所以沒有贏家。

我的導師曾經這樣教我：

導師：艾德，你在做什麼？
我（自豪地說）：我在讀一本關於如何使用 GWT 構建現代 Java 應用的書呢。

導師：你讀它做什麼？
我：作為一名 Java 開發者，我需要跟上潮流。GWT 就是現在的潮流。

導師：你在讀這本書之前還讀過什麼書？
我：我讀了一本關於 Apache Tapestry 的書，那本書有 500 頁。Apache Tapestry 是之前的潮流。

導師：Apache Tapestry 現在還是潮流嗎？
我：不是了，GWT 才是。

導師：你之前從 Tapestry 學到的技能現在還能用嗎？
我：不能用了呀。

導師：Tapestry 能幫助你更好地理解 GWT 嗎？
我：不能。不過兩者都用到了一些設計模式。

導師：那就是設計模式了，設計模式能幫你解決你遇到的問題嗎？
我：可以，而且幫助很大。

導師：新事物來了又走，其實有很多共同點。你應該學你該學的。你應該把你 80% 的學習時間用在學習基礎上，剩下 20% 的時間才是用來學習框架、庫和工具的。
我：哦……只留 20% 的時間學習框架、庫和工具？

導師：是的。你在工作中解決問題時自然就會學會框架、庫和工具。
我：謝謝指導。

導師：你之後還會謝我的。

導師的建議改變了我的生活。我把書架上關於框架的書全部都扔了，五十本書一本不剩，扔得我很開心。

我買了一些不會過時的書，並用 80% 的學習時間來讀這些書：

• 程式設計師修煉之道 The Pragmatic Programmer
• 程式碼整潔之道 Clean Code
• 程式設計師的職業素養 The Clean Code
• 領域驅動設計和實踐 Domain-Driven Design
• 測試驅動的物件導向軟體開發 Growing Object-Oriented Software, Guided by Tests
• 持續交付 Continuous Delivery

我只買了一本關於最新技術的書，是關於 Spring 的。因為根據林迪效應，學習 Spring 是一項不錯的投資。

林迪效應認為，對於不會自然消亡的事物，如一項技術或一個想法，其預期壽命與其當前的生命成正比；即，只要這一事物多存活一天，就意味著其預期生壽命會更長一些。

一項技術在市場上存活得越久，就越值得我們投資（學習）它。

不要急著學習新技術，因為這些技術很可能會死。

時間會告訴你答案，你要學會等待。

十年來，我參與開發過 50 個不同的軟體專案。得益於我導師的建議，我學的所有東西都適用於不同的公司、團隊和領域。我的知識今天仍然有用。我沒有浪費我的時間。

如果你看得更深入些，你會發現所有的軟體專案都是類似的：

• 用的程式語言雖然不一樣，但是設計方法是類似的。
• 用的框架雖然是不一樣的，但是設計模式是類似的。
• 參與的開發者是不一樣的，但是如何和這些人打交道是不變的。

記住，框架、庫和工具來了又走。時間才是珍貴的。

將你的黃金時間用於學習通用技能，那些不會過時的技能。

• 不要學習微服務框架，學習演進式架構（Evolutionary Architecture）。
• 不要學習新的程式語言，學習程式碼整潔之道、設計模式、領域驅動設計（DDD）。
• 不要學習 LeSS 和規模化敏捷框架（SAFe），學習精益生產原則（Lean manufacturing principles）。
• 不要學習 Hystrix，學習容錯模式（Fault Tolerance Patterns）。
• 不要學習 Docker，學成持續交付。
• 不要學習 Angular、React 和 Vue，學習 Web、HTTP 和 REST。

熱門評論：

我同意你的大部分觀點，但是我覺得你不用這麼堅決地不學習一些東西。
「學習工具」與「學習它所蘊含的設計模式」並不互斥。

2007 年的時候我曾經試圖搞清楚到底什麼是「資料層」以及怎麼使用它，這是當時流行的 ORM 概念。我向別人問了一堆關於 NHibernate（譯註：一個面向.NET框架的物件關係對映解決方案。主要用來把物件模型表示的物件對映到基於SQL的關係模型資料結構中去）的問題，很多人都回復我說「你應該先搞清楚原理，而不是學習這個工具」。但我心裡想的是，shit，不行啊，因為我需要通過大量的實踐才能理解這些原理啊。這是我學習的重要途徑。

所以我覺得學習這些蘊含了豐富原理的工具其實是非常有用的。
同樣的道理對很多工具都適用。比如 React，如果沒有 React 誰能理解虛擬 DOM 呢？
不過我基本同意你的論點，但是過分強調不要學習工具就有一點何不食肉糜的意味了。

另外，Docker 也不僅僅是持續交付，「學習新的程式語言」和「學習設計模式和 DDD」也不是互斥的，Angular 最難的部分也不是 Web 和 HTTP，最難的是學習 Angular 提供的這些傻傻的工具和工作流（我不是很喜歡這些玩意）。

作者的回覆：

看來我們達成了共識——學習基礎常常意味著深挖某個框架、庫或者工具。框架和基礎都要學習，但是優先順序必須是基礎高於框架。

我的觀點：

假設你面前有兩個應聘者，一個對框架特別熟，但是對基礎知識一點都不懂；另一個對框架一點都不熟，但是基礎知識特別懂。你會僱傭誰？

小公司僱傭前者，能用就行。大公司僱傭後者，能堪重任。