前端架构
在談前端架構之前，需要先探討一下不同人群對前端產生的困惑。前端這個職業最近幾年才逐漸被認可，之前一直是低端的代名詞，所以多數高手很不屑搞這個。之前的很多項目，人們對前端這塊的要求也只是能用就行，所以很少會在上面去細致、深入地建立一套完善體系。而多數產品的技術經理也會是后端出身的，往往對前端的認識還停留在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做幾個圖，搞一些花哨效果就可以了，它是一個系統工程，涉及從用戶習慣調研、產品設計、前端開發、甚至后端服務等一系列環節，需要從易用度、觀感、加載性能、流暢度等各方面共同提升。
這些東西都需要從全局角度作規劃，從源頭控制起，否則只能是頭疼醫頭，腳痛醫腳。為此，基礎技術中心會逐步整合幾套適合不同場景的基礎前端框架，作為種子項目供今后的技術選型使用。此外，還會從前端開發的各種主題組織一些技術分享，并且逐步形成一套制度化，流程化的培訓體系。
總結
- 上一篇： 北京话姆们是什么意思
- 下一篇： 小班教案《冻冰花》反思