中止學習框架

這是一篇譯文，原文在 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 個不一樣的軟件項目。得益於我導師的建議，我學的全部東西都適用於不一樣的公司、團隊和領域。個人知識今天仍然有用。我沒有浪費個人時間。

若是你看得更深刻些，你會發現全部的軟件項目都是相似的：

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

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

© 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（譯註：一個面向.NET框架的對象關係映射解決方案。主要用來把對象模型表示的對象映射到基於SQL的關係模型數據結構中去）的問題，不少人都回復我說「你應該先搞清楚原理，而不是學習這個工具」。但我內心想的是，shit，不行啊，由於我須要經過大量的實踐才能理解這些原理啊。這是我學習的重要途徑。

因此我以爲學習這些蘊含了豐富原理的工具實際上是很是有用的。
一樣的道理對不少工具都適用。好比 React，若是沒有 React 誰能理解虛擬 DOM 呢？
不過我基本贊成你的論點，可是過度強調不要學習工具就有一點何不食肉糜的意味了。

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

做者的回覆：

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

個人觀點：

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

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