前端架構那些事

 　　在談前端架構以前，須要先探討一下不一樣人羣對前端產生的困惑。前端這個職業最近幾年才逐漸被承認，以前一直是低端的代名詞，因此多數高手很不屑搞這個。以前的不少項目，人們對前端這塊的要求也只是能用就行，因此不多會在上面去細緻、深刻地創建一套完善體系。而多數產品的技術經理也會是後端出身的，每每對前端的認識還停留在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： 　　http://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，這一層徹底由前端程序員控制，他就能夠在這個地方作這種合併，很是的合理。 　　除此以外，咱們經常會用到HTML模板，但使用它的最佳位置是隨着產品的場景而不一樣的，可能某個地方在前端更好，可能某個地方在後端好些。到底放在哪合適，只有前端開發人員纔會知道，若是前端開發人員不能參與一部分後端代碼的開發，優化工做也仍是作不完全。有NodeJS以後會怎樣呢，由於無論前端模板仍是後端模板，都是JavaScript的，可使用同一套庫，這樣在作調整的時候不會有代碼遷移的煩惱，直接把模板換地方便可。 　　如今，也有不少業務場景有實時通訊的需求，目前來講最合適的方案是Socket.io，它默認使用NodeJS來當服務端，這也是NodeJS的一個重要使用場景。 　　這樣，前端開發人員也部分參與了運行在服務端的代碼，他的工做範圍從原先客戶端瀏覽器，向後拓展了一個薄層，因此就有了全棧的稱呼。至於說這個稱呼還繼續擴展，一個前端開發人員從視覺到交互到靜態HTML到JavaScript包辦的狀況，這個就有些過頭了。 　　以上這些，主要解決的都是代碼層面的事情。另外有一個方面，也是須要關注，但卻經常不能引發重視的，那就是前端的工程化問題。 　　早期爲何沒有這些問題？由於那時候前端很簡單，複雜度不高，如今整個很複雜了，就帶來了不少管理問題。好比說整個系統的前端都組件化了以後，HTML會拆分紅各類模板，JavaScript會拆分紅各類模塊，而CSS也經過LESS或者SASS這種方式，變成了一種編譯式的語言。 　　這時候，咱們考慮一個所謂的組件，它就比較麻煩了。它多是一個或者多個HTML模板，加上一個或者多個JavaScript模塊，再包含CSS中的一部分構成的，而前二者均可能有依賴項，三個部分也都要避免與其餘組件的衝突。 　　這些東西都須要管理，而且提供一種比較好的方案去維護。在JavaScript被模塊化以後，也能夠經過單元測試來控制它們的質量，而且把這個過程自動化，每次版本有變動以前，保證它們最基本的正確性。最終，須要有一種自動化的發佈機制，把這幾類代碼提取，打包合併，壓縮，發佈。 　　這個主題展開能夠講不少，因此咱們不在本次分享中涉及。在我以前的幾篇文章中，也闡述過觀點。 　　目前這方面研究最深刻的是以前百度FIS團隊的張雲龍，他的幾篇文章在這裏，強烈推薦閱讀。 　　後記： 　　這篇文章是我入職蘇寧以後第一次公開分享，目標受衆主要是後端出身的技術經理，目的是讓這個羣體能有更多的前端意識。如今公司的項目基本都有前端模塊，但人員專職程度較低，水平也良莠不齊。蘇寧的戰略口號之一是提高用戶體驗，從產品角度看，用戶體驗的提高並不是是UI作幾個圖，搞一些花哨效果就能夠了，它是一個系統工程，涉及從用戶習慣調研、產品設計、前端開發、甚至後端服務等一系列環節，須要從易用度、觀感、加載性能、流暢度等各方面共同提高。 　　這些東西都須要從全局角度做規劃，從源頭控制起，不然只能是頭疼醫頭，腳痛醫腳。爲此，基礎技術中心會逐步整合幾套適合不一樣場景的基礎前端框架，做爲種子項目供從此的技術選型使用。此外，還會從前端開發的各類主題組織一些技術分享，而且逐步造成一套制度化，流程化的培訓體系。