前端程式設計師的焦慮感從何而來？

隨著網際網路產品越來越多，使用者們必定也會不斷的索取更好的使用者體驗，前端同學也會扮演著越來越重要的角色。責任越來越重，天花板就越來越高。

雖然前端的能力越來越強，技術棧要求也越來越高。但從工程角度出發，前端目前還處在一個較低的階級水平。

何謂前端工程

我剛畢業的時候，在一家創業公司做全棧，職稱是web開發工程師。當時前後端未分離，而我內心的工程，就是我手頭整個前後端工程程式碼。

當時對前端工程是沒有概念的，對我而言，前端就是js+css+html，它脫離了伺服器就沒了意義。單把這些程式碼拎出來，我也無法稱之為工程。

後來三大框架出現，前後端逐漸分離，開始出現“前端工程化”的概念。17年初時，曾面試過一家小創業公司，面試官問我前端工程化怎麼做？當時我回答：“前端工程化就是：程式碼模組化、功能元件化，打包、構建、釋出自動化、流程化。”在後面的一年中，我的工程化概念，大致還是如此，可能還會加上一個開發規範。

在這個“工程化”概念下，我所認為的“前端工程”，就是我眼前的“前端程式碼”，它的最終目的是為使用者輸出前端頁面。我最關注的即是：如何更高效率、更高質量的為使用者輸出體驗更好、能力更多的頁面。 這些年前端coder圍繞著這點也做了很多：

高效率

ES6+
多端統一
介面管理與mocker
框架、工具庫、元件庫

高質量

開發高質量

git
code review
開發規範

線上質量保證

監控系統

應急-快速回滾能力

更好的體驗

多尺寸適配
小程式
高效能

能力更多

複雜互動
native能力
動畫、遊戲

當然這其中也有一些交集，比如三大框架的出現既為高互動頁面提供了可能性，也提高了整體開發效率與質量。比如圍繞高效率與高質量會統一建設一個前端迭代管理系統，負責工程迭代、構建、釋出、回滾。

其實我也就隨便列列，有很多東西都沒涉及，但也能感受到這幾年前端領域的突飛猛進。再站在現在這個時期，看前後端未分離的時期，那段後端兼職js、視覺兼職css的上古年代，確實不能稱前端程式碼為“工程”，更不太好意思說前端程式設計師為“工程師”。這也難怪很多高校老師、後端同學不屑前端。

但立足現在，前端所涉及的範圍已經遠遠超出了當年，我們的“工程”複雜度與其能擁有的能力也超出當年的想象。我們可以驕傲地說自己是一名前端工程師了。但我覺得，我們似乎離軟體工程師還差一點點。

前端工程師，首先是軟體工程師

在我們這裡，業務需求所涉及的前端變更是需要做系統分析的，後端系統分析也是要參加的，這些涉及了上述所說種種。尤其是當需求變更較大、波及較廣，甚至還同時涉及了多個系統間的遷移、升級、重構，這其中的複雜度便會迅速上升。對於體量較大、使用者量較多的業務，這就是對工程師的一個考驗了。

當你不斷的經歷這些挑戰，可能突然有一刻，會有種感覺：作為一名工程師，以前都只關注自己手頭的前端程式碼，對於整個軟體系統工程的思考實在太少了。在這個軟體系統中，前端所涉及的工程扮演著哪些角色？哪些系統影響著它？它影響著哪些系統？它們的變更都會產生什麼影響？

所以前端工程師，其作為一名軟體工程師，應該從整個軟體系統工程去看。前端工程師不僅僅是完成自己的前端工程，而是完成了整個軟體系統中的一部分，它也不會脫離整個系統而獨立。而作為整個系統工程的一部分，前端工程要懂得去索取，懂得去影響，瞭解整體工程的能力與痛點，思考整體工程如何去提高。

這時候再來看這句話：前端工程師，先是軟體工程師。不知道大家能否多了一些體感。

前端地位低？

但如果我們從整個軟體工程來看，這時候我們就會意識到一個慘痛的事實：前端工程在整個系統工程中的地位太低了。在螞蟻，前端工程師往後走了一步，多了一層node層，在整體系統工程中擴大了自身佔比，還算好一些。而對於大多數只涉及web頁面工程的同學來說，望著這個巨大的軟體系統工程，即使有心，似乎也無力。

其實我覺得很多前端工程師是很厲害的。尤其是這幾年，越來越多的優秀畢業生加入了前端。有時候我會覺得，前端的互動邏輯如此複雜，其對程式碼水平的要求比後端大部分的業務場景高到不知道哪裡去了。但純粹的程式碼水平並無法決定前端工程的影響力。即使你能用0和1敲打出一個天花亂墜的頁面，那它也就是一個頁面。

前端工程在一個軟體系統中是處於最上游的（使用者入口）。因此，也就沒有其他系統需要調取前端系統的服務。在整個軟體系統中，前端對接的系統少，所影響的系統也少，工程地位低。不像後端，它既需要為前端提供能力，又需要問中後臺、資料層索取能力，也可能需要問其他業務後端索取能力，對接系統很多，工程地位自然也高。

由此又會導致，前端往往不是產品能否實現的決定性因素。在軟體系統中，需要上游系統調取下游系統服務。換言之，上游依託於下游。這自然而然的導致技術評估從下游開始。到前端評估時，已經是最後一道坎了。而這一道坎，業務方往往是無論如何也得過的。如果坎比較高（互動視覺難以實現），最終也是通過降低互動複雜度與使用者體驗，來保證產品功能先上。

有很多同學認為前端對業務的參與度太低了。但我們自我感覺對業務參與度也挺高呀，我知道產品都有哪些頁面，都有哪些功能。但瞭解並不是參與，影響才是參與。前端的工程影響力以及業務影響力，導致了前端對業務的參與度本質上是很低的。在這種情況下，說白了，很多前端只是流水線工人。視覺稿來了，實現它。實在實現不了，打回換一份更簡單的視覺稿。可不甘心做一個流水線工人啊，似乎都能看到年紀大了以後被裁員的結局。那這又該怎麼辦呢？

前端的焦慮

前端彷彿一直處在焦慮當中。前兩年我們的主要矛盾是日益爆發的前端新技術同前端程式設計師學不動之間的矛盾。而這一兩年前端技術棧趨於穩定，輪子相對也少了。加上前端程式設計師也比較拼，學不動的感覺也隨著無數個夜晚的學習而漸漸逝去。

這時候前端又開始了新的焦慮，前端的天花板是不是太低？工資是不是沒後端高？前端開發的壁壘在哪裡？我認為我們的主要矛盾已經發生了變化，變成了前端日益增長的工程地位訴求同前端工程侷限性之間的矛盾。

聰明或勤奮，再加上時間的積累，總是能解決“學不動”的問題的。但前端工程地位訴求怕是自身再怎麼努力也不一定能解決的。解決當下前端焦慮的辦法只能是打破前端工程侷限，增加前端工程影響力，拔高其工程地位。最終讓前端人員也能在軟體系統工程中當家做主，平等的參與到軟體系統建設當中。

只有前端崛起，前端工程師才能擺脫焦慮，而這不是一兩個人的戰鬥，需要大家一起去努力實現。

前端工程師的進階

能從現有工程中發現痛點，創造出一個系統或服務，提高效能、促進業務出成果。典型的如Node層，利用node服務端能力，搭建一層為前端服務的BFF層。於是便在一個軟體系統工程中，硬生生造出一層系統，擴充了前端工程師的工程地盤。

遠交近攻

在一個系統工程中，我們多做了一部分工作，自然就有人少做了一部分。現在我們無中生有的，是人家不願意做的“髒活累活”。如果我需要侵佔下游的核心能力時，他們便不一定讓步了。這時候我們可以採取“遠交近攻”。如果我們能直接對接下游的下游，同時又能擁有下游的能力。那我們下游還有什麼存在的意義呢？現在流行的FaaS似乎就給我們提供了一個idea、亦或者就是個契機。

反客為主

前端雖然是上游系統，但可以通過提高自身工程能力，主動地放大業務可能性。將可能性的瓶頸下拋，進而促進下游系統提高自身能力。化被動為主動，改接受為影響，進而提高自身工程地位。典型的如小程式。小程式最初是由客戶端同學去實現，最開始其實也是致力於平臺生態問題。因其技術棧基本與前端契合，極大了利好了前端開發者（而不是客戶端開發）。

前端開發同學瘋狂湧入後，一方面做了非常多基建工作，極大提高了小程式開發效率。另一方面，大量的小程式讓業務看到小程式的無限可能。進而對小程式本身能力也多了很多訴求，如微信小程式支援了Npm包。社群裡，前端程式設計師在小程式建設上不斷努力，如今說到小程式，大家似乎都在誇前端厲害。

相信隨著無數優秀的前端同學不斷的奮鬥，幾年以後的前端工程師必然又是另外一番成就。希望屆時，我們可以驕傲的稱自己為一名軟體工程師。我們依舊會不斷學習，但學習的背後不再是因為焦慮，而是純粹對於工程與程式碼的熱愛~

加油吧前端程式設計師們！

自己是從事了五年的前端工程師，不少人私下問我，2019年前端該怎麼學，方法有沒有？

沒錯，年初我花了一個多月的時間整理出來的學習資料，希望能幫助那些想學習前端，卻又不知道怎麼開始學習的朋友。

這裡推薦一下我的前端學習交流q-u-n：784783012，裡面都是學習前端的從最基礎的HTML+CSS+JS【炫酷特效，遊戲，外掛封裝，設計模式】到移動端HTML5的專案實戰的學習資料都有整理，送給每一位前端小夥伴。2019最新技術，與企業需求同步。好友都在裡面學習交流，每天都會有大牛定時講解前端技術!

點選： 加入

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69901074/viewspace-2637639/，如需轉載，請註明出處，否則將追究法律責任。