摘要:今天給大家分享的主題是前端的自我成長,這是一個關于成長的話題。的確如此,到目前為止,還沒有任何一個大學會教前端,倒是有些培訓班,會講網頁開發三劍客。
今天給大家分享的主題是前端的自我成長,這是一個關于成長的話題。
很多人都有這樣的感覺:聽了很多技術圈子的分享,有的有深度,有的循循善誘,深入淺出,但是呢,幾年下來,到底哪些用上了,哪些對自己真的有幫助了?反而有些模糊。
2015 年我在不同的場合分享了很多內容:有移動端的性能、有適配、有 Web vs Native,也有 hybrid,但是其實我一直比較擔心,真正有深度的內容,其實面向的是比較小眾的群體,比如說 Hybrid,其實它在大部分公司里面,是只能用現成的。
所以我這一次嘗試分享一個我認為可以幫助到所有前端的話題,關于前端的成長,如果說這個分享的內容,聽眾里面有那么幾十個人拿到 BAT 的 offer,或者升職加薪,那么我覺得我就認為我取得了成功。
前端其實是個特別苦逼的職業,因為前端技術一直革命的特別快,新技術、新技巧在不斷地被發明出來。之前我有一個朋友,他講說他對自己的認知是了解前端、熟悉前端、精通前端、熟悉前端、不懂前端。為什么呢,他說當他覺得自己對前端所有的東西覺得無所不知,無所不能的時候,忽然看到了一段代碼,他完全無法理解,于是整個世界就崩塌了,從此再也不敢說自己會前端。
我就跟他說,這里,缺少的是一種正確的方法,你覺得無所不知、無所不能的標準是什么,是工作中很久沒遇到解決不了的問題么?他說還真是這樣。我就又問他,那你系統學過前端么?他想了想,還真沒學過,大學里不開這個課。的確如此,到目前為止,還沒有任何一個大學會教前端,倒是有些培訓班,會講網頁開發三劍客。
我這里講的內容,希望帶給大家的,就是該如何學習前端,實現自身成長。
關于成長,首先我得發一個免責聲明,不是我對我講的內容沒有信心,而是成長是自己的事,英文有句話,在外企工作的人會經常聽到,叫做:
You are the owner of your career.
你是你職業發展的責任人。這句話潛臺詞是,你(不是你老板,也不是你爸媽,也不是你女朋友)是你職業發展的責任人。
這句話我在我職業生涯的起點聽說,一直指導我的職業發展,甚至在我帶團隊,培養團隊的時候,也是中心的指導思想,之前我帶的團隊的同學,他們有不少人也在帶團隊,其實他們也在實踐這句話,所以我這里,也把這句話、把這個道理分享給大家。
我們講前端成長,我認為,主要在兩個方面,一部分是“能力”,一部分是“知識”。我個人的觀點,能力占百分之八十,知識占百分之二十。
從這個圖上,大家可以看到,其實我們認為變化快的東西,最新出來的 Angular、React、ES2015,其實都在知識里面,知識又分成兩部分,一部分我把它叫做標準,它是相對而言比較穩定的,很少會出現一個標準被推翻的事情。另一部分則是技術,像是 jQuery、React 這些框架啦,像是 MVC、FLUX 這些架構的東西,這些東西是由各個公司主導的,變化就非常快,你看 Grunt 發展了沒多久,Gulp 就來挑戰他了,然后又有 browserify、webpack 這些東西。
而我認為占重點的能力,則是非常穩定的,我認為能力是三大塊:編程能力、架構能力、工程能力。
編程能力,就是用代碼解決問題的能力,你編程能力越強,就能解決越復雜的問題,細分又有調試、算法、數據結構、OS 原理等這些的支撐,你才能解決各種麻煩的問題。
架構能力,則是解決代碼規模的問題,當一個系統足夠復雜,你會寫每一塊,能解決每一個問題,不等于你能搞定整個系統,這就需要架構能力,架構能力包含了一些意識,比如解耦、接口隔離,也包含認識業務建立抽象模型,也有一些常見的模式,比如經典的 MVC,還有設計層面,面向對象、設計模式等等。
最后工程能力,則是解決協作的問題,當系統規模更大,光靠一個人,是沒辦法完成的,如何保證幾個高手互相能夠配合好?如何保證項目里面水平最差的人不拖后腿?這個工程化建設,往往會跨越多個業務,以匯報關系上的團隊為單位來做。包括前后端解耦,模塊化,質量保證,代碼風格,等等。
其實不難看出來,這三項,其實是有順序的,低等級、小團隊,編程能力一項就能應付,越資深的前端,越大的公司和團隊,越是需要后面的技能,但是這里我要強調一點,其實資深前端,大團隊,對能力的需求,是既要還要——不是說資深的前端,編程能力就可以變差。
社區總會有一些聲音,對工程能力,對架構能力持有一種抵觸的態度,覺得比較虛,覺得不需要。實際上以某些人所在的崗位來說,也沒錯,畢竟公司、團隊的狀態確實可能用不到,但是以個人成長的角度來看,就是大錯特錯。
下面我們來具體講講,關于知識的學習。
對知識,我一直有個觀點,叫做寧缺毋濫,這個圖片上寫了一句好前端才分對錯,是的,其實很多人,他學習東西的時候就喜歡挑,挑簡單的學,書選擇最”深入淺出”的,在這種心態下,沒有任何一絲學好的可能性,
所以我對知識學習的目標,理解為亮點,一曰準確,二曰全面。當年學習一部分知識,如果你能做到這兩點,那你將來在業務上做技術決策的時候,你面對面試官技術問題的時候,信心跟你只看過皮毛是完全不一樣的。
怎么做到這兩點呢?我想路子肯定有很多,而我的答案,我這里要分享的,是“建立自己的知識體系”。
如何建立自己的知識體系呢?我個人總結的經驗,是下面幾個步驟:
第一步,尋找線索。
你要了解一個知識,比如我想學 Web 平臺的 API 了,當然可以先找一本書,看看別人都寫了什么,但是我不喜歡這么干。
我大學里,學前端的東西,為了找個 id 和 name 的區別,曾經要借十幾本書來,對比著看,那個時候,是真的沒人告訴我,什么書比較好。所以我對別人總結好的知識,第一反應是質疑,不信。
所以我比較推薦,找一些比較準確的,你可以確定它真的足夠全面的資料當作線索。對 Web 平臺的 API,我就用反射:
瀏覽器里給出來的這個屬性列表是不會騙人的,用這個東西作為線索,我就很有信心。
同樣可能比較適合做的資料,還有一些標準文檔的附錄,和源代碼里的結構定義。
第二步,是建立聯系。
比如說,看下面幾個 DOM 屬性:
img
這里,左邊一列是操作 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 提出的心理舒適區、學習區和恐慌區。選擇一份對自己來說具有挑戰性的工作,正面解決問題。
技術圈里流行一個笑話,說的是一個人,工作了三年,卻只有一年的經驗,因為后面兩年都在重復第一年的工作。
所以我們要做的事,就是永遠不重復勞動,當你覺得現在的工作,越來越舒適,越來越缺少風險的時候,就應該引起警惕了。
而雖然訓練是個很困難的事情,其實大家也不必過于擔憂,雖然到處都是“一萬小時訓練”的言論,現在各大公司的招聘門檻,在我看來應該都卡在幾百小時訓練的程度。所以我想說,一萬小時太久,只爭朝夕。希望看到大家成為更好的前端,做更好的自己。
以上是我分享的所有內容。
學習前端的過程中遇到什么問題或者想獲取學習資源的話,歡迎加入前端學習交流QQ群:328058344
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/112125.html
摘要:用前后端分離的開發模式,前端和后端約定好接口格式之后,前端可以用模擬返回數據,從而可以完全脫離后端進行開發安裝使用這里作用等價于拓展周杰倫林俊杰鄧紫棋方大同自定義的拓展函數同理,用占位符和調用具體的函數等價可模擬整形數組的長度和值可模擬某一 MockJs 用前后端分離的開發模式,前端和后端約定好接口格式之后,前端可以用MockJs模擬返回數據,從而可以完全脫離后端進行開發 安裝 npm...
摘要:用前后端分離的開發模式,前端和后端約定好接口格式之后,前端可以用模擬返回數據,從而可以完全脫離后端進行開發安裝使用這里作用等價于拓展周杰倫林俊杰鄧紫棋方大同自定義的拓展函數同理,用占位符和調用具體的函數等價可模擬整形數組的長度和值可模擬某一 MockJs 用前后端分離的開發模式,前端和后端約定好接口格式之后,前端可以用MockJs模擬返回數據,從而可以完全脫離后端進行開發 安裝 npm...
摘要:用前后端分離的開發模式,前端和后端約定好接口格式之后,前端可以用模擬返回數據,從而可以完全脫離后端進行開發安裝使用這里作用等價于拓展周杰倫林俊杰鄧紫棋方大同自定義的拓展函數同理,用占位符和調用具體的函數等價可模擬整形數組的長度和值可模擬某一 MockJs 用前后端分離的開發模式,前端和后端約定好接口格式之后,前端可以用MockJs模擬返回數據,從而可以完全脫離后端進行開發 安裝 npm...
摘要:前言為什么鄙視我們程序員隨著技術的日漸發展,各種可視化操作工具大行其道為廣大程序員們提供了不少的便利特別是作為一名對圖形色彩都很敏感的前端工程師,自然也對圖形化操作界面愛不釋手但是在后端,運維等傳統程序員噼里啪啦命令行敲得飛起的時候,總感覺 前言 為什么鄙視我們GUI程序員T.T 隨著IT技術的日漸發展,各種可視化操作工具大行其道為廣大程序員們提供了不少的便利.特別是作為一名對圖形色彩...
摘要:前言為什么鄙視我們程序員隨著技術的日漸發展,各種可視化操作工具大行其道為廣大程序員們提供了不少的便利特別是作為一名對圖形色彩都很敏感的前端工程師,自然也對圖形化操作界面愛不釋手但是在后端,運維等傳統程序員噼里啪啦命令行敲得飛起的時候,總感覺 前言 為什么鄙視我們GUI程序員T.T 隨著IT技術的日漸發展,各種可視化操作工具大行其道為廣大程序員們提供了不少的便利.特別是作為一名對圖形色彩...
閱讀 3729·2021-11-24 09:39
閱讀 3444·2019-08-30 15:56
閱讀 1370·2019-08-30 15:55
閱讀 1031·2019-08-30 15:53
閱讀 1919·2019-08-29 18:37
閱讀 3601·2019-08-29 18:32
閱讀 3128·2019-08-29 16:30
閱讀 2918·2019-08-29 15:14