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