一個前端開發者的自我修養

今天給大家分享的主題是前端的自我成長，這是一個關於成長的話題。

很多人都有這樣的感覺：聽了很多技術圈子的分享，有的有深度，有的循循善誘，深入淺出，但是呢，幾年下來，到底哪些用上了，哪些對自己真的有幫助了?反而有些模糊。

2015 年我在不同的場合分享了很多內容：有移動端的效能、有適配、有 Web vs Native，也有 hybrid，但是其實我一直比較擔心，真正有深度的內容，其實面向的是比較小眾的群體，比如說 Hybrid，其實它在大部分公司裡面，是隻能用現成的。

所以我這一次嘗試分享一個我認為可以幫助到所有前端的話題，關於前端的成長，如果說這個分享的內容，聽眾裡面有那麼幾十個人拿到 BAT 的 offer，或者升職加薪，那麼我覺得我就認為我取得了成功。

前端其實是個特別苦逼的職業，因為前端技術一直革命的特別快，新技術、新技巧在不斷地被發明出來。之前我有一個朋友，他講說他對自己的認知是瞭解前端、熟悉前端、精通前端、熟悉前端、不懂前端。為什麼呢，他說當他覺得自己對前端所有的東西覺得無所不知，無所不能的時候，忽然看到了一段程式碼，他完全無法理解，於是整個世界就崩塌了，從此再也不敢說自己會前端。

我就跟他說，這裡，缺少的是一種正確的方法，你覺得無所不知、無所不能的標準是什麼，是工作中很久沒遇到解決不了的問題麼？他說還真是這樣。我就又問他，那你係統學過前端麼？他想了想，還真沒學過，大學裡不開這個課。的確如此，到目前為止，還沒有任何一個大學會教前端，倒是有些培訓班，會講網頁開發三劍客。

我這裡講的內容，希望帶給大家的，就是該如何學習前端，實現自身成長。

關於成長，首先我得發一個免責宣告，不是我對我講的內容沒有信心，而是成長是自己的事，英文有句話，在外企工作的人會經常聽到，叫做：

You are the owner of your career.

你是你職業發展的責任人。這句話潛臺詞是，你（不是你老闆，也不是你爸媽，也不是你女朋友）是你職業發展的責任人。

這句話我在我職業生涯的起點聽說，一直指導我的職業發展，甚至在我帶團隊，培養團隊的時候，也是中心的指導思想，之前我帶的團隊的同學，他們有不少人也在帶團隊，其實他們也在實踐這句話，所以我這裡，也把這句話、把這個道理分享給給大家。

我們講前端成長，我認為，主要在兩個方面，一部分是“能力”，一部分是“知識”。我個人的觀點，能力佔百分之八十，知識佔百分之二十。

從這個圖上，大家可以看到，其實我們認為變化快的東西，最新出來的 Angular、React、ES2015，其實都在知識裡面，知識又分成兩部分，一部分我把它叫做標準，它是相對而言比較穩定的，很少會出現一個標準被推翻的事情。另一部分則是技術，像是 jQ、React 這些框架啦，像是 MVC、Flux 這些架構的東西，這些東西是由各個公司主導的，變化就非常快，你看 Grunt 發展了沒多久，Gulp 就來挑戰他了，然後又有 browserify、webpack 這些東西。

而我認為佔重點的能力，則是非常穩定的，我認為能力是三大塊：程式設計能力、架構能力、工程能力。

程式設計能力，就是用程式碼解決問題的能力，你程式設計能力越強，就能解決越複雜的問題，細分又有除錯、演算法、資料結構、OS 原理等這些的支撐，你才能解決各種麻煩的問題。

架構能力，則是解決程式碼規模的問題，當一個系統足夠複雜，你會寫每一塊，能解決每一個問題，不等於你能搞定整個系統，這就需要架構能力，架構能力包含了一些意識，比如解耦、介面隔離，也包含認識業務建立抽象模型，也有一些常見的模式，比如經典的 MVC，還有設計層面，物件導向、設計模式等等。

最後工程能力，則是解決協作的問題，當系統規模更大，光靠一個人，是沒辦法完成的，如何保證幾個高手互相能夠配合好？如何保證專案裡面水平最差的人不拖後腿？這個工程化建設，往往會跨越多個業務，以彙報關係上的團隊為單位來做。包括前後端解耦，模組化，質量保證，程式碼風格，等等。

其實不難看出來，這三項，其實是有順序的，低等級、小團隊，程式設計能力一項就能應付，越資深的前端，越大的公司和團隊，越是需要後面的技能，但是這裡我要強調一點，其實資深前端，大團隊，對能力的需求，是既要還要——不是說資深的前端，程式設計能力就可以變差。

社群總會有一些聲音，對工程能力，對架構能力持有一種牴觸的態度，覺得比較虛，覺得不需要。實際上以某些人所在的崗位來說，也沒錯，畢竟公司、團隊的狀態確實可能用不到，但是以個人成長的角度來看，就是大錯特錯。

下面我們來具體講講，關於知識的學習。

對知識，我一直有個觀點，叫做寧缺毋濫，這個圖片上寫了一句好前端才分對錯，是的，其實很多人，他學習東西的時候就喜歡挑，挑簡單的學，書選擇最”深入淺出”的，在這種心態下，沒有任何一絲學好的可能性，

所以我對知識學習的目標，理解為亮點，一曰準確，二曰全面。當年學習一部分知識，如果你能做到這兩點，那你將來在業務上做技術決策的時候，你面對面試官技術問題的時候，信心跟你只看過皮毛是完全不一樣的。

怎麼做到這兩點呢？我想路子肯定有很多，而我的答案，我這裡要分享的，是“建立自己的知識體系”。

如何建立自己的知識體系呢？我個人總結的經驗，是下面幾個步驟：

第一步，尋找線索。

你要了解一個知識，比如我想學 Web 平臺的 API 了，當然可以先找一本書，看看別人都寫了什麼，但是我不喜歡這麼幹。

我大學裡，學前端的東西，為了找個 id 和 name 的區別，曾經要借十幾本書來，對比著看，那個時候，是真的沒人告訴我，什麼書比較好。所以我對別人總結好的知識，第一反應是質疑，不信。

所以我比較推薦，找一些比較準確的，你可以確定它真的足夠全面的資料當作線索。對 Web 平臺的 API，我就用反射：

瀏覽器裡給出來的這個屬性列表是不會騙人的，用這個東西作為線索，我就很有信心。

同樣可能比較適合做的資料，還有一些標準文件的附錄，和原始碼裡的結構定義。

第二步，是建立聯絡。

比如說，看下面幾個 DOM 屬性：

這裡，左邊一列是操作 Node 的，右邊一列是操作 Element 的，它就存在一定的對應關係。

一般來說，我們找對應關係的方式有以下幾個依據：

• 美感
• 完備性
• 操作同一組資料

特別提一下，操作同一組資料，正是物件導向的核心概念，對前端而言，有點不一樣的是，所有的 API，根都是 window，所以，其實大部分的 API，可以依據物件導向的資料和操作的觀點進行劃分。

第三步，是分類。

這裡我給出一個實際一些的例子，下圖是我對 zepto(移動簡化版jQuery)，的 API 分類

建立聯絡以後，我們依據知識之間的聯絡，進行分類，就可以得到一張圖譜，在這個圖裡面，你就可以非常清楚地知道，哪些知識，是非常重要的，哪些，其實是可以互相替代的。

而一旦有你之前沒見過的東西，你又能通過把它放到圖譜裡，來快速理解它，或者找出一些很好的替代方案。

比如說面試的時候，如果面試官問你 bind 和 unbind 怎麼用，你還不會，這時候，如果你心裡有這張圖，你就不至於一臉懵了，你可以說，雖然我不知道 bind 和 unbind，但是我知道 live 和 die 啊，我又知道 on 和 off 啊。

這張圖裡我們就可以看出，collection 裡面的東西，多半沒什麼用，而節點操作裡，肯定就都很有用。

第四步，是追本溯源。

當我對一個知識體系的全貌有了概念以後，佔了全面兩個字，接下來需要確認它的準確性。很多知識，在社群，會有很多的爭議，該相信誰呢，這是個問題。而我的答案，就是追本溯源，去找它最初的討論和定義。

有一個真實的案例，就是閉包這個概念，曾經我們很多人的理解都是錯的，把閉包和 scope 的概念給混淆起來，認為閉包是函式的執行環境上下文，但是有一個叫做 hax 的（很多人應該都認識他，哈哈），他就對此提出了質疑，認為閉包就是函式。於是我就去查證閉包的概念。

大家都知道，wiki 其實是不準確的，但是其中有一段，基本不會太有問題，就是歷史。下圖是 closure 這個詞條的歷史部分：

從這段歷史裡，我找到了一個名字， Peter J Landin，他是提出者，那麼，我就去看看他到底是怎麼說的，於是我去 google 學術搜尋，找他的文章

果然找到了，於是我們看看原始的檔案

這個定義，對應到我們今天 JS 裡的閉包，是稍微有點區別的，但是它毫無疑問，是包含了兩個部分環境部分和控制（程式碼）部分，所以其實，閉包就是對應著 JS 的函式，而之前，普遍的觀點是認為閉包只包含環境。

所以這個追溯的過程，能夠幫我們真正搞清楚對錯。

除了 wiki-google 學術搜尋的組合，還有一些郵件列表和 github 提交歷史，也是非常適合去查證一些概念和技術的歷史的。

最後說，我講的這個建立知識體系的過程，是不斷接受新知識，挑戰、質疑原有的體系，推翻再重建，每一次迴圈，你的知識體系都變得更加堅固，更加強大。

下面分享的一部分，是關於能力培養。

能力培養其實重要性很高，但是其實說起來，內容卻很少。只有兩點: 教材、訓練。

對知識學習，我是主張建立自己的體系，不要去相信書，但是對能力培養，我的觀點就剛好相反，我覺得能力的體系，恰恰是難以自己建立的，需要教材去指導。這是由兩者的複雜程度和變化速度決定的。

想培養能力，就要找經典的教材來學習，像演算法導論，The C++ Programming Language這些經典，幾十年都沒有過時。

注意這裡我用了教材，而不是書。

教材和書最大的區別，就是有沒有習題。

在我看來，內容再難的書可以一星期讀兩本，但是教材一定不行，教材一定得花幾個月的時間，一邊讀一邊做習題。

於是談到訓練。

其實有個事實是，工作以後，只有極少數人仍然能夠做到訓練，比如我自己的程式設計能力，我自覺工作 7、8 年，幾乎沒有過進步。

訓練應該是系統的（需要教材）、主動的，這兩個特點不可或缺，有人會覺得，我真的工作很辛苦，每天都要加班，但是其實，任何被動的痛苦，都沒法給人帶來進步，你的痛苦倒是可能給老闆帶來更多收入。

如果面臨困境，可以選擇系統訓練來提升自己，但是對大部分人來說，可能更樂於選擇一個一個變通的辦法: 養成習慣，讓工作變得更有挑戰。

這個事情其實有不少理論，比較有名的是 Noel Tichy 提出的心理舒適區、學習區和恐慌區。選擇一份對自己來說具有挑戰性的工作，正面解決問題。

技術圈裡流行一個笑話，說的是一個人，工作了三年，卻只有一年的經驗，因為後面兩年都在重複第一年的工作。

所以我們要做的事，就是永遠不重複勞動，當你覺得現在的工作，越來越舒適，越來越缺少風險的時候，就應該引起警惕了。

而雖然訓練是個很困難的事情，其實大家也不必過於擔憂，雖然到處都是“一萬小時訓練”的言論，現在各大公司的招聘門檻，在我看來應該都卡在幾百小時訓練的程度。所以我想說，一萬小時太久，只爭朝夕。希望看到大家成為更好的前端，做更好的自己。

以上是我分享的所有內容。