1.明確你的前端學習路線與方法

首先是前端的基礎知識，常常有一些工作多年的工程師，在看到一些我認為很基礎的 JavaScript 語法的時候，還會驚呼“居然可以這樣”。是的，基礎知識的欠缺會讓你束手束腳，更限制你解決問題的思路。 其次，技術上存在短板，就會導致前端開發者的上升通道不甚順暢。特別是一些小公司的程式設計師，只能靠自己摸索，這樣就很容易陷入重複性勞動的陷阱，最終耽誤自己的職業發展。 除此之外，前端工程師也會面臨技術發展問題帶來的挑戰。前端社群高度活躍，前端標準也在快速更新，這樣蓬勃發展對技術來說無疑是好事，但是副作用也顯而易見，它使得前端工程師的學習壓力變得很大。 我們就拿 JavaScript 標準來說，ES6 中引入的新特性超過了過去十年的總和，新特性帶來的實踐就更多了，僅僅是一個 Proxy 特性的引入，就支援了 VueJS 從 2.0 到 3.0 的核心原理完全升級。 缺少系統教育 + 技術快速革新，在這樣的大環境下，前端工程師保持自學能力就顯得尤其重要了。 那麼，前端究竟應該怎麼學呢？我想，我可以簡單分享一下自己的經驗。 學習路徑與學習方法 首先是0 基礎入門的同學，你可以讀幾本經典的前端教材，比如《JavaScript 高階程式設計》《精通 CSS》等書籍，去閱讀一些參考性質的網站也是不錯的選項，比如MDN。 如果你至少已經有了 1 年以上的工作經驗，希望在技術上有一定突破，那麼，這個專欄就可以是你技術進階的一個選項了。 在這個專欄中，我希望傳達的不僅僅是具體的知識點，還有體系架構和學習方法。我希望達到三個目標： 帶你摸索出適合自己的前端學習方法； 幫助你建立起前端技術的知識架構；讓你理解前端技術背後的核心思想。 在開始具體的知識講解之前，這篇文章中，我想先來談兩個前端學習方法。 第一個方法：建立知識架構 第一個方法是建立自己的知識架構，並且在這個架構上，不斷地進行優化。 我們先來講講什麼叫做知識架構？我們可以把它理解為知識的“目錄”或者索引，它能夠幫助我們把零散的知識組織起來，也能夠幫助我們發現一些知識上的盲區。 當然，知識的架構是有優劣之分的，最重要的就是邏輯性和完備性。 我們來思考一個問題，如果我們要給 JavaScript 知識做一個頂層目錄，該怎麼做呢？ 如果我們把一些特別流行的術語和問題，拼湊起來，可能會變成這樣： 型別轉換； this 指標； 閉包； 作用域鏈； 原型鏈； …… 這其實不是我們想要的結果，因為這些知識點之間，沒有任何邏輯關係。它們既不是並列關係，又不是遞進關係，合在一起，也就沒有任何意義。這樣的知識架構，無法幫助我們去發現問題和理解問題。 如果讓我來做，我會這樣劃分： 文法 語義 執行時 為什麼這樣分呢，因為對於任何計算機語言來說，必定是“用規定的文法，去表達特定語義，最終操作執行時的”一個過程。 這樣，JavaScript 的任何知識都不會出現在這個範圍之外，這是知識架構的完備性。我們再往下細分一個層級，就變成了這個樣子： 文法 詞法 語法 語義 執行時 型別 執行過程 我來解釋一下這個劃分。 文法可以分成詞法和語法，這來自編譯原理的劃分，同樣是完備的。語義則跟語法具有一一對應關係，這裡暫時不區分。 對於執行時部分，這個劃分保持了完備性，我們都知道：程式 = 演算法 + 資料結構，那麼，對執行時來說，型別就是資料結構，執行過程就是演算法。 當我們再往下細分的時候，就會看到熟悉的概念了，詞法中有各種直接量、關鍵字、運算子，語法和語義則是表示式、語句、函式、物件、模組，型別則包含了物件、數字、字串等…… 這樣逐層向下細分，知識框架就初見端倪了。在頂層和大結構上，我們通過邏輯來保持完備性。如果繼續往下，就需要一些技巧了，我們可以尋找一些線索。 比如在 JavaScript 標準中，有完整的文法定義，它是具有完備性的，所以我們可以根據它來完成，我們還可以根據語法去建立語義的知識架構。實際上，因為 JavaScript 有一份統一的標準，所以相對來說不太困難。 如果是瀏覽器中的 API，那就困難了，它們分佈在 w3c 的各種標準當中，非常難找。但是我們要想找到一些具有完備性的線索，也不是沒有辦法。我喜歡的一個辦法，就是用實際的程式碼去找：for in 遍歷 window 的屬性，再去找它的內容。 我想，學習的過程，實際上就是知識架構不斷進化的過程，通過知識架構的自然延伸，我們可以更輕鬆地記憶一些原本難以記住的點，還可以發現被忽視的知識盲點。 建立知識架構，同樣有利於面試，沒人能夠記住所有的知識，當不可避免地談到一個記不住的知識，如果你能快速定位到它在知識架構中的位置，把一些相關的點講出來，我想，這也能撈回不少分。（關於前端具體的知識架構，我會在 02 篇文章中詳細講解。） 第二個方法：追本溯源 第二個方法，我把它稱作追本溯源。 有一些知識，背後有一個很大的體系，例如，我們對比一下 CSS 裡面的兩個屬性： Ning: opacity； display。 雖然都是“屬性”，但是它們背後的知識量完全不同，opacity 是個非常單純的數值，表達的意思也很清楚，而 display 的每一個取值背後都是一個不同的佈局體系。我們要講清楚 display，就必須關注正常流（Normal Flow）、關注彈性佈局系統以及 grid 這些內容。 還有一些知識，涉及的概念本身經歷了各種變遷，變得非常複雜和有爭議性，比如 MVC，從 1979 年至今，概念變化非常大，MVC 的定義幾乎已經成了一段公案，我曾經擷取了 MVC 原始論文、MVP 原始論文、微軟 MSDN、Apple 開發者文件，這些內容裡面，MVC 畫的圖、箭頭和解釋都完全不同。 這種時候，就是我們做一些考古工作的時候了。追本溯源，其實就是關注技術提出的背景，關注原始的論文或者文章，關注作者說的話。 操作起來也非常簡單：翻翻資料（一般 wiki 上就有）找找歷史上的文章和人物，再順藤摸瓜翻出來歷史資料就可以了，如果翻出來的是歷史人物（幸虧網際網路的歷史不算悠久），你也可以試著發封郵件問問。 這個過程，可以幫助我們理解一些看上去不合理的東西，有時候還可以收穫一些趣聞，比如 JavaScript 之父 Brendan Eich 曾經在 Wikipedia 的討論頁上解釋 JavaScript 最初想設計一個帶有 prototype 的 scheme，結果受到管理層命令把它弄成像 Java 的樣子（如果你再挖的深一點，甚至能找到他對某位“尖頭老闆”的吐槽）。 根據這麼一句話，我們再去看看 scheme，看看 Java，再看看一些別的基於原型的語言，我們就可以理解為什麼 JavaScript 是現在這個樣子了：函式是一等公民，卻提供了 new this instanceof 等特性，甚至抄來了 Java 的 getYear 這樣的 Bug。