中止學習框架

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

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

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

做者的回覆：

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

 

個人觀點：

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

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

------------------------------------------------------------------------------------------------------------------

知乎網友熱評:

 

當初剛從Android轉前端的時候，一點基礎也不會，什麼html什麼css，徹底不懂，上手就是angular1.0，學的很痛苦，很難受，後續半年前後接觸了vue和react，emmm沒錯，我就是框架仔。後來跳槽，個人上司告訴我，不要用框架，所有使用原生，這才讓我真正感受踏入了前端的領域。給個人實際經驗就是，你從框架中學習基礎，效率很是之低，當你脫離了雙向綁定，脫離了全家桶，你會發現，離開框架你什麼也不會。

因此就像題主說的同樣，框架只是工具，咱們只須要拿來用，可是真正須要學習的，是底層的原理，以及脫離框架後相似功能的實現方法。

肉呼呼的山田桑

 

我以爲可能從框架（或相似東西）的代碼中學習基礎也頗有效（我很難靜下心來讀理論書，由於我在不使用這些基礎知識的時候根本不知道他們有什麼用，很枯燥）。而經過讀前人的代碼先了解了大多數基礎知識（這每每很不全面），這時再看基礎的書，就能找到共鳴了。

匿名

 

"把你 80% 的學習時間用在學習基礎上，剩下 20% 的時間纔是用來學習框架、庫和工具的。" 這句是重點。換句話說能夠理解爲20%的時間來寫業務代碼，80%的時間來思考其深層的原理。

 

空無戒

 

我司連續走了三名前端 都是隻會用vue的 react上手上不上去 最後走的倆個前端 總會問我一些拋開框架的基礎問題 而實際他們使用框架很是糟糕 我想說 我也就看了半個月react 相關的一些文檔去面試 倆天看了公司使用的腳手架及其相關工具 一共八個文檔 。用的時候，根本不須要太熟練，不會就看文檔，基礎好，學得就是快，有些人確實會用，可是真的會用嗎？基礎差的，一旦某些腳手架出現一些涉及看封裝源碼的，就懵逼了。最後jrg牛逼。

 

鄭大大

 

學習框架，並非達到能用就好了，我以爲吧，框架的存在就是對主流技術的一個封裝，仍是有不少思想值得去學習。
就拿前端三大主流框架來講，每一個框架都表明着一種開發思想，都有本身的一套技術方案，他們基本上囊括你所能想到和用到的技術，難道就很差奇他們怎麼實現的嗎。
要學就深刻去學。

 

男猴