前端是有多難?
發(fā)布時間:
2017-06-21 16:07:44
前端是有多難?以下是小編整理的一點內(nèi)容,帶你了解學(xué)習(xí)前端有多難?
HTML
小編知道有一些學(xué)校會教一些簡單的網(wǎng)頁制作,就是用 Dreamweaver 點一點的那種。大多也會留作業(yè),最后交作業(yè)的時候看起來也像模像樣。
只要不看代碼。看了代碼感覺寧愿選擇死亡。table 布局,無意義的 dom 節(jié)點。大小寫混用,縮進混亂。作為一個前端工程師,至少要寫明白自己寫的聲明是什么意思對吧?
然后還得減少不必要的 dom 節(jié)點,畢竟很多文章說節(jié)點多會影響渲染速度。然后比較重要的一點兒是對于語義化標(biāo)簽的見解。比如什么時候該用 ul,
什么時候該用 section, aside,至于 head
里面的那些無聊的聲明只要會復(fù)制粘貼就好了,小編覺得沒什么意思。自信做到這些的應(yīng)該算差不多了。本文說的是前端有多難,很多人都覺得這些標(biāo)簽簡單。然而想象一下,要寫多少的標(biāo)簽才能理解語義化的意義?要寫多少頁面才能真正的明白這個節(jié)點應(yīng)該寫什么標(biāo)簽?如何組合才算合理?
CSS
然后是關(guān)于
CSS,小編覺得這方面是很復(fù)雜的。并不像很多人覺得只是一些單詞的組合。一開始小編會改 background-color 覺得開心得不行,以為掌握了。在第一次寫超過50個class之后就感覺想死,重復(fù)性勞動,樣式修改調(diào)試,寫法丑。接觸到
Sass 之后像是發(fā)現(xiàn)了新大陸,有一段時間甚至不會寫原生 css 語法了。
然后折騰Sass -> Stylus
到這里結(jié)束了么? naive
后面還有postcss, cssnext 這些東西。
在 react 生態(tài)中還有 css-modules, css-in-js 這些鬼東西。
雖然語法都不是很難。但是這么長時間的折騰下來,雖說提升是有的,但并沒有感覺到生產(chǎn)力有多少巨大的提升。
css 到這里還沒完。
還有BEM的命名方式要去理解。
到這里依舊沒有完。
css3 的新特性,還有各種 hack。比如如何實現(xiàn)footer始終在底部,內(nèi)容始終撐滿全局?如何實現(xiàn)條紋?
到這里結(jié)束了么?
依舊沒完。
css stage 4 等著去學(xué)習(xí)。
還有精力?
可以試著多做些兼容性相關(guān)的東西。會崩潰,相信我
到這里?
在小編的視野中差不多算結(jié)束了,然而有誰能確定明天有沒有一個什么new-css之類的東西解決什么問題。
JS
來了來了,前端的一個核心。說JS輕松么?這個我們共同來探討下!
首先是各種 dom 的增刪改,然后是ajax相關(guān)。學(xué)會了差不多能做簡單的頁面了。然后對異步的理解。只有理解了異步才能正常地寫js。然后是對js語言特性的理解。比如ES5如何實現(xiàn)繼承什么的,閉包。
總之這些就是面試題總是會問的東西。
之后還應(yīng)該理解設(shè)計模式對吧?
到這里是正常的語言應(yīng)該學(xué)習(xí)的內(nèi)容了。然而js到這里只是起步。
之后一個前端工程師還得會 ES2015/2016 之類的吧。現(xiàn)在不寫個async誰好意思說自己是寫前端的?
之后應(yīng)該是配合工具了,后文說。
繼續(xù)順著語言往下說。會了 ECMAScript 就能做個合格的前端了么?
還早呢。
之前火的 coffee script 現(xiàn)在不行了,然而 TypeScript 火了啊。不學(xué)一下怎么好意思追前端?
ts 對于之前寫 Java, C# 的非常友好,基本語法沒什么變化。然而可苦了那些不寫這些語言的同學(xué)。語法改變倒是其次,思維方式的轉(zhuǎn)變才是難以接受的。
現(xiàn)在還有 Elm 了。
Tools
都說二流程序員愛玩工具,那我應(yīng)該算是三流程序員了。對于vim如果我不算狂熱,那可能沒有幾個人算是教徒了。
我一直覺得編輯器應(yīng)該夠快,能夠跟上我思考的速度。在折騰了兩年總算契合了我的習(xí)慣。
對于其他編輯器,我只有一個不去選擇的理由:太慢
好了,說完了我自己的選擇,得來看看我用過的編輯器了。
最初我也沒用過幾天的 Dreamweaver。直接上了 sublime。之后跟著快樂的sublime編輯器這套課程用了起來,應(yīng)該是我用過除了vim外時間第二長的編輯器。
最初只覺得好看就用起來了。
然后學(xué)了一段時間PHPStorm,大概會用了JetBrains家的東西。說實話,他們家的東西是不怎么好學(xué)的,細節(jié)太多。
然后我用起了vim。
作為一個0基礎(chǔ)起步的人,我在編輯器上折騰了兩年多才算找到了還算合適的方式。
其實我覺得很多人并沒有找到自己合適的編輯器,導(dǎo)致寫代碼的熱情都降低了。
對于編輯器的總結(jié)是只能自己踩坑才能找到合適的編輯器和配置。然而需要時間踩坑啊!
另外的工具大概是前端的工具集了,就像是gulp這類的東西。
我在初學(xué)的時候流行的是grunt,然而我看到那個配置文件寫的就完全不想用。
然后gulp就流行了起來,配置文件看起來簡單好多,學(xué)!
然后gulp剛剛?cè)腴T就發(fā)現(xiàn)世界已經(jīng)被webpack統(tǒng)治了,怎么辦,學(xué)啊。
這么長時間的折騰結(jié)束了么?沒有啊!
還有rollup打包這些東西了。
像是php或者java就沒這么多破事,代碼不用打包,直接跑起來,哪里會半年換一套方案。
到現(xiàn)在,HTTP/2大行其道,可是前端卻沒有一款適合HTTP/2的打包工具。所以我覺得半年到一年左右還會有新的工具出現(xiàn),大家準(zhǔn)備好重新學(xué)習(xí)吧 :)
剛剛突然想起了還有版本控制工具也算是工具。
一開始不用版本控制,然后學(xué)Git, 然后有些公司使用svn,又得學(xué)。會用是一回事,深入理解又是另一回事了。咱們得稍微深入地理解一些吧。比如版本控制如何看待移動文件這件事的?
然后會了Git, 怎么說也得上Github混混臉熟吧。然后跟Gayhub上的一堆基佬交流一下,怒了提交個issue。過幾天發(fā)現(xiàn)這么簡單的bug還沒fix掉,忍不了,我自己寫patch,發(fā)個pr上去。
上面一行話說得輕松,然而沒個一年半載哪里做得到。
版本控制會了,企業(yè)級私有倉庫還得折騰一下吧,踩踩坑。
Functional
又一個重點來了。
就是js什么范式都能寫。
因為大多數(shù)人都是從C/C++學(xué)起的,所以總能先接觸到OOP思想。而且OOP掙錢容易,所以這其中大部分人是不愿意接觸不怎么掙錢而且還得重新學(xué)的的其他部分的,用我爹的話說就是別搞那些沒用的。
然而現(xiàn)在不學(xué)FP真的能行么?
并不能啊,兄弟。
現(xiàn)在不寫個 react 好意思跟人說自己是寫前端么!寫了react怎么說也得接觸一下 redux 吧。然后就完了。。。和之前完全不同的新思維就來了。
之前jQuery綁定一個數(shù)據(jù)直接改就好了。現(xiàn)在出個單項數(shù)據(jù)流,什么操作都得發(fā)個 action ,視圖得訂閱 store 。好吧,這還不算FP的范疇。
高階函數(shù)總是了吧。我之前從來沒想過高階函數(shù)怎么在 react 里面用,直到看了 connect 源碼吃了一驚,還能這么寫!
還有說爛了的柯里化。
現(xiàn)在還出現(xiàn)了很多js的函數(shù)式語言變種,就像 Elm , clojurescript什么的。
我真的覺得不學(xué)門函數(shù)式現(xiàn)在很難做前端了。
所以從入門的OOP到函數(shù)式,得費多大功夫才能學(xué)會。人家都是學(xué)好一種就可以了,做前端的都得會 。
Back-End
Node.js帶來了前端的春天。然而也加重了前端的負擔(dān)。
之前寫點兒jQuery就成了,現(xiàn)在還得會Node, 自己寫后端。
寫過后端的人多少都知道,代碼寫起來并不算很難,難的是負擔(dān)。如何設(shè)計才能承載高并發(fā)大流量。如何應(yīng)對這些情況,宕機了怎么辦。
原來前端不用關(guān)心的東西現(xiàn)在都得考慮。畢竟 Node 和前端靠的近,人家問起來自己不會多尷尬。
在我個人看來,很多寫Node的只知道堆package, 對于Buffer, Event, Stream, Http并不是很了解。
所以寫 Node 的前端同學(xué)們啊,咱們的學(xué)習(xí)之路任重而道遠。
學(xué)通了之后呢?那就已經(jīng)脫離前端的范疇了。
Database
這都說到后端了。得扯一下數(shù)據(jù)庫吧。
數(shù)據(jù)庫絕不是簡單的拼一下SQL語句就可以了。
在設(shè)計表結(jié)構(gòu)的時候要充分考慮之后的應(yīng)用場景,可維護性,承載量級。
就算不考慮上面的幾條,那至少得遵守到三范式吧?
數(shù)據(jù)庫應(yīng)用的時候還有很多要了解,比如一個表關(guān)聯(lián)是什么意思,事務(wù)是什么東西,應(yīng)用場景在哪里,如何處理慢查詢。
而我發(fā)現(xiàn)有些人都被ORM慣壞了,寫SQL都生疏了。
好了,一個前端工程師做到這份上也算是仁至義盡了。后面的交給DBA吧。
Server
做一個獨立前端自然少不了和server打交道。關(guān)于 Nginx 至少得會安裝。然后會寫簡單的配置文件。這樣,就可以自己上一個網(wǎng)站了。用了 Node 還得學(xué)學(xué)反向代理的東西。
然而到這里哪里能滿足愛折騰的前端?
HTTPS 走起!從幾家服務(wù)商中選擇自己喜歡的,口碑好的,然后搞定證書。
跑了HTTPS依舊不滿意,追新的我們怎么還用幾十年前的 HTTP/1.1 ? HTTP/2 走起,自己下載編譯安裝 Nginx ,然后調(diào)參數(shù),改配置。
這個階段得學(xué)會 Linux系 編譯, SSL/TLS 的知識,加密算法,HTTP。。。
一個寫前端的還得學(xué)這些 T_T
還沒完啊,HTTP懂了還有TCP/IP等著啃,Socket協(xié)議還得了解。
算法數(shù)據(jù)結(jié)構(gòu)與數(shù)學(xué)
一萬個人告訴我算法和數(shù)據(jù)結(jié)構(gòu)才是計算機科學(xué)的核心。
List, Graph, Tree 什么的還得學(xué)學(xué)。反轉(zhuǎn)二叉樹這種知名題目還得寫寫。快排,水仙花什么的還得寫一些
這個時候可能有些前端會問,跟我有關(guān)系?
關(guān)系太大了。
我在實習(xí)的第一個月在做module load的一些方案,因為對算法了解不深,寫了很多操蛋的代碼。好在后來各種重構(gòu)沒讓我太過羞恥。
前端多多少少會接觸 canvas 和 WebGL 這些關(guān)于圖形學(xué)的東西。可是如果線性代數(shù)學(xué)的不到家怎么可能寫得好圖形學(xué)的代碼?
至于那些數(shù)據(jù)結(jié)構(gòu)對于前端應(yīng)用可能并不是很明顯,然而一旦碰到將是致命的。比如對于Immutable.js的理解
所以一個合格的前端算法還得過關(guān)。
工程化
工程化是我一直覺得前端的最最困難的地方。和其他的后端所不同的是,前端工程化的重要性遠超算法數(shù)據(jù)結(jié)構(gòu)。
前端雖然也有幾十年了,可是一直處于邊緣地帶。沒有非常穩(wěn)定和合適的工程化實現(xiàn)。
千禧之前大多用C直接寫。然后用PHP做后端,直接在HTML里面拼接。
然后出jQuery一統(tǒng)江湖。改dom解決所有問題。
可是到這個時候是無法解決大量頁面所帶來的問題的。比如性能,比如緩存,比如代碼重復(fù),比如代碼可讀性差。
之后的Angular1的出世應(yīng)該算是一道驚雷。在我看來前端工程化大概從這里起步了。
源自于后端常用的依賴注入控制反轉(zhuǎn)之類的思想開始在前端嶄露頭角。
到現(xiàn)在,雖然群星閃耀,卻仍舊沒有一個穩(wěn)定的最好的解決方案。
從MVC -> MVVM -> Flux 的變化,現(xiàn)在似乎 Reactive 有著火起來的趨勢。
如何組織構(gòu)建頁面,如何在大量頁面中仍然能優(yōu)秀地組織好文件結(jié)構(gòu),如何在面對需求變更的時候通過盡量少的修改代碼來實現(xiàn)需求。如何減少錯誤的發(fā)生,和排錯的代價。
在我看來,在前端領(lǐng)域,優(yōu)秀的工程化方案要比優(yōu)秀地算法更重要一些。
硬件
再來扯扯硬件吧。最重要的自然是電腦,畢竟我們這樣的“網(wǎng)癮少年/女”每天八九個小時都要對著電腦,甚至可能比和對象呆一起的時間都長。然后是鍵盤。自從小編買了 HHKB 我只覺得沒有網(wǎng)上盛傳的那么神奇。我該怎么用還是怎么用,代碼速度依舊,開心程度依舊。
所以小編覺得可能一把500塊的cherry就夠了。關(guān)鍵是一定要把大寫鎖定 map 到 ctrl!所以做前端成本真的很高啊!
結(jié)論
到這里,你發(fā)現(xiàn)了么。前端一點兒都不簡單啊。要學(xué)各種注定被淘汰的所謂“新”東西。還得學(xué)貫前后端,熟悉算法,了解工程化方案。學(xué)習(xí)前端真的很難嗎?小編覺得找到自己一套學(xué)習(xí)方法以及多練著很重要。當(dāng)然,找個培訓(xùn)機構(gòu)跟著老師同學(xué)一起學(xué)習(xí)那是最好不過了。現(xiàn)騰科推出HTML課程,金牌老師授課,給你與眾不同的學(xué)習(xí)驚喜。現(xiàn)在報名還有優(yōu)惠,具體可咨詢騰科(http://www.didibird.cn)。

上一篇:
六個你可能不知道的bash小秘笈
下一篇:
IT人才畢業(yè)出來就拿1W+工資,這是真的?