|
|
在談前端架構(gòu)之前，需要先探討一下不同人群對前端產(chǎn)生的困惑。前端這個職業(yè)最近幾年才逐漸被認(rèn)可，之前一直是低端的代名詞，所以多數(shù)高手很不屑搞這個。之前的很多項目，人們對前端這塊的要求也只是能用就行，所以很少會在上面去細(xì)致、深入地建立一套完善體系。而多數(shù)產(chǎn)品的技術(shù)經(jīng)理也會是后端出身的，往往對前端的認(rèn)識還停留在Java Struts那個原始的MVC模型上，或者首先想到的就是GWT和JSF，這是從后端角度出發(fā)的一種視角。用這類思維方式做出來的產(chǎn)品，一般用戶體驗(yàn)都不會很好。
另一方面，從界面層上手的人群，他對用戶體驗(yàn)這方面會把控得比較好，但通常缺架構(gòu)意識，或者說是軟件工程的意識。在界面層比較復(fù)雜的情況下，很可能會有失控的趨勢。對整個系統(tǒng)結(jié)構(gòu)的認(rèn)知程度通常不夠深入，也缺乏設(shè)計模式等方面的知識。
開發(fā)人員會有一些困惑：
創(chuàng)建項目的時候，一般沒有人作前端的技術(shù)選型
- 拿到項目之后，沒有直接可復(fù)制的基礎(chǔ)版本
習(xí)慣于引用第三方組件
- 趕功能，需要某個組件或者特效
- 上網(wǎng)搜到一個合適的，加進(jìn)來
- 它還依賴一些別的庫
- 文件大還是次要的
- 可能會產(chǎn)生沖突，樣式也不一致
開發(fā)經(jīng)理也會有一些困惑：
協(xié)作過程感覺有問題
- 前端人員寫原始界面，包含靜態(tài)界面和特效
- 開發(fā)人員接著改，加邏輯
- 發(fā)現(xiàn)有問題要返工了
- 在誰的代碼基礎(chǔ)上繼續(xù)改？如何合并？
2014年了，為什么還有這么多人工環(huán)節(jié)？
- 能自動單元測試嗎？
- 能自動發(fā)布打包嗎？
用戶會對這些事情感到煩惱：
長得丑
- 界面老土
- 風(fēng)格不一致
速度慢
- 加載慢
- 渲染慢
- 執(zhí)行慢
出錯
架構(gòu)的本質(zhì)是什么？其實(shí)也是一種管理。通常我們所說的管理，都是指對于任務(wù)和人員的管理，而架構(gòu)管的是機(jī)器和代碼。比如說，機(jī)器的部署屬于運(yùn)維的物理架構(gòu)，SOA屬于服務(wù)架構(gòu)，那么，前端的架構(gòu)指什么呢？
長期以來，前端所處的位置是比較偏應(yīng)用層，而且是很薄的一層，而架構(gòu)又要求深度和廣度，所以之前在前端里面做架構(gòu)，好比在小水塘里游泳，稍微撲騰兩下就到處碰壁。但最近這幾年來，前端的范圍被大大拓展了，所以這一層逐漸變得大有可為。
怎樣去理解架構(gòu)呢？在早期的文字MUD游戲里，有這么一句話：“你感覺哪里不對，但是又說不上來。”在我們開發(fā)和使用軟件系統(tǒng)的過程中，或多或少會遇到這樣的感覺，有這種感覺就說明架構(gòu)方面可能有些問題。
在狹義的前端領(lǐng)域，架構(gòu)要處理的很重要的事情是組件的集成。由于JavaScript本身缺乏命名空間這樣的機(jī)制，多數(shù)框架都傾向于自己搞一套，所以這方面的碎片化是很嚴(yán)重的。如果一個公司的實(shí)力不足以自研所有用到的組件，就會一直面臨這方面的問題。
比如說，在做某個功能的過程中，發(fā)現(xiàn)需要一個組件，時間來不及做，就到網(wǎng)上搜了個，加到代碼里面，先運(yùn)行起來再說。一不小心，等功能做完的時候，已經(jīng)引入了無數(shù)種組件了，有很多代碼是重疊的，可能有的還有沖突，外觀也不一致。
環(huán)顧四周的大型互聯(lián)網(wǎng)公司，基本上都有自己的前端框架，比如阿里的Kissy和Arale，騰訊的JX，百度的Tangram，360的QWrap等，為什么？因?yàn)橐蟿e的框架，并且在此基礎(chǔ)上發(fā)展適合自己的組件庫，代價非常大，初期沒辦法的時候只能湊合，長期來說，所有代碼都可控的意義非常重要。
那么，是不是一套框架可以包打天下呢，這個真的很難。對于不同的產(chǎn)品形態(tài)，如果想要用一套框架去適應(yīng)，有的會偏輕，有的又偏重，有的要兼容低端瀏覽器，有的又不要，很難取舍。
常見的前端產(chǎn)品形態(tài)包括：
- 內(nèi)容型Web站點(diǎn) 側(cè)重渲染方面的優(yōu)化，前端邏輯比重小
- 操作型B/S系統(tǒng) 以數(shù)據(jù)和邏輯為中心，界面較規(guī)整
- 內(nèi)嵌Web的本地應(yīng)用 要處理緩存和一些本地接口，包括PC客戶端和移動端
另外有Web游戲，因?yàn)楦覀兊钠髽I(yè)形態(tài)關(guān)系不大，而且也比較獨(dú)特，所以不包含在內(nèi)。這三種產(chǎn)品的前端框架要處理的事情顯然是不太一樣的，所以可以細(xì)分成2-3種項目模板，整理出對應(yīng)的種子項目，供同類產(chǎn)品初始化用。
最近我們經(jīng)常在前端領(lǐng)域聽說兩個詞：全端、全棧。
全端的意思是，原來的只做在瀏覽器中運(yùn)行的Web程序不夠，還要做各種終端，包括ios，Android等本地應(yīng)用，甚至PC桌面應(yīng)用。
為什么廣義的前端應(yīng)當(dāng)包含本地應(yīng)用呢？因?yàn)楝F(xiàn)在的本地應(yīng)用，基于很多考慮，都變成了混合應(yīng)用，也就是說，開發(fā)這個應(yīng)用的技術(shù)，既包含原生的代碼，也包含了嵌入的HTML5代碼。這么一來，就造成了開發(fā)本地應(yīng)用的人技能要求較廣，能夠根據(jù)產(chǎn)品的場景，合理選擇每個功能應(yīng)當(dāng)使用的技術(shù)。
現(xiàn)在有一些PC端的混合應(yīng)用開發(fā)技術(shù)，比如node-webkit和hex，前者的典型應(yīng)用是Intel® XDK，后者的典型應(yīng)用是有道詞典，此外，豌豆莢的PC客戶端也是采用類似技術(shù)的，也有一些產(chǎn)品是用的qt-webkit。這類技術(shù)可以方便做跨平臺，極大減少開發(fā)工作量。
所以，我們可以看到，在很多公司，開發(fā)安卓、ios應(yīng)用的人員跟Web前端的處于同一個團(tuán)隊中，這很大程度上就是考慮到這種情況。
全棧的意思是，除了只做在瀏覽器中運(yùn)行的代碼，還寫一些服務(wù)端的代碼，這個需求又是從哪里來的呢？
這個需求其實(shí)來自優(yōu)化。我們要優(yōu)化一個系統(tǒng)的前端部分，有這么一些事情可以做：
- HTML結(jié)構(gòu)的優(yōu)化，減少DOM樹的層次等等
- CSS渲染性能的優(yōu)化，批量寫入DOM變更之類
- 資源文件的優(yōu)化，比如小圖片的合并，圖像格式的處理，圖標(biāo)字體的使用等
- JavaScript邏輯的優(yōu)化，模塊化，異步加載，性能優(yōu)化
- 加載字節(jié)量的優(yōu)化，主要是分?jǐn)偟牟呗?/li>
- HTTP請求的優(yōu)化
這里面，除了前三條，其他都可能跟后端有些關(guān)系，尤其是最后一條。但是前端的人沒法去優(yōu)化后端的東西，這是不同的協(xié)作環(huán)節(jié)，所以就很麻煩。
那么，如果有了全棧，這個問題可以怎么解決呢？
比如說，我們要做最原始的小文件合并，可以在服務(wù)器做一些配置，把多個合并成一個請求，比如天貓的某個url：
這個就很明顯是多個文件合并而成的，9個小文件的請求，合并成了一個64k的文件請求。
這種簡單的事情可以在靜態(tài)代理服務(wù)器上配置出來，更復(fù)雜的就比較難了，需要一定的服務(wù)端邏輯。比如說，我們有多個ajax請求，請求不同的服務(wù)，每個請求的數(shù)據(jù)量都非常少，但因?yàn)檎埱髷?shù)很多，可能會影響加載性能，如果能把它們在服務(wù)端就合并成一個就好了。但這個優(yōu)化是前端發(fā)起的，傳統(tǒng)模式下，他的職責(zé)范圍有限，優(yōu)化不到服務(wù)端去，而這多個服務(wù)很可能是跨產(chǎn)品模塊的，想要合并，放在哪個后端團(tuán)隊都很怪異。
這可真難辦，就像老虎追猴子，猴子上了樹，老虎只能在下面干瞪眼。但是如果我們能讓老虎上樹，這就不是個問題了。如果有這么一層NodeJS，這一層完全由前端程序員控制，他就可以在這個地方做這種合并，非常的合理。
除此之外，我們常常會用到HTML模板，但使用它的最佳位置是隨著產(chǎn)品的場景而不同的，可能某個地方在前端更好，可能某個地方在后端好些。到底放在哪合適，只有前端開發(fā)人員才會知道，如果前端開發(fā)人員不能參與一部分后端代碼的開發(fā)，優(yōu)化工作也還是做不徹底。有NodeJS之后會怎樣呢，因?yàn)椴还芮岸四０暹€是后端模板，都是JavaScript的，可以使用同一套庫，這樣在做調(diào)整的時候不會有代碼遷移的煩惱，直接把模板換地方即可。
現(xiàn)在，也有很多業(yè)務(wù)場景有實(shí)時通信的需求，目前來說最合適的方案是Socket.io，它默認(rèn)使用NodeJS來當(dāng)服務(wù)端，這也是NodeJS的一個重要使用場景。
這樣，前端開發(fā)人員也部分參與了運(yùn)行在服務(wù)端的代碼，他的工作范圍從原先客戶端瀏覽器，向后拓展了一個薄層，所以就有了全棧的稱呼。至于說這個稱呼還繼續(xù)擴(kuò)展，一個前端開發(fā)人員從視覺到交互到靜態(tài)HTML到JavaScript包辦的情況，這個就有些過頭了。
以上這些，主要解決的都是代碼層面的事情。另外有一個方面，也是需要關(guān)注，但卻常常不能引起重視的，那就是前端的工程化問題。
早期為什么沒有這些問題？因?yàn)槟菚r候前端很簡單，復(fù)雜度不高，現(xiàn)在整個很復(fù)雜了，就帶來了很多管理問題。比如說整個系統(tǒng)的前端都組件化了之后，HTML會拆分成各種模板，JavaScript會拆分成各種模塊，而CSS也通過LESS或者SASS這種方式，變成了一種編譯式的語言。
這時候，我們考慮一個所謂的組件，它就比較麻煩了。它可能是一個或者多個HTML模板，加上一個或者多個JavaScript模塊，再包含CSS中的一部分構(gòu)成的，而前兩者都可能有依賴項，三個部分也都要避免與其他組件的沖突。
這些東西都需要管理，并且提供一種比較好的方案去維護(hù)。在JavaScript被模塊化之后，也可以通過單元測試來控制它們的質(zhì)量，并且把這個過程自動化，每次版本有變更之前，保證它們最基本的正確性。最終，需要有一種自動化的發(fā)布機(jī)制，把這幾類代碼提取，打包合并，壓縮，發(fā)布。
這個主題展開可以講很多，所以我們不在本次分享中涉及。在我之前的幾篇文章中，也闡述過觀點(diǎn)。
目前這方面研究最深入的是之前百度FIS團(tuán)隊的張云龍，他的幾篇文章在這里，強(qiáng)烈推薦閱讀。
后記：
這篇文章是我入職蘇寧之后第一次公開分享，目標(biāo)受眾主要是后端出身的技術(shù)經(jīng)理，目的是讓這個群體能有更多的前端意識。現(xiàn)在公司的項目基本都有前端模塊，但人員專職程度較低，水平也參差不齊。蘇寧的戰(zhàn)略口號之一是提升用戶體驗(yàn)，從產(chǎn)品角度看，用戶體驗(yàn)的提升并非是UI做幾個圖，搞一些花哨效果就可以了，它是一個系統(tǒng)工程，涉及從用戶習(xí)慣調(diào)研、產(chǎn)品設(shè)計、前端開發(fā)、甚至后端服務(wù)等一系列環(huán)節(jié)，需要從易用度、觀感、加載性能、流暢度等各方面共同提升。
這些東西都需要從全局角度作規(guī)劃，從源頭控制起，否則只能是頭疼醫(yī)頭，腳痛醫(yī)腳。為此，基礎(chǔ)技術(shù)中心會逐步整合幾套適合不同場景的基礎(chǔ)前端框架，作為種子項目供今后的技術(shù)選型使用。此外，還會從前端開發(fā)的各種主題組織一些技術(shù)分享，并且逐步形成一套制度化，流程化的培訓(xùn)體系。
it知識庫：前端架構(gòu)那些事兒，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
