前端是有多難？

發(fā)布時(shí)間： 2017-06-21 16:07:44

前端是有多難？以下是小編整理的一點(diǎn)內(nèi)容，帶你了解學(xué)習(xí)前端有多難？

HTML
小編知道有一些學(xué)校會(huì)教一些簡(jiǎn)單的網(wǎng)頁(yè)制作，就是用 Dreamweaver 點(diǎn)一點(diǎn)的那種。大多也會(huì)留作業(yè)，最后交作業(yè)的時(shí)候看起來(lái)也像模像樣。
只要不看代碼?？戳舜a感覺(jué)寧愿選擇死亡。table 布局，無(wú)意義的 dom 節(jié)點(diǎn)。大小寫(xiě)混用，縮進(jìn)混亂。作為一個(gè)前端工程師，至少要寫(xiě)明白自己寫(xiě)的聲明是什么意思對(duì)吧？
然后還得減少不必要的 dom 節(jié)點(diǎn)，畢竟很多文章說(shuō)節(jié)點(diǎn)多會(huì)影響渲染速度。然后比較重要的一點(diǎn)兒是對(duì)于語(yǔ)義化標(biāo)簽的見(jiàn)解。比如什么時(shí)候該用 ul, 什么時(shí)候該用 section, aside，至于 head 里面的那些無(wú)聊的聲明只要會(huì)復(fù)制粘貼就好了，小編覺(jué)得沒(méi)什么意思。自信做到這些的應(yīng)該算差不多了。本文說(shuō)的是前端有多難，很多人都覺(jué)得這些標(biāo)簽簡(jiǎn)單。然而想象一下，要寫(xiě)多少的標(biāo)簽才能理解語(yǔ)義化的意義？要寫(xiě)多少頁(yè)面才能真正的明白這個(gè)節(jié)點(diǎn)應(yīng)該寫(xiě)什么標(biāo)簽？如何組合才算合理？

CSS
然后是關(guān)于 CSS，小編覺(jué)得這方面是很復(fù)雜的。并不像很多人覺(jué)得只是一些單詞的組合。一開(kāi)始小編會(huì)改 background-color 覺(jué)得開(kāi)心得不行，以為掌握了。在第一次寫(xiě)超過(guò)50個(gè)class之后就感覺(jué)想死，重復(fù)性勞動(dòng)，樣式修改調(diào)試，寫(xiě)法丑。接觸到 Sass 之后像是發(fā)現(xiàn)了新大陸，有一段時(shí)間甚至不會(huì)寫(xiě)原生 css 語(yǔ)法了。
然后折騰Sass -> Stylus
到這里結(jié)束了么？ naive
后面還有postcss, cssnext 這些東西。
在 react 生態(tài)中還有 css-modules, css-in-js 這些鬼東西。
雖然語(yǔ)法都不是很難。但是這么長(zhǎng)時(shí)間的折騰下來(lái)，雖說(shuō)提升是有的，但并沒(méi)有感覺(jué)到生產(chǎn)力有多少巨大的提升。
css 到這里還沒(méi)完。
還有BEM的命名方式要去理解。
到這里依舊沒(méi)有完。
css3 的新特性，還有各種 hack。比如如何實(shí)現(xiàn)footer始終在底部，內(nèi)容始終撐滿(mǎn)全局？如何實(shí)現(xiàn)條紋？
到這里結(jié)束了么？
依舊沒(méi)完。
css stage 4 等著去學(xué)習(xí)。
還有精力？
可以試著多做些兼容性相關(guān)的東西。會(huì)崩潰，相信我
到這里？
在小編的視野中差不多算結(jié)束了，然而有誰(shuí)能確定明天有沒(méi)有一個(gè)什么new-css之類(lèi)的東西解決什么問(wèn)題。

JS
來(lái)了來(lái)了，前端的一個(gè)核心。說(shuō)JS輕松么？這個(gè)我們共同來(lái)探討下！
首先是各種 dom 的增刪改，然后是ajax相關(guān)。學(xué)會(huì)了差不多能做簡(jiǎn)單的頁(yè)面了。然后對(duì)異步的理解。只有理解了異步才能正常地寫(xiě)js。然后是對(duì)js語(yǔ)言特性的理解。比如ES5如何實(shí)現(xiàn)繼承什么的，閉包。
總之這些就是面試題總是會(huì)問(wèn)的東西。
之后還應(yīng)該理解設(shè)計(jì)模式對(duì)吧？
到這里是正常的語(yǔ)言應(yīng)該學(xué)習(xí)的內(nèi)容了。然而js到這里只是起步。
之后一個(gè)前端工程師還得會(huì) ES2015/2016 之類(lèi)的吧?，F(xiàn)在不寫(xiě)個(gè)async誰(shuí)好意思說(shuō)自己是寫(xiě)前端的？
之后應(yīng)該是配合工具了，后文說(shuō)。
繼續(xù)順著語(yǔ)言往下說(shuō)。會(huì)了 ECMAScript 就能做個(gè)合格的前端了么？
還早呢。
之前火的 coffee script 現(xiàn)在不行了，然而 TypeScript 火了啊。不學(xué)一下怎么好意思追前端？
ts 對(duì)于之前寫(xiě) Java, C# 的非常友好，基本語(yǔ)法沒(méi)什么變化。然而可苦了那些不寫(xiě)這些語(yǔ)言的同學(xué)。語(yǔ)法改變倒是其次，思維方式的轉(zhuǎn)變才是難以接受的。
現(xiàn)在還有 Elm 了。

Tools
都說(shuō)二流程序員愛(ài)玩工具，那我應(yīng)該算是三流程序員了。對(duì)于vim如果我不算狂熱，那可能沒(méi)有幾個(gè)人算是教徒了。
我一直覺(jué)得編輯器應(yīng)該夠快，能夠跟上我思考的速度。在折騰了兩年總算契合了我的習(xí)慣。
對(duì)于其他編輯器，我只有一個(gè)不去選擇的理由：太慢
好了，說(shuō)完了我自己的選擇，得來(lái)看看我用過(guò)的編輯器了。
最初我也沒(méi)用過(guò)幾天的 Dreamweaver。直接上了 sublime。之后跟著快樂(lè)的sublime編輯器這套課程用了起來(lái)，應(yīng)該是我用過(guò)除了vim外時(shí)間第二長(zhǎng)的編輯器。
最初只覺(jué)得好看就用起來(lái)了。
然后學(xué)了一段時(shí)間PHPStorm，大概會(huì)用了JetBrains家的東西。說(shuō)實(shí)話，他們家的東西是不怎么好學(xué)的，細(xì)節(jié)太多。
然后我用起了vim。
作為一個(gè)0基礎(chǔ)起步的人，我在編輯器上折騰了兩年多才算找到了還算合適的方式。
其實(shí)我覺(jué)得很多人并沒(méi)有找到自己合適的編輯器，導(dǎo)致寫(xiě)代碼的熱情都降低了。
對(duì)于編輯器的總結(jié)是只能自己踩坑才能找到合適的編輯器和配置。然而需要時(shí)間踩坑??！
另外的工具大概是前端的工具集了，就像是gulp這類(lèi)的東西。
我在初學(xué)的時(shí)候流行的是grunt，然而我看到那個(gè)配置文件寫(xiě)的就完全不想用。
然后gulp就流行了起來(lái)，配置文件看起來(lái)簡(jiǎn)單好多，學(xué)！
然后gulp剛剛?cè)腴T(mén)就發(fā)現(xiàn)世界已經(jīng)被webpack統(tǒng)治了，怎么辦，學(xué)啊。
這么長(zhǎng)時(shí)間的折騰結(jié)束了么？沒(méi)有??！
還有rollup打包這些東西了。
像是php或者java就沒(méi)這么多破事，代碼不用打包，直接跑起來(lái)，哪里會(huì)半年換一套方案。
到現(xiàn)在，HTTP/2大行其道，可是前端卻沒(méi)有一款適合HTTP/2的打包工具。所以我覺(jué)得半年到一年左右還會(huì)有新的工具出現(xiàn)，大家準(zhǔn)備好重新學(xué)習(xí)吧 :)
剛剛突然想起了還有版本控制工具也算是工具。
一開(kāi)始不用版本控制，然后學(xué)Git，然后有些公司使用svn，又得學(xué)。會(huì)用是一回事，深入理解又是另一回事了。咱們得稍微深入地理解一些吧。比如版本控制如何看待移動(dòng)文件這件事的？
然后會(huì)了Git，怎么說(shuō)也得上Github混混臉熟吧。然后跟Gayhub上的一堆基佬交流一下，怒了提交個(gè)issue。過(guò)幾天發(fā)現(xiàn)這么簡(jiǎn)單的bug還沒(méi)fix掉，忍不了，我自己寫(xiě)patch，發(fā)個(gè)pr上去。
上面一行話說(shuō)得輕松，然而沒(méi)個(gè)一年半載哪里做得到。
版本控制會(huì)了，企業(yè)級(jí)私有倉(cāng)庫(kù)還得折騰一下吧，踩踩坑。

Functional
又一個(gè)重點(diǎn)來(lái)了。
就是js什么范式都能寫(xiě)。
因?yàn)榇蠖鄶?shù)人都是從C/C++學(xué)起的，所以總能先接觸到OOP思想。而且OOP掙錢(qián)容易，所以這其中大部分人是不愿意接觸不怎么掙錢(qián)而且還得重新學(xué)的的其他部分的，用我爹的話說(shuō)就是別搞那些沒(méi)用的。
然而現(xiàn)在不學(xué)FP真的能行么？
并不能啊，兄弟。
現(xiàn)在不寫(xiě)個(gè) react 好意思跟人說(shuō)自己是寫(xiě)前端么！寫(xiě)了react怎么說(shuō)也得接觸一下 redux 吧。然后就完了。。。和之前完全不同的新思維就來(lái)了。
之前jQuery綁定一個(gè)數(shù)據(jù)直接改就好了。現(xiàn)在出個(gè)單項(xiàng)數(shù)據(jù)流，什么操作都得發(fā)個(gè) action ，視圖得訂閱 store 。好吧，這還不算FP的范疇。
高階函數(shù)總是了吧。我之前從來(lái)沒(méi)想過(guò)高階函數(shù)怎么在 react 里面用，直到看了 connect 源碼吃了一驚，還能這么寫(xiě)！
還有說(shuō)爛了的柯里化。
現(xiàn)在還出現(xiàn)了很多js的函數(shù)式語(yǔ)言變種，就像 Elm , clojurescript什么的。
我真的覺(jué)得不學(xué)門(mén)函數(shù)式現(xiàn)在很難做前端了。
所以從入門(mén)的OOP到函數(shù)式，得費(fèi)多大功夫才能學(xué)會(huì)。人家都是學(xué)好一種就可以了，做前端的都得會(huì) 。

Back-End
Node.js帶來(lái)了前端的春天。然而也加重了前端的負(fù)擔(dān)。
之前寫(xiě)點(diǎn)兒jQuery就成了，現(xiàn)在還得會(huì)Node, 自己寫(xiě)后端。
寫(xiě)過(guò)后端的人多少都知道，代碼寫(xiě)起來(lái)并不算很難，難的是負(fù)擔(dān)。如何設(shè)計(jì)才能承載高并發(fā)大流量。如何應(yīng)對(duì)這些情況，宕機(jī)了怎么辦。
原來(lái)前端不用關(guān)心的東西現(xiàn)在都得考慮。畢竟 Node 和前端靠的近，人家問(wèn)起來(lái)自己不會(huì)多尷尬。
在我個(gè)人看來(lái)，很多寫(xiě)Node的只知道堆package, 對(duì)于Buffer, Event, Stream, Http并不是很了解。
所以寫(xiě) Node 的前端同學(xué)們啊，咱們的學(xué)習(xí)之路任重而道遠(yuǎn)。
學(xué)通了之后呢？那就已經(jīng)脫離前端的范疇了。

Database
這都說(shuō)到后端了。得扯一下數(shù)據(jù)庫(kù)吧。
數(shù)據(jù)庫(kù)絕不是簡(jiǎn)單的拼一下SQL語(yǔ)句就可以了。
在設(shè)計(jì)表結(jié)構(gòu)的時(shí)候要充分考慮之后的應(yīng)用場(chǎng)景，可維護(hù)性，承載量級(jí)。
就算不考慮上面的幾條，那至少得遵守到三范式吧？
數(shù)據(jù)庫(kù)應(yīng)用的時(shí)候還有很多要了解，比如一個(gè)表關(guān)聯(lián)是什么意思，事務(wù)是什么東西，應(yīng)用場(chǎng)景在哪里，如何處理慢查詢(xún)。
而我發(fā)現(xiàn)有些人都被ORM慣壞了，寫(xiě)SQL都生疏了。
好了，一個(gè)前端工程師做到這份上也算是仁至義盡了。后面的交給DBA吧。

Server
做一個(gè)獨(dú)立前端自然少不了和server打交道。關(guān)于 Nginx 至少得會(huì)安裝。然后會(huì)寫(xiě)簡(jiǎn)單的配置文件。這樣，就可以自己上一個(gè)網(wǎng)站了。用了 Node 還得學(xué)學(xué)反向代理的東西。
然而到這里哪里能滿(mǎn)足愛(ài)折騰的前端？
HTTPS 走起！從幾家服務(wù)商中選擇自己喜歡的，口碑好的，然后搞定證書(shū)。
跑了HTTPS依舊不滿(mǎn)意，追新的我們?cè)趺催€用幾十年前的 HTTP/1.1 ？ HTTP/2 走起，自己下載編譯安裝 Nginx ，然后調(diào)參數(shù)，改配置。
這個(gè)階段得學(xué)會(huì) Linux系編譯， SSL/TLS 的知識(shí)，加密算法，HTTP。。。
一個(gè)寫(xiě)前端的還得學(xué)這些 T_T
還沒(méi)完啊，HTTP懂了還有TCP/IP等著啃，Socket協(xié)議還得了解。
算法數(shù)據(jù)結(jié)構(gòu)與數(shù)學(xué)
一萬(wàn)個(gè)人告訴我算法和數(shù)據(jù)結(jié)構(gòu)才是計(jì)算機(jī)科學(xué)的核心。
List, Graph, Tree 什么的還得學(xué)學(xué)。反轉(zhuǎn)二叉樹(shù)這種知名題目還得寫(xiě)寫(xiě)?？炫?，水仙花什么的還得寫(xiě)一些
這個(gè)時(shí)候可能有些前端會(huì)問(wèn)，跟我有關(guān)系？
關(guān)系太大了。
我在實(shí)習(xí)的第一個(gè)月在做module load的一些方案，因?yàn)閷?duì)算法了解不深，寫(xiě)了很多操蛋的代碼。好在后來(lái)各種重構(gòu)沒(méi)讓我太過(guò)羞恥。
前端多多少少會(huì)接觸 canvas 和 WebGL 這些關(guān)于圖形學(xué)的東西?？墒侨绻€性代數(shù)學(xué)的不到家怎么可能寫(xiě)得好圖形學(xué)的代碼？
至于那些數(shù)據(jù)結(jié)構(gòu)對(duì)于前端應(yīng)用可能并不是很明顯，然而一旦碰到將是致命的。比如對(duì)于Immutable.js的理解
所以一個(gè)合格的前端算法還得過(guò)關(guān)。
工程化
工程化是我一直覺(jué)得前端的最最困難的地方。和其他的后端所不同的是，前端工程化的重要性遠(yuǎn)超算法數(shù)據(jù)結(jié)構(gòu)。
前端雖然也有幾十年了，可是一直處于邊緣地帶。沒(méi)有非常穩(wěn)定和合適的工程化實(shí)現(xiàn)。
千禧之前大多用C直接寫(xiě)。然后用PHP做后端，直接在HTML里面拼接。
然后出jQuery一統(tǒng)江湖。改dom解決所有問(wèn)題。
可是到這個(gè)時(shí)候是無(wú)法解決大量頁(yè)面所帶來(lái)的問(wèn)題的。比如性能，比如緩存，比如代碼重復(fù)，比如代碼可讀性差。
之后的Angular1的出世應(yīng)該算是一道驚雷。在我看來(lái)前端工程化大概從這里起步了。
源自于后端常用的依賴(lài)注入控制反轉(zhuǎn)之類(lèi)的思想開(kāi)始在前端嶄露頭角。
到現(xiàn)在，雖然群星閃耀，卻仍舊沒(méi)有一個(gè)穩(wěn)定的最好的解決方案。
從MVC -> MVVM -> Flux 的變化，現(xiàn)在似乎 Reactive 有著火起來(lái)的趨勢(shì)。
如何組織構(gòu)建頁(yè)面，如何在大量頁(yè)面中仍然能優(yōu)秀地組織好文件結(jié)構(gòu)，如何在面對(duì)需求變更的時(shí)候通過(guò)盡量少的修改代碼來(lái)實(shí)現(xiàn)需求。如何減少錯(cuò)誤的發(fā)生，和排錯(cuò)的代價(jià)。
在我看來(lái)，在前端領(lǐng)域，優(yōu)秀的工程化方案要比優(yōu)秀地算法更重要一些。

硬件
再來(lái)扯扯硬件吧。最重要的自然是電腦，畢竟我們這樣的“網(wǎng)癮少年/女”每天八九個(gè)小時(shí)都要對(duì)著電腦，甚至可能比和對(duì)象呆一起的時(shí)間都長(zhǎng)。然后是鍵盤(pán)。自從小編買(mǎi)了 HHKB 我只覺(jué)得沒(méi)有網(wǎng)上盛傳的那么神奇。我該怎么用還是怎么用，代碼速度依舊，開(kāi)心程度依舊。
所以小編覺(jué)得可能一把500塊的cherry就夠了。關(guān)鍵是一定要把大寫(xiě)鎖定 map 到 ctrl！所以做前端成本真的很高啊！

結(jié)論
到這里，你發(fā)現(xiàn)了么。前端一點(diǎn)兒都不簡(jiǎn)單啊。要學(xué)各種注定被淘汰的所謂“新”東西。還得學(xué)貫前后端，熟悉算法，了解工程化方案。學(xué)習(xí)前端真的很難嗎？小編覺(jué)得找到自己一套學(xué)習(xí)方法以及多練著很重要。當(dāng)然，找個(gè)培訓(xùn)機(jī)構(gòu)跟著老師同學(xué)一起學(xué)習(xí)那是最好不過(guò)了。現(xiàn)騰科推出HTML課程，金牌老師授課，給你與眾不同的學(xué)習(xí)驚喜。現(xiàn)在報(bào)名還有優(yōu)惠，具體可咨詢(xún)騰科（http://pesce.cn）。