為前端工程之崛起而編程！
作者 | 螞蟻保險體驗技術團隊
責編 | 胡巍巍
本文經授權轉載知乎「相學長」
曾經在知乎的一個問答《從事前端真的沒有後端工資高？》中談到自己對前端工程師的天花板的認識：
我覺得，隨著互聯網產品越來越多，用戶們必定也會不斷的索取更好的用戶體驗，前端同學也會扮演著越來越重要的角色。責任越來越重，天花板就越來越高(誒，自己說的話，貌似也沒必要加什麼引用......)。
當時的角度主要注重產品體驗上。現在入職螞蟻1年左右，對其又產生了一些新的想法。雖然前端的能力越來越強，技術棧要求也越來越高。但從工程角度出發，前端目前還處在一個較低的階級水平。
首先，我們作為前端工程師，是怎麼定義這個「工程」的呢？
何謂前端工程
我剛畢業的時候，在一家創業公司做全棧，職稱是Web開發工程師。當時前後端未分離，而我內心的工程，就是我手頭整個前後端工程代碼。當時對前端工程是沒有概念的，對我而言，前端就是JS+CSS+HTML，它脫離了伺服器就沒了意義。單把這些代碼拎出來，我也無法稱之為工程。
後來三大框架出現，前後端逐漸分離，開始出現「前端工程化」的概念。2017年初時，曾面試過一家小創業公司，面試官問我前端工程化怎麼做？
當時我回答：「前端工程化就是：代碼模塊化、功能組件化，打包、構建、發布自動化、流程化。」在後面的一年中，我的工程化概念，大致還是如此，可能還會加上一個開發規範。
在這個「工程化」概念下，我所認為的「前端工程」，就是我眼前的 「前端代碼」，它的最終目的是為用戶輸出前端頁面。
我最關注的即是：如何更高效率、更高質量的為用戶輸出體驗更好、能力更多的頁面。這些年前端Coder圍繞著這點也做了很多：
高效率：
- ES6+
- 多端統一
- 介面管理與Mocker
- 框架、工具庫、組件庫
高質量：
- 開發高質量
- Git
- Code Review
- 開發規範
- 線上質量保證
- 監控系統
- 應急-快速回滾能力
更好的體驗：
- 多尺寸適配
- 小程序
- 高性能
能力更多：
- 複雜交互
- Native能力
- 動畫、遊戲
當然這其中也有一些交集，比如三大框架的出現既為高交互頁面提供了可能性，也提高了整體開發效率與質量。比如圍繞高效率與高質量會統一建設一個前端迭代管理系統，負責工程迭代、構建、發布、回滾。
其實我也就隨便列列，有很多東西都沒涉及，但也能感受到這幾年前端領域的突飛猛進。再站在現在這個時期，看前後端未分離的時期，那段後端兼職JS、視覺兼職CSS的上古年代，確實不能稱前端代碼為「工程」，更不太好意思說前端程序員為「工程師」。這也難怪很多高校老師、後端同學不屑前端。
但立足現在，前端所涉及的範圍已經遠遠超出了當年，我們的「工程」複雜度與其能擁有的能力也超出當年的想像。我們可以驕傲地說自己是一名前端工程師了。但我覺得，我們似乎離軟體工程師還差一點點。
前端工程師，首先是軟體工程師
網上有很多人，都說過這句話。說的似乎很有道理，卻又沒啥體感。而近幾天我對這句話感受日深，這其中很大原因歸功於螞蟻在Node上的豐富實踐。
螞蟻應該是實踐Node比較多的公司了。目前螞蟻的大部分移動端業務，都有對應的體驗適配層BFF層，也即大家通俗理解中的Node中間層。
它的主要職責為：銜接頁面與後端，聚合後端介面，做好數據轉化，輸出最滿足頁面期望的數據結果。
它的主要目的為：讓後端更專註於領域模型，將頁面數據的設計交與前端，彼此更專業高效。更通俗點說：讓業務開發更快！
而加入螞蟻后，BFF層可以說給我增加了很多工作量。我們需要開始給自己頁面設計介面，需要對接多個後台系統。新增介面，可能需要考慮拓展性；舊的介面變更，需要考慮兼容性。
如果涉及後端變更，需要評估其變更影響，需要評估系統的依賴與發布的先後順序。此外還需要考慮需求上線時，Node層與前端的灰度方案、監控方案、應急方案。
所以在我們組，業務需求所涉及的前端變更是需要做系統分析的，後端系統分析也是要參加的，這些涉及了上述所說種種。
尤其是當需求變更較大、波及較廣，甚至還同時涉及了多個系統間的遷移、升級、重構，這其中的複雜度便會迅速上升。對於體量較大、用戶量較多的業務，這就是對工程師的一個考驗了。
當你不斷的經歷這些挑戰，可能突然有一刻，會有種感覺：作為一名工程師，以前都只關注自己手頭的前端代碼，對於整個軟體系統工程的思考實在太少了。
在這個軟體系統中，前端所涉及的工程扮演著哪些角色？哪些系統影響著它？它影響著哪些系統？它們的變更都會產生什麼影響？
所以前端工程師，其作為一名軟體工程師，應該從整個軟體系統工程去看。前端工程師不僅僅是完成自己的前端工程，而是完成了整個軟體系統中的一部分，它也不會脫離整個系統而獨立。
而作為整個系統工程的一部分，前端工程要懂得去索取，懂得去影響，了解整體工程的能力與痛點，思考整體工程如何去提高。
這時候再來看這句話：前端工程師，先是軟體工程師。不知道大家能否多了一些體感。
前端地位低
但如果我們從整個軟體工程來看，這時候我們就會意識到一個慘痛的事實：前端工程在整個系統工程中的地位太低了。
在螞蟻，前端工程師往後走了一步，多了一層Node層，在整體系統工程中擴大了自身佔比，還算好一些。
而對於大多數只涉及Web頁面工程的同學來說，望著這個巨大的軟體系統工程，即使有心，似乎也無力。
其實我覺得很多前端工程師是很厲害的。尤其是這幾年，越來越多的優秀畢業生加入了前端。
有時候我會覺得，前端的交互邏輯如此複雜，其對代碼水平的要求比後端大部分的業務場景高到不知道哪裡去了。
但純粹的代碼水平並無法決定前端工程的影響力。即使你能用0和1敲打出一個天花亂墜的頁面，那它也就是一個頁面。
前端工程在一個軟體系統中是處於最上游的（用戶入口）。因此，也就沒有其他系統需要調取前端系統的服務。
在整個軟體系統中，前端對接的系統少，所影響的系統也少，工程地位低。不像後端，它既需要為前端提供能力，又需要問中後台、數據層索取能力，也可能需要問其他業務後端索取能力，對接系統很多，工程地位自然也高。
由此又會導致，前端往往不是產品能否實現的決定性因素。在軟體系統中，需要上游系統調取下游系統服務。
換言之，上游依託於下游。這自然而然的導致技術評估從下游開始。到前端評估時，已經是最後一道坎了。
而這一道坎，業務方往往是無論如何也得過的。如果坎比較高（交互視覺難以實現），最終也是通過降低交互複雜度與用戶體驗，來保證產品功能先上。
有很多同學認為前端對業務的參與度太低了。但我們自我感覺對業務參與度也挺高呀，我知道產品都有哪些頁面，都有哪些功能。
但了解並不是參與，影響才是參與。前端的工程影響力以及業務影響力，導致了前端對業務的參與度本質上是很低的。
在這種情況下，說白了，很多前端只是流水線工人。視覺稿來了，實現它。
實在實現不了，打回換一份更簡單的視覺稿。可不甘心做一個流水線工人啊，似乎都能看到年紀大了以後被裁員的結局。那這又該怎麼辦呢？
前端的焦慮
前端彷彿一直處在焦慮當中。前兩年我們的主要矛盾是日益爆發的前端新技術同前端程序員學不動之間的矛盾。
而這一兩年前端技術棧趨於穩定，輪子相對也少了。加上前端程序員也比較拼，學不動的感覺也隨著無數個夜晚的學習而漸漸逝去。
這時候前端又開始了新的焦慮，前端的天花板是不是太低？工資是不是沒後端高？前端開發的壁壘在哪裡？
我認為我們的主要矛盾已經發生了變化，變成了前端日益增長的工程地位訴求同前端工程局限性之間的矛盾。
聰明或勤奮，再加上時間的積累，總是能解決「學不動」的問題的。但前端工程地位訴求怕是自身再怎麼努力也不一定能解決的。
解決當下前端焦慮的辦法只能是打破前端工程局限，增加前端工程影響力，拔高其工程地位。最終讓前端人員也能在軟體系統工程中當家做主，平等的參與到軟體系統建設當中。
只有前端崛起，前端工程師才能擺脫焦慮，而這不是一兩個人的戰鬥，需要大家一起去努力實現。我個人想了三條計策。
崛起三計
1.無中生有
能從現有工程中發現痛點，創造出一個系統或服務，提高效能、促進業務出成果。
典型的如Node層，利用Node服務端能力，搭建一層為前端服務的BFF層。於是便在一個軟體系統工程中，硬生生造出一層系統，拓展了前端工程師的工程地盤。
2.遠交近攻
在一個系統工程中，我們多做了一部分工作，自然就有人少做了一部分。現在我們無中生有的，是人家不願意做的「臟活累活」。
如果我需要侵佔下游的核心能力時，他們便不一定讓步了。這時候我們可以採取「遠交近攻」。如果我們能直接對接下游的下游，同時又能擁有下游的能力。
那我們下游還有什麼存在的意義呢？現在流行的FaaS似乎就給我們提供了一個Idea、亦或者就是個契機。
3.反客為主
前端雖然是上游系統，但可以通過提高自身工程能力，主動地放大業務可能性。將可能性的瓶頸下拋，進而促進下游系統提高自身能力。
化被動為主動，改接受為影響，進而提高自身工程地位。典型的如小程序。小程序最初是由客戶端同學去實現，最開始其實也是致力於平台生態問題。
因其技術棧基本與前端契合，極大了利好了前端開發者（而不是客戶端開發）。前端開發同學瘋狂湧入後，一方面做了非常多基建工作，極大提高了小程序開發效率。
另一方面，大量的小程序讓業務看到小程序的無限可能。進而對小程序本身能力也多了很多訴求，如微信小程序支持了NPM包。社區里，前端程序員在小程序建設上不斷努力，如今說到小程序，大家似乎都在誇前端厲害。
相信隨著無數優秀的前端同學不斷的奮鬥，幾年以後的前端工程師必然又是另外一番成就。
希望屆時，我們可以驕傲的稱自己為一名軟體工程師。我們依舊會不斷學習，但學習的背後不再是因為焦慮，而是純粹對於工程與代碼的熱愛~
加油吧前端程序員們！讓我們一起為前端工程之崛起而編程。
TAG:CSDN |