一個前端的自我修養

時間 2019-11-15

標籤一個前端自我修養简体版

原文原文鏈接

①一個前端的自我修養

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

　　不少人都有這樣的感受：聽了不少技術圈子的分享，有的有深度，有的循循善誘，深刻淺出，可是呢，幾年下來，到底哪些用上了，哪些對本身真的有幫助了?反而有些模糊。css

　　2015 年我在不一樣的場合分享了不少內容：有移動端的性能、有適配、有 Web vs Native，也有 hybrid，可是其實我一直比較擔憂，真正有深度的內容，其實面向的是比較小衆的羣體，好比說 Hybrid，其實它在大部分公司裏面，是隻能用現成的。html

　　因此我這一次嘗試分享一個我認爲能夠幫助到全部前端的話題，關於前端的成長，若是說這個分享的內容，聽衆裏面有那麼幾十我的拿到 BAT 的 offer，或者升職加薪，那麼我以爲我就認爲我取得了成功。前端

　　前端實際上是個特別苦逼的職業，由於前端技術一直革命的特別快，新技術、新技巧在不斷地被髮明出來。以前我有一個朋友，他講說他對本身的認知是瞭解前端、熟悉前端、精通前端、熟悉前端、不懂前端。爲何呢，他說當他以爲本身對前端全部的東西以爲無所不知，無所不能的時候，突然看到了一段代碼，他徹底沒法理解，因而整個世界就崩塌了，今後不再敢說本身會前端。java

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

　　我這裏講的內容，但願帶給你們的，就是該如何學習前端，實現自身成長。git

關於成長，首先我得發一個免責聲明，不是我對我講的內容沒有信心，而是成長是本身的事，英文有句話，在外企工做的人會常常聽到，叫作：程序員

You are the owner of your career.github

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

　　這句話我在我職業生涯的起點據說，一直指導個人職業發展，甚至在我帶團隊，培養團隊的時候，也是中心的指導思想，以前我帶的團隊的同窗，他們有很多人也在帶團隊，其實他們也在實踐這句話，因此我這裏，也把這句話、把這個道理分享給給你們。

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

　　從這個圖上，你們能夠看到，其實咱們認爲變化快的東西，最新出來的 Angular、React、ES2015，其實都在知識裏面，知識又分紅兩部分，一部分我把它叫作標準，它是相對而言比較穩定的，不多會出現一個標準被推翻的事情。另外一部分則是技術，像是 jQuery、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這些經典，幾十年都沒有過期。

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

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

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

　　因而談到訓練。

　　其實有個事實是，工做之後，只有極少數人仍然可以作到訓練，好比我本身的編程能力，我自覺工做七、8 年，幾乎沒有過進步。

　　訓練應該是系統的（須要教材）、主動的，這兩個特色不可或缺，有人會以爲，我真的工做很辛苦，天天都要加班，可是其實，任何被動的痛苦，都無法給人帶來進步，你的痛苦卻是可能給老闆帶來更多收入。

　　若是面臨困境，能夠選擇系統訓練來提高本身，可是對大部分人來講，可能更樂於選擇一個一個變通的辦法：養成習慣，讓工做變得更有挑戰。

　　這個事情其實有很多理論，比較有名的是 Noel Tichy 提出的心理溫馨區、學習區和恐慌區。選擇一份對本身來講具備挑戰性的工做，正面解決問題。

　　技術圈裏流行一個笑話，說的是一我的，工做了三年，卻只有一年的經驗，由於後面兩年都在重複第一年的工做。

　　因此咱們要作的事，就是永遠不重複勞動，當你以爲如今的工做，愈來愈溫馨，愈來愈缺乏風險的時候，就應該引發警戒了。

　　而雖然訓練是個很困難的事情，其實你們也沒必要過於擔心，雖然處處都是「一萬小時訓練」的言論，如今各大公司的招聘門檻，在我看來應該都卡在幾百小時訓練的程度。因此我想說，一萬小時過久，只爭朝夕。但願看到你們成爲更好的前端，作更好的本身。

　　以上是我分享的全部內容。

回到頂部(go to top)

②寫給初學前端工程師的一封信

　　你們好：

　　應波波的邀請寫一寫我對這個話題的想法。從去年開始很多朋友讓我幫忙介紹前端工程師，絕大部分忙都沒幫上，緣由是真找不到人。我當時是這麼跟他們分析的：過去的客戶端以browser爲主，因此html/css/javascript是惟一選擇，如今但是mobile first，因而大量前端開發者被native開發分流，以及本來想作前端工程師的後備力量應屆生們也選擇學native開發，致使前端人荒。隨着狀況改變，H5（HTML5的大衆暱稱）在傳播上體現的商業價值巨大，不管是創業團隊仍是巨頭天然重視這塊低成本高收益的事。好像前端開發的春天又來了，但局面是後備人才不足，想轉前端開發的又會發現貴圈比之前還亂，除了標準依然滯後，各類框架、工具冒出來，沒一兩年又淘汰，過去好像會jQuery就能夠混，如今的門檻確實高很多。沒辦法創業團隊要招到優秀的前端工程師只能靠情懷和燒錢，巨頭們須要從新培育起好的技術文化吸引人才，尤爲是肯花錢和時間在前端技術的培訓、積累和創新上。以前有人說web已死，如今看說這話的人能夠去死了。在前端技術儲備上加大投入，很長一段時間內都是很是值得的。

　　回到主題，標題實際上是病句「初學前端工程師」。前端工程師是種崗位的title，怎麼用學呢。我想將錯就錯說說職業的問題。前端社區三類人：前端工程師、前端開發者、「玩票」者。首先要明確前端工程師是種職業，是專職爲公司業務提供前端開發服務的一個工種。前端開發者意義更廣，凡是用前端技術開發的都算，但這裏我想狹義上指前端開源社區貢獻者和自由前端開發者。「玩票」者，指本來是其它語言的開發者，因喜好前端技術常常參與社區互動並貢獻開源項目的人。前端工程師和後二者的主要區別就是——職業性，後二者主要關注和解決通用問題（提升前端開發的生產力啊、推動標準的實現和發展啊），而前端工程師的職能是解決所在公司的產品開發中的前端工程問題（工程和技術是不一樣概念，以前我分享過一個關於什麼是前端工程的話題，在這裏）。明肯定義後，開始談談我作了這麼多年前端工程師的一點感覺。

　　「他是我見過的最好的前端工程師」，這是多年前一位前同事對個人評價，我本身會剋制的在後面加上「之一」。若是他說的是「最好的前端開發者」，我絕對不會接受這種評價。個人github如此冷清，編程上也沒有突出的才能，也沒貢獻過任何有影響力的開源項目。但我以爲本身是很好的前端工程師，我參與的產品開發效率很高，對技術發展很敏感，不多走偏，多少還有點前瞻性。身在一線，對技術上的或人上的問題看的比較準。共同之處：追求更好更有效的解決工做上的實際問題。我不會盲目追求「最流行」的技術，更不會把它強加給產品，除非我以爲它真的適合這個項目，切實解決問題爲導向。剛到豆瓣時，我問本身：豆瓣產品前端的最大問題是什麼？不是統一UI、不是搞個新框架，而是要經過建全基礎設施，改變開發方式將原來集中式的業務代碼完全解藕纔是癥結。這裏面有技術問題還有跨角色合做的問題，所以不能孤立前端團隊，搞合做不搞對立。當時組建的通用工具組集合了各類背景的資深工程師，一塊兒討論方案，成果對後面支撐公司業務的快速發展起到了重要做用。作這些事情要忍耐默默無聞、要常常跳出本身的溫馨區，到另外一個不熟的領域甘心當小白，目的只有一個——切實有效的把產品中的問題解決掉。對我的而言，一般這麼作能夠收穫到更多更深入的經驗和知識，因此我也樂此不疲。不理解的人或許會以爲這人不牛逼啊，別人的見解不重要，收穫到實實在在的有價值的東西纔是硬道理。新人不應看重虛名，裝逼不健康。沉浸到每個項目中（別。挑。活），作到具體問題具體分析，不生搬硬套，獨立思考，虛心交流必定會快速成長起來。不要拿追求「完美」當幌子，不肯作沒技術含量的事，這樣的話乾脆別幹前端了。

　　擁抱變化是我在前公司工做時被灌輸的價值觀。對於剛走上前端工程師崗位的同窗們來講，要慢慢習慣前端技術的快速變化，而且擁抱它。要stay hungry, stay foolish。其中也有重點，在不易變的方向上多花時間學習越深刻越好，不糾纏、執着於那些易變的東西。對新技術始終保持好奇心。

工具是最易變的，工具包括從各類庫、框架到構建工具、編輯器等等。我對工具的態度是實用至上、喜新厭舊。對於新人來講儘量多的體驗各類工具沒壞處，從工具的設計思想上也能學到很多知識，可是要清醒的認識到，會用不少工具不是工程師核心的開發能力，也不是我的的核心競爭力。
前端技術自己的變化是演變，不像工具那樣徹底棄用變成全新的。好比多花些時間學習CSS2.1一點都不會浪費，多研究一些Javascript的基礎特性也不會輕易過期。而後有預見性的學習新技術，在項目中積極擁抱新標準，好比ES6。幸運的是如今有大量工具讓咱們能夠提早在產品開發中應用新標準。
開發思想不存在過期的問題，這些須要在長期的開發實踐中不斷的總結、反思，好比分離關注點是70年代提出的，從它衍生出不少開發理念，它永遠不會過期。這些好像很「虛」的東西，在駕馭複雜的項目中很是有用。

　　我以爲前端工程師是全部工程師角色中最有也最須要「工匠精神」的。前端工程師的基本職責就是還原設計，把一個躺在設計圖上的死的設計變成能夠用的活的設計。所謂「工匠精神」體如今這個「活」字上。可視方面，一個動畫的過程是否順暢，一個交互動做所有狀態是否都作到位，適配上是否足夠靈活。代碼方面，一段通用代碼是否足夠通用，代碼冗餘是否最小，性能是否足夠快等等。簡單的實現是最低要求，剩下的部分產品經理、項目經理不會要求，那是優秀的前端工程師發揮的空間。前端工程師的成長就是一個修煉的過程，修煉的開始就是在學會了那些書本上能夠學到的編程知識後。在前端工程師的素質中，我認爲應用能力是最重要的。這種應用能力可當作是一種產品的塑造能力，前提要有產品思惟和設計思惟，能自主發現並彌補產品、設計的空白和不合理環節，能夠很好的控制代碼的複雜度，高效高質量的完成開發需求。提高這種能力，紙上談兵不行，只能在各類項目中摸爬滾打，如同醫生不斷積累臨牀經驗同樣。若是公司項目不能知足，就本身找項目作。我在剛畢業的時候，接過很多私活，一般這類項目發揮空間大。

　　每一個開發團隊都有本身的一套遊戲規則：代碼規範、code review、git或svn的用法、開發流程等等，先按照規則玩，再想着如何添磚加瓦。團隊意識是一種職業態度。在一個好的團隊裏工做會很開心，團隊會促進個體更快的成長。但一個好團隊也是靠全部個體共建。不要抱怨本身所在的團隊不夠好，用更開放的心態分享和交流，慢慢的一個好的氛圍便會造成。

　　最後再說說前端工程師的態度問題。前端技術發展很快，所以要不斷學習，不該該輕易自滿。以前在知乎裏回答過一個問題，我是這麼寫的：「程序員容易陶醉在本身的代碼中，甚至有某種自戀。我也有過這種時候，我甚至認爲不夠自戀就不是好程序員，藝術家沒有不自戀的。但若是跳出本身的世界看，你寫出來的東西到底價值有多大，產品所以成功？到底能影響什麼，一二個同事，一個團隊，整個行業？跟心目中大神的差距？這個時候會冷靜一些，原來只是比之前的本身進步一些而已。」

　　前面並無說成爲一名優秀的前端工程師具體應該學習什麼技術，會不會有些失望？由於具體的技術會變，不變的是那些特質和觀念。但願個人分享對新入行的前端工程師有所啓發和幫助。

　　－Kejun

回到頂部(go to top)

③談談我這三年在技術上的成長

紮實的基礎

記得第一次面試以前，我很努力地把所知道的前端相關的技術點列了列，寫了好幾頁紙的關鍵詞，而後針對每一個關鍵詞系統地鞏固學習，解決心中的疑問以及學習時遇到的新疑問，而後自信滿滿地參加了新浪和網易的面試。那時候，估計兩家公司的前端工程化已經有些苗頭了，但可能認爲學校裏的同窗沒啥實戰經驗，主要問的都是前端基礎題，閉包、正則、DOM 模型、Event 模型等等，沒什麼特別深刻的話題。固然，那時候個人簡歷中也沒有太多體現工程化相關的內容，估計跟面試官也聊不起來。

對於入門不久的前端同窗，面試官着重考慮的是他們的學習能力、發展潛力，也會適當看看編程能力過不過關，對 JavaScript/CSS/HTML 的基礎知識掌握的牢不牢固。若是你被面試官選中了，那就說明，你具備較強的綜合素養，是一個合格的前端入門者。通常重點高校學生的學習能力都還不錯，大學幾門計算機相關學科的薰陶加上適當的課外練習後，編程能力也是可以接受的，因此公司喜歡招聘重點高校尤爲是偏理工科的學生。我看到很多同窗，在畢業前三五個月纔開始瞭解和學習前端，單最後都順利地進入 BAT。

我就屬於上面這波人，只不過，不是畢業前抱佛腳，而是較早地接觸了前端，看了不少書籍，融入了前端社區，而且在學校的技術團隊中鍛鍊了基本功。我很慶幸本身會在大學時，投入那麼多時間在前端基礎知識的學習上，由於畢業後我發現，本身已經沒有那麼多時間和耐心來學習這些略感枯燥的知識了。已經工做的你還可以堅持一口氣啃完犀牛書麼？估計絕大多數人都沒這個耐心吧，即使有些知識你已經淡忘了，只願意把犀牛書做爲工具書。我在畢業前就把這本書啃了四五遍，如今基本不須要這本工具書了。

大學期間讀過的書不少，豆瓣上記錄過大學讀的書，從每本書都吸取點知識，因此總的知識儲備實際上是足夠應付面試和通常需求的。不謙虛地說，我對前端硬知識的瞭解比較全面，這對我後續的提高奠基了堅實的基礎。

紮實的基礎

知識體系和能力階梯

可是，畢業工做後，才發現，我學的那點東西遠遠不夠。事實上，畢業以前的實習就深有體會了。

爲何公司指望學生可以去實習？公司有本身的一套流程和技術體系，這一套東西是適配公司業務，方便各個工種之間協同做戰的，並且每一個公司的那一套都不太同樣。剛畢業的同窗最熟練的是對 API 的使用，而進入一個新環境後，會發現以前熟悉的那一套並很差使，有不少軟件環境須要搭建，不少框架類庫須要熟悉，還有一堆開發流程、上線流程、業務流程等等，這些東西會讓一個自信的新人變得沒有任何優越感。再加上分配的業務上還有幾個小 bug 要修理，你幾乎不會有本身的時間，學習變得變成了一種奢侈的事情。這也是給還在學校的同窗一個警示，若是你要走技術這條路，基本功必定要打紮實，不然工做第一年你會至關吃力。

百度實習那幾個月對個人改變很大，象牙塔外拼搏三個月，我的閱歷見長且不說，技術上的認識有了很大幅度的提高。固然，這要感謝公司。在公司裏很容易知道哪些技術是公司須要的，哪些技能是業務中必須熟練掌握的。慢慢的，對技術就有了必定的甄別能力，曾經擺在心中的技術關鍵詞是單線程、兼容性、冒泡捕獲、事件代理等等，而如今變成了組件化、調試模式、自動化測試、前端集成環境等等，徹底是兩個知識維度上的分類。

公司有不一樣層級的人，他們作的事情也有些差別，從這些差別中也可以體會出，本身跟這羣人相比亮點和缺點分別是什麼，若是須要提高還須要作些什麼。越大的公司，對人能力的分級越明顯，對我的來說，也越容易找準本身的位置。知道本身水平在什麼位置，也知道下一個水平在什麼位置以後，咱們須要的就只有努力了。

業務和新技術

我歷來不擔憂社區又出來幾個什麼新的技術名詞，由於我已經給這些詞安排了座位，就在腦海中。好比 grunt、gulp、webpack 等名詞出來的時候，我沒有忙着去深刻學習，腦子裏有一張大概的體系圖，先把它們打包扔到腦子裏命名爲「工程化-打包類」，先存起來，等到須要的時候再去學習。實際上，我也是隔了三四個月纔去學習和使用他們的。

可是存進大腦以前，我會先簡單瞭解這些工具：它能作什麼？哪些場景能夠用？大概如何用？社區在哪裏？組件庫如何搜索？三者之間的差別是什麼？而後看看基本的 API，這些工做花不了多少時間，可是對我後續深刻了解它們提供了很大的幫助。我一直很承認這句話：「知道從哪裏能夠學到知識，就就學會了這個知識的一半」。

因此我不擔憂有新技術出來，我不忙着學它，由於即使是我學會了，個人團隊中也不會去用它，甚至業務中根本就用不上。對新知識作分類而且瞭解全貌，至於細節部分嘛，先放放。不要動不動就搞什麼源碼分析，React 的 diff 算法，Vue 的 MVVM，這種事情費事費力，其實稍微想象下就知道是個啥了麼，中間的細節實現和實現原理不是不重要，而是暫時不重要。能夠等到你閒下來或者預知業務中有須要時，再下工夫深刻也不遲。

大多數狀況下，技術都是跟着需求的變化而變化的，需求從哪裏來？固然是從你的團隊和業務之中出來的。跟着業務走，你的方向不會錯！

小結

能夠說沒有人系統地學過前端，大學沒這門課，公司也沒這門課。前端這個詞是 ajax 流行時出現，它朝氣蓬勃，發展卻異常迅猛。要在技術這條路上走的長久，首先要把基礎打紮實，而後才能能力和閒工夫按部就班。