2018年的前端架構師都在幹嘛?

TooBug發表於2018-06-01

前言:本文整理自自己在知乎問題《2018年的前端是否有『架構』可言?》的回答。據說是有掘金限量筆記本可以拿,於是很沒骨氣地整理成文章發出來。如果大家也喜歡掘金的筆記本,也來發文章哦。

皮一下

一,明確下架構的定義,在知乎的這個問題中,題主說“整個後端的架構是非常複雜和龐大的,一個好的架構師需要在數不清的方案組合中進行架構選擇”。看起來架構似乎是一個在無數方案元件中做選擇的問題。

所以,如果回答“前端的方案組合很多,所以架構也很麻煩”,是否就可以回應這個問題了。那麼,前端方案組合多嗎?確實是多如牛毛吧,比後端多很多很多吧。

以上是牛角尖。

一、關注點

後端架構的目標,題主也說到了,高效能、高可用、可擴充套件、安全。

至於後面說的那麼多知識點,雖然都是有用的,但是不免有些掉書袋了。高可用有各種難點,有各個方面的高可用需要關注,但事實上,後端經過這麼多年的發展,尤其是海量使用者場景大量出現以後,這些問題的解決方案也都非常明確了。如果不明確的也是業界公認暫時無解的問題,例如分散式CAP等。至於其中碰到的具體問題的的具體技術上的策略,如果還需要自己從頭去想,那這個後端工程師(還不叫架構師)應該是不合格的。我理解,做後端的架構其實基本上是在前人整理過的各種場景的解決方案中做選擇。

那麼前端呢?目標也是高效能、高可用、可擴充套件、安全嗎?所以只要資料庫不用選,語言不用選,框架三選一,架構就簡單了?我認為這是對前端的關注點理解不到位的體現。

二、前端的核心關注點——使用者

作為前端工程師,關注點是什麼呢?首先就是使用者,包括使用者側的操作和使用者體驗。

例如一個介面給到使用者,比如報錯是紅色文字還是輸入框變紅?Loading放頂上還是頁面中間?使用者點選提交後按鈕顯示Loading還是灰掉?轉菊花還是骨架屏?先顯示佔點陣圖還是先白屏?

再比如使用者訪問我的網站快不快,用起來爽不爽,會不會覺得卡,會不會覺得low。這些東西會決定你的頁面是單頁面還是多頁面,URL如何設計,載入策略是什麼?

我認為這些才是前端最該關注的東西。

所以我做的架構一點都不高大上。僅僅是決定如何讓網站載入更快,如何不引入不必要的程式碼,把不必要的程式碼幹掉,如何讓使用者載入最少的內容,如何讓使用者最快看到效果,前端渲染還是後端渲染,同步輸出還是非同步輸出等等。

是不是覺得一點都不是架構師乾的事?但前端構架師確實就是在幹這些事。所以,你要說前端架構師是一個技術上的架構師,倒還不如說是更關注使用者的體驗架構師。從這個角度來說,前端架構師和跟後端架構師的關注點不在一個維度上。

三、工程難度

題主說,“最多算上錯誤監控、埋點方案、快取策略等偏運維的決策”,彷彿這些是一句話可以搞定的很簡單的事情。

是,後端錯誤監控不難,無非try..catch嘛,再不濟程式掛了還有各種運維工具可以救人於水火。但是前端呢?一個ajax載入失敗了怎麼監控,一個css載入失敗了怎麼監控,再極端一點,瀏覽器卡死了怎麼監控,頁面崩潰了怎麼監控?

至於埋點,能做得好的我都非常佩服。連使用者關閉了你的頁面都監控不到,還想通過埋點來獲取業務和技術資料?

至於快取就更奇葩了,到底有沒有快取,到底是200還是304還是沒有請求了,到底版本對不對,到底有沒有被代理瞎搞,到底這個神奇的瀏覽器是怎麼處理快取的……別以為說一句“加個快取”,就這麼輕輕鬆鬆地搞定了。每一個把快取玩好的前端工程師都值得尊敬。就不說更多的什麼localStorage/serviceWorker之類的了。

說這一大段,並不是要說前端架構師搞這些很苦很累,你們要尊重我們。而是想說,這些不起眼的事情,不如想象的那麼容易,很多時候架構師是在幫助工程師探路或者踩坑,把這些東西的技術方案搞定。

四、面向團隊

現階段的前端工程化還不成熟,這是個切實的情況。架構師在專案選型的同時,有相當部分的精力會放到工程化方案的選型上。是否用webpack,是否用npm,是否用TypeScript,是否用ES6/7/8,是否要babel,是否用PostCSS。是否要CI,是否要自動打包釋出。是否要分包載入,是否要抽取CSS檔案……

這些事,在後端可能不存在,在客戶端可能也不存在,或者即使存在,也被IDE悄悄地代勞了。作為專案的選型者,寫幾個依賴,install一下就開工了。但是前端不行,前端這裡有大量的工程化選型或者配置/開發的任務。

作為架構師,如何選擇一套好用的、沒有坑的語言/構建工具,也不容易。

我舉個例子吧,大家可能覺得TypeScript很好,直接用不就好了嗎?殊不知,TypeScript需要配置tsc或者webpackts-loader(現在babel也可以了),還有tsconfig檔案,以及各種.d.ts檔案。當然,即使這樣,也有可能在寫程式碼的時候報一堆無法解決的錯誤,需要你花大量的時間去研究為什麼有這個做,怎樣可以不報錯(也可能根本就不能不報錯)。當你在Vue中使用TypeScript時,你需要研究怎樣讓它識別Vue Component的型別,怎樣做自動提示和型別檢查。當你在ajax使用時會發現你要研究怎樣將服務端返回的資料與某個型別對映起來(然後發現在runtime時毛用都沒有)。

前端架構師,也有相當多的精力在這上面。

這是一個好的現狀嗎?未必,但現狀確實如此,這個鍋架構師不背誰來背?

五、小結

所謂架構,我理解是綜合考慮目標、業界和團隊,作為合理的方案選擇,既能支撐業務的發展,又能令團隊滿意。如果能達到這個目標,自然就是一個好的架構。目前來看,前端要做到一個好的架構不容易,做的事情並不比後端少。

至於說前端架構師做的所謂的這些架構的事情是否高大上,那是另一個沒有答案的問題。

相關文章