前端架構那些事兒

在談前端架構之前,需要先探討一下不同人群對前端產生的困惑。前端這個職業最近幾年才逐漸被認可,之前一直是低端的代名詞,所以多數高手很不屑搞這個。之前的很多項目,人們對前端這塊的要求也只是能用就行,所以很少會在上面去細致、深入地建立一套完善體系。而多數產品的技術經理也會是后端出身的,往往對前端的認識還停留在Java Struts那個原始的MVC模型上,或者首先想到的就是GWT和JSF,這是從后端角度出發的一種視角。用這類思維方式做出來的產品,一般用戶體驗都不會很好。

  另一方面,從界面層上手的人群,他對用戶體驗這方面會把控得比較好,但通常缺架構意識,或者說是軟件工程的意識。在界面層比較復雜的情況下,很可能會有失控的趨勢。對整個系統結構的認知程度通常不夠深入,也缺乏設計模式等方面的知識。

  開發人員會有一些困惑:

  • 創建項目的時候,一般沒有人作前端的技術選型

  • 拿到項目之后,沒有直接可復制的基礎版本

  習慣于引用第三方組件

  • 趕功能,需要某個組件或者特效

  • 上網搜到一個合適的,加進來

  • 它還依賴一些別的庫

  • 文件大還是次要的

  • 可能會產生沖突,樣式也不一致

  開發經理也會有一些困惑:

  • 協作過程感覺有問題

  • 前端人員寫原始界面,包含靜態界面和特效

  • 開發人員接著改,加邏輯

  • 發現有問題要返工了

  • 在誰的代碼基礎上繼續改?如何合并?

  2014年了,為什么還有這么多人工環節?

  • 能自動單元測試嗎?

  • 能自動發布打包嗎?

  用戶會對這些事情感到煩惱:

  長得丑

  • 界面老土

  • 風格不一致

  速度慢

  • 加載慢

  • 渲染慢

  • 執行慢

  出錯

  架構的本質是什么?其實也是一種管理。通常我們所說的管理,都是指對于任務和人員的管理,而架構管的是機器和代碼。比如說,機器的部署屬于運維的物理架構,SOA屬于服務架構,那么,前端的架構指什么呢?

  長期以來,前端所處的位置是比較偏應用層,而且是很薄的一層,而架構又要求深度和廣度,所以之前在前端里面做架構,好比在小水塘里游泳,稍微撲騰兩下就到處碰壁。但最近這幾年來,前端的范圍被大大拓展了,所以這一層逐漸變得大有可為。

  怎樣去理解架構呢?在早期的文字MUD游戲里,有這么一句話:“你感覺哪里不對,但是又說不上來?!痹諼頤強⒑褪褂萌砑低車墓討?,或多或少會遇到這樣的感覺,有這種感覺就說明架構方面可能有些問題。

  在狹義的前端領域,架構要處理的很重要的事情是組件的集成。由于JavaScript本身缺乏命名空間這樣的機制,多數框架都傾向于自己搞一套,所以這方面的碎片化是很嚴重的。如果一個公司的實力不足以自研所有用到的組件,就會一直面臨這方面的問題。

  比如說,在做某個功能的過程中,發現需要一個組件,時間來不及做,就到網上搜了個,加到代碼里面,先運行起來再說。一不小心,等功能做完的時候,已經引入了無數種組件了,有很多代碼是重疊的,可能有的還有沖突,外觀也不一致。

  環顧四周的大型互聯網公司,基本上都有自己的前端框架,比如阿里的Kissy和Arale,騰訊的JX,百度的Tangram,360的QWrap等,為什么?因為要整合別的框架,并且在此基礎上發展適合自己的組件庫,代價非常大,初期沒辦法的時候只能湊合,長期來說,所有代碼都可控的意義非常重要。

  那么,是不是一套框架可以包打天下呢,這個真的很難。對于不同的產品形態,如果想要用一套框架去適應,有的會偏輕,有的又偏重,有的要兼容低端瀏覽器,有的又不要,很難取舍。

  常見的前端產品形態包括:

  • 內容型Web站點 側重渲染方面的優化,前端邏輯比重小

  • 操作型B/S系統 以數據和邏輯為中心,界面較規整

  • 內嵌Web的本地應用 要處理緩存和一些本地接口,包括PC客戶端和移動端

  另外有Web游戲,因為跟我們的企業形態關系不大,而且也比較獨特,所以不包含在內。這三種產品的前端框架要處理的事情顯然是不太一樣的,所以可以細分成2-3種項目模板,整理出對應的種子項目,供同類產品初始化用。

  最近我們經常在前端領域聽說兩個詞:全端、全棧。

  全端的意思是,原來的只做在瀏覽器中運行的Web程序不夠,還要做各種終端,包括iOS,Android等本地應用,甚至PC桌面應用。

  為什么廣義的前端應當包含本地應用呢?因為現在的本地應用,基于很多考慮,都變成了混合應用,也就是說,開發這個應用的技術,既包含原生的代碼,也包含了嵌入的HTML5代碼。這么一來,就造成了開發本地應用的人技能要求較廣,能夠根據產品的場景,合理選擇每個功能應當使用的技術。

  現在有一些PC端的混合應用開發技術,比如node-webkit和hex,前者的典型應用是Intel? XDK,后者的典型應用是有道詞典,此外,豌豆莢的PC客戶端也是采用類似技術的,也有一些產品是用的qt-webkit。這類技術可以方便做跨平臺,極大減少開發工作量。

  所以,我們可以看到,在很多公司,開發安卓、iOS應用的人員跟Web前端的處于同一個團隊中,這很大程度上就是考慮到這種情況。

  全棧的意思是,除了只做在瀏覽器中運行的代碼,還寫一些服務端的代碼,這個需求又是從哪里來的呢?

  這個需求其實來自優化。我們要優化一個系統的前端部分,有這么一些事情可以做:

  • HTML結構的優化,減少DOM樹的層次等等

  • CSS渲染性能的優化,批量寫入DOM變更之類

  • 資源文件的優化,比如小圖片的合并,圖像格式的處理,圖標字體的使用等

  • JavaScript邏輯的優化,??榛?,異步加載,性能優化

  • 加載字節量的優化,主要是分攤的策略

  • HTTP請求的優化

  這里面,除了前三條,其他都可能跟后端有些關系,尤其是最后一條。但是前端的人沒法去優化后端的東西,這是不同的協作環節,所以就很麻煩。

  那么,如果有了全棧,這個問題可以怎么解決呢?

  比如說,我們要做最原始的小文件合并,可以在服務器做一些配置,把多個合并成一個請求,比如天貓的某個url:

  //g.tbcdn.cn/kissy/k/1.4.1/??dom/base-min.js,event-min.js,event/dom/base-min.js,event/base-min.js,event/dom/touch-min.js,event/dom/shake-min.js,event/dom/focusin-min.js,event/custom-min.js,cookie-min.js?t=1.js

  這個就很明顯是多個文件合并而成的,9個小文件的請求,合并成了一個64k的文件請求。

  這種簡單的事情可以在靜態代理服務器上配置出來,更復雜的就比較難了,需要一定的服務端邏輯。比如說,我們有多個ajax請求,請求不同的服務,每個請求的數據量都非常少,但因為請求數很多,可能會影響加載性能,如果能把它們在服務端就合并成一個就好了。但這個優化是前端發起的,傳統模式下,他的職責范圍有限,優化不到服務端去,而這多個服務很可能是跨產品??櫚?,想要合并,放在哪個后端團隊都很怪異。

  這可真難辦,就像老虎追猴子,猴子上了樹,老虎只能在下面干瞪眼。但是如果我們能讓老虎上樹,這就不是個問題了。如果有這么一層NodeJS,這一層完全由前端程序員控制,他就可以在這個地方做這種合并,非常的合理。

  除此之外,我們常?;嵊玫紿TML模板,但使用它的最佳位置是隨著產品的場景而不同的,可能某個地方在前端更好,可能某個地方在后端好些。到底放在哪合適,只有前端開發人員才會知道,如果前端開發人員不能參與一部分后端代碼的開發,優化工作也還是做不徹底。有NodeJS之后會怎樣呢,因為不管前端模板還是后端模板,都是JavaScript的,可以使用同一套庫,這樣在做調整的時候不會有代碼遷移的煩惱,直接把模板換地方即可。

  現在,也有很多業務場景有實時通信的需求,目前來說最合適的方案是Socket.io,它默認使用NodeJS來當服務端,這也是NodeJS的一個重要使用場景。

  這樣,前端開發人員也部分參與了運行在服務端的代碼,他的工作范圍從原先客戶端瀏覽器,向后拓展了一個薄層,所以就有了全棧的稱呼。至于說這個稱呼還繼續擴展,一個前端開發人員從視覺到交互到靜態HTML到JavaScript包辦的情況,這個就有些過頭了。

  以上這些,主要解決的都是代碼層面的事情。另外有一個方面,也是需要關注,但卻常常不能引起重視的,那就是前端的工程化問題。

  早期為什么沒有這些問題?因為那時候前端很簡單,復雜度不高,現在整個很復雜了,就帶來了很多管理問題。比如說整個系統的前端都組件化了之后,HTML會拆分成各種模板,JavaScript會拆分成各種???,而CSS也通過LESS或者SASS這種方式,變成了一種編譯式的語言。

  這時候,我們考慮一個所謂的組件,它就比較麻煩了。它可能是一個或者多個HTML模板,加上一個或者多個JavaScript???,再包含CSS中的一部分構成的,而前兩者都可能有依賴項,三個部分也都要避免與其他組件的沖突。

  這些東西都需要管理,并且提供一種比較好的方案去維護。在JavaScript被??榛?,也可以通過單元測試來控制它們的質量,并且把這個過程自動化,每次版本有變更之前,保證它們最基本的正確性。最終,需要有一種自動化的發布機制,把這幾類代碼提取,打包合并,壓縮,發布。

  這個主題展開可以講很多,所以我們不在本次分享中涉及。在我之前的幾篇文章中,也闡述過觀點。

  目前這方面研究最深入的是之前百度FIS團隊的張云龍,他的幾篇文章在這里,強烈推薦閱讀。

  后記:

  這篇文章是我入職蘇寧之后第一次公開分享,目標受眾主要是后端出身的技術經理,目的是讓這個群體能有更多的前端意識。現在公司的項目基本都有前端???,但人員專職程度較低,水平也參差不齊。蘇寧的戰略口號之一是提升用戶體驗,從產品角度看,用戶體驗的提升并非是UI做幾個圖,搞一些花哨效果就可以了,它是一個系統工程,涉及從用戶習慣調研、產品設計、前端開發、甚至后端服務等一系列環節,需要從易用度、觀感、加載性能、流暢度等各方面共同提升。

  這些東西都需要從全局角度作規劃,從源頭控制起,否則只能是頭疼醫頭,腳痛醫腳。為此,基礎技術中心會逐步整合幾套適合不同場景的基礎前端框架,作為種子項目供今后的技術選型使用。此外,還會從前端開發的各種主題組織一些技術分享,并且逐步形成一套制度化,流程化的培訓體系。


來源:博客園

上一篇: 一個前端工程師眼里的NodeJS

下一篇: 深度分析HTML5在移動開發方面的發展狀況

分享到: 更多
抢庄牌九外挂 pc蛋蛋每天稳赚300元 时时彩全部历史数据 时时彩开奖结果查询 手机版三公游戏赢现金 加盟福利彩票要多少钱 内蒙古时时走势图经 技巧赌大小最科学下注 广东时时开奖软件 北京时时5分 七乐彩中奖规则图表 大乐透顺序不对算不算 七星彩计划下载 pk10免费计划软件赢客 高频彩人工计划app 精准幸运飞艇计划稳定版