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