翻譯作者： 方應杭

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

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

　　那么，譯文開始。

　　我們是程序員，每天都在了解最新的技術，每天都在學習編程語言、框架和庫。

　　因為我們知道的現代編程工具越多越好，對吧？

　　不停地追隨 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 個不同的軟件項目。得益于我導師的建議，我學的所有東西都適用于不同的公司、團隊和領域。我的知識今天仍然有用。我沒有浪費我的時間。

　　如果你看得更深入些，你會發現所有的軟件項目都是類似的：

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

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

© In Time (2011) by Andrew Niccol

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

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

　　熱門評論：

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

2007 年的時候我曾經試圖搞清楚到底什么是「數據層」以及怎么使用它，這是當時流行的 ORM 概念。我向別人問了一堆關于 NHibernate 的問題，很多人都回復我說「你應該先搞清楚原理，而不是學習這個工具」。但我心里想的是，shit，不行啊，因為我需要通過大量的實踐才能理解這些原理啊。這是我學習的重要途徑。

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

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

　　作者的回復：

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

　　我的觀點：

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

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