停止學習框架

方應杭發表於2019-05-20

  我們是程式設計師,每天都在瞭解最新的技術,每天都在學習程式語言、框架和庫。

  因為我們知道的現代程式設計工具越多越好,對吧?

  不停地追隨 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 提供的這些傻傻的工具和工作流(我不是很喜歡這些玩意)。

  作者的回覆:

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

  我的觀點:

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

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

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

 

 

 

 

相關文章