前端架構(gòu)需要解決的問題

前端網(wǎng)頁就是這么簡單，除去圖片、視頻等資源外只有三部分，即標(biāo)記網(wǎng)頁元素的HTML、設(shè)置元素樣式的CSS和負責(zé)交互處理的JavaScript。

在軟件開發(fā)上，普遍認為架構(gòu)設(shè)計能把復(fù)雜的工程代碼分解成相互耦合度較低的模塊，規(guī)劃整個工程。簡單地說，在大多數(shù)人的認知里，架構(gòu)設(shè)計是為了分離代碼而存在的。更直接地說，架構(gòu)設(shè)計就是為開發(fā)人員分工而存在的。而前端網(wǎng)頁是天然按照單個網(wǎng)頁解耦的（即網(wǎng)頁與網(wǎng)頁之間是獨立的），在大多數(shù)的前端工程中，一個網(wǎng)頁的復(fù)雜度剛好適合一個人的工作量。基于這樣的認知，前端網(wǎng)頁確實是不需要架構(gòu)設(shè)計的，因為絕大多數(shù)的前端工程不存在分工的問題，每個前端工程師分幾個頁面就完事了。

而事實上，前端網(wǎng)頁的復(fù)雜度已經(jīng)逐漸超出控制。在一些稍具規(guī)模的網(wǎng)站上，需要由幾十甚至上百個頁面組成；在一些復(fù)雜的網(wǎng)頁中（如在線畫圖，在線剪輯視頻），也需要由幾十甚至上百個小模塊組成。在大型網(wǎng)站的前端工程里，如果沒有架構(gòu)設(shè)計，任由開發(fā)人員自由發(fā)揮的話，一定會出現(xiàn)代碼高度混亂和高度冗余的情況。這種情況是危險的，很大程度上會造成項目進度失控或運維成本過高等狀況。

再者，軟件架構(gòu)并不是僅僅為了分工而存在的。架構(gòu)是軟件整體結(jié)構(gòu)的抽象描述，是一個軟件的基本思想，而分工只是結(jié)構(gòu)抽象帶來的附加好處。

而基于這樣的認知，所有軟件（包括前端）都需要架構(gòu)設(shè)計。但是如果網(wǎng)站只有幾個頁面，并且沒有任何擴展需求，此時還要大費周章地去做架構(gòu)設(shè)計，就相當(dāng)于牛刀宰雞了。

因此，在具有一定規(guī)模的前端工程中，是需要架構(gòu)設(shè)計的。而前端架構(gòu)，一般需要解決4個問題來提高前端網(wǎng)頁的質(zhì)量和性能，即規(guī)整化、適配性和兼容性、模塊化、單頁應(yīng)用。

規(guī)整化概述

由于前端頁面的易學(xué)性，導(dǎo)致很多前端開發(fā)工作都是由其他軟件工程師兼職的。即使一些專職的前端工程師，有相當(dāng)一部分也沒有系統(tǒng)地學(xué)習(xí)過前端開發(fā)，所以前端代碼中會出現(xiàn)各種各樣的編寫習(xí)慣，很多代碼細節(jié)也過于粗糙，導(dǎo)致源源不斷地出現(xiàn)各種小問題。

由于前端的代碼在網(wǎng)上很容易找到，因此一些前端工程師會東找個例子，西找個例子，然后簡單地把代碼放到一起，頂多再模仿著寫幾行代碼或者在例子中修改幾個變量，這樣就算完成一個頁面了。像這樣在很多代碼細節(jié)還不清楚的情況下，直接把代碼堆到一起，看起來是很快就完成了一個頁面，但是一旦出現(xiàn)問題，便需要花很長的時間去“嘗試”出問題的位置，大部分情況下這種行為是得不償失的。

由于網(wǎng)上有很多網(wǎng)頁模板，看起來還很不錯，因此一些工程師便使用這些模板稍稍改動就算完成頁面了，導(dǎo)致整個網(wǎng)站是“色彩斑斕”“五彩繽紛”。

但是到網(wǎng)站發(fā)布前UI風(fēng)格整頓的時候，網(wǎng)頁修改的工作量和重新做一次沒什么兩樣。

由于JavaScript語法的開放性，夸張地說，100個人用JavaScript就會有100種編程語言。越大的前端工程，越多的前端工程師，前端工程也會越混亂。

以上，浮躁地忽略學(xué)習(xí)過程、隨意地抄襲代碼、偷懶地使用網(wǎng)頁模板、一人一個樣的語法使用習(xí)慣和低估了前端工程的復(fù)雜性，這些都造成了前端結(jié)構(gòu)極度混亂和代碼高度冗余的局面。雖然看上去功能是完成了，但是一旦發(fā)生Bug修正、需求變更、UI改版、交互方式變更等情況，都會出現(xiàn)工數(shù)和風(fēng)險完全不可控的局面。

很多人可能會認為，前端是天然按照單個網(wǎng)頁解耦的，混亂是可以控制在一定范圍內(nèi)的。但是，前端工程除了網(wǎng)頁標(biāo)簽以外，往往還有CSS樣式文件和JavaScript腳本文件，這些文件是可以無限制地被多個網(wǎng)頁引用的。混亂的前端結(jié)構(gòu)如圖3.16所示。

由此可知，在混亂的前端工程內(nèi)部，其實并不是天然按照單個網(wǎng)頁解耦的。所以混亂其實不能天然被控制在一定范圍內(nèi)。

圖3.16 混亂的前端工程結(jié)構(gòu)

更可怕的是，這種不好的前端編程行為會遵循破窗效應(yīng)，會感染到其他的前端工程師，甚至整個開發(fā)團隊。因此，前端架構(gòu)第一個需要做的便是規(guī)整化，制定一些規(guī)則，以達到約束整個前端開發(fā)過程的目的。

適配性和兼容性概述

首先是適配性。現(xiàn)在的顯示設(shè)備多種多樣，前端網(wǎng)頁的顯示也不僅僅局限在PC瀏覽器當(dāng)中。更多地，手機瀏覽器、某些嵌入網(wǎng)頁的App、平板電腦、電視，甚至是巨屏，都可能需要顯示前端網(wǎng)頁。這些林林總總的顯示設(shè)備，分辨率、長寬比各式各樣，交互方式也不盡相同，而前端頁面對這些設(shè)備的適應(yīng)性，就是適配性。當(dāng)然，網(wǎng)頁不需要適配所有的顯示設(shè)備，很多情況下，PC的網(wǎng)頁和手機的網(wǎng)頁都會分開實現(xiàn)。但是即使是只需要在PC瀏覽器顯示的網(wǎng)頁，也需要有一定的適配性，因為PC顯示器的分辨率不盡相同，瀏覽器的窗口也可以隨意縮放。

因此，前端架構(gòu)應(yīng)該考慮網(wǎng)頁的適配性。適配性做不好的網(wǎng)頁，很容易產(chǎn)生一些頁面錯位等用戶體驗不好的狀況，這種山寨的感覺會影響用戶對網(wǎng)站的第一印象。網(wǎng)頁需要適配的多種設(shè)備如圖3.17所示，但是在一般情況下，網(wǎng)頁不需要適配所有的設(shè)備，只需要適配選定的設(shè)備種類即可（如PC版網(wǎng)頁、移動端版網(wǎng)頁）。而對大型網(wǎng)站而言，大屏展示端不是必需的，但是PC端和移動端的適配需要充分對應(yīng)。

圖3.17 網(wǎng)頁需要適配的多種設(shè)備

其次是兼容性。除了多種多樣的顯示設(shè)備以外，瀏覽器也是各式各樣的，這些瀏覽器即使都支持HTML 5，但有些CSS樣式配置和一部分瀏覽器API也是不一樣的，而前端頁面對這些瀏覽器的適應(yīng)性，就是兼容性。目前比較流行的瀏覽器有Chrome、Firefox和Safari，當(dāng)然還有很多其他瀏覽器，它們的內(nèi)核大多數(shù)和Chrome是一樣的，所以兼容了Chrome、Firefox和Safari就相當(dāng)于兼容了所有現(xiàn)代瀏覽器。而兼容性最大的挑戰(zhàn)莫過于IE了，IE 9以下版本不支持HTML 5，IE 9、IE 10、IE 11雖然支持HTML 5，但是都不太友好。當(dāng)然了，也不是要讓網(wǎng)頁兼容所有瀏覽器，畢竟兼容瀏覽器帶來的工作量和測試量也是不小的。

因此，前端架構(gòu)也應(yīng)該考慮瀏覽器的兼容性。網(wǎng)頁需要適配的多種瀏覽器如圖3.18所示，這里忽略了一些用戶量不大或者沒有獨立瀏覽器內(nèi)核的瀏覽器，如360瀏覽器、搜狗瀏覽器、百度瀏覽器、小米瀏覽器、華為瀏覽器等。

市場上瀏覽器很多，每個瀏覽器的不同版本之間也有區(qū)別，但一般情況下，網(wǎng)頁不需要兼容所有的瀏覽器，現(xiàn)在很多網(wǎng)站都放棄IE 6～IE 10了。對于大型網(wǎng)站而言，由于用戶使用的瀏覽器不集中，所以還是要盡量兼容足夠多的瀏覽器。

圖3.18 網(wǎng)頁需要適配的多種瀏覽器

模塊化概述

在前端的開發(fā)過程中，很多時候我們是在做重復(fù)的事情。例如，A頁面需要一個播放器，B頁面也需要一個播放器；C頁面有一個視頻列表，D頁面也有一個視頻列表，如圖3.19所示。諸如此類，頁面與頁面之間，會有很多類似的，甚至相同的部分。

圖3.19 網(wǎng)頁與網(wǎng)頁間相似的部分

面對這些類似的部分，比較原始的方法是直接復(fù)制代碼。這種方法很直接，但是復(fù)制的代碼需要重新調(diào)整和重新調(diào)試。如果復(fù)制的是其他人編寫的代碼，調(diào)整時間會更長。如果需要調(diào)整所有這些復(fù)制代碼的話，這個過程將會是相當(dāng)無趣的。

現(xiàn)在，前端部分流行組件化，出現(xiàn)了如Bootstrap等前端組件工具箱，可以很簡單地畫出列表和導(dǎo)航欄，以及一系列通用的頁面組件。這些組件工具箱確實能幫助我們在UI描畫時省點力氣，但是，組件工具箱一般只是對HTML默認標(biāo)簽進行了美化或者擴充，其無法提供現(xiàn)成的業(yè)務(wù)模塊（例如圖3.19中的視頻資源列表）。

其實，我們希望的是把這些通用的業(yè)務(wù)模塊做成獨立的部分，各個網(wǎng)頁通過簡單地調(diào)用即可把這些業(yè)務(wù)模塊拼接進來，就像搭建積木一樣，如圖3.20所示。這個就是模塊化，相同部分只有一份代碼。

圖3.20 網(wǎng)頁與網(wǎng)頁間相似的部分

單頁應(yīng)用概述

傳統(tǒng)的網(wǎng)站會不斷地跳轉(zhuǎn)頁面，例如單擊搜索后會跳轉(zhuǎn)頁面，單擊翻頁后也會跳轉(zhuǎn)頁面。一旦出現(xiàn)跳轉(zhuǎn)頁面，用戶就需要等待重新加載頁面后才能繼續(xù)操作，如果在網(wǎng)絡(luò)不好的情況下，這種等待的體驗是糟糕的。為了改進這種糟糕的體驗，單頁應(yīng)用（Single Page Web Application，SPA）的概念開始流行。單頁應(yīng)用是指在瀏覽器中運行的應(yīng)用，其在使用期間不會重新加載頁面。

簡單地說，單頁應(yīng)用是把多個頁面合并成一個頁面。傳統(tǒng)網(wǎng)站與單頁應(yīng)用的對比如圖3.21所示。

更簡單地說，單頁應(yīng)用是只有一個前端頁面的網(wǎng)站，瀏覽器一開始會加載必要的HTML、CSS和JavaScript文件，之后所有的操作都會在這個頁面上完成。以翻頁操作為例，JavaScript腳本會向服務(wù)器請求翻頁所需要的數(shù)據(jù)，數(shù)據(jù)返回后，JavaScript腳本會進行DOM操作，修改頁面顯示的內(nèi)容，如圖3.22所示。因此單頁應(yīng)用只是刷新列表而不是重新跳轉(zhuǎn)頁面。

圖3.21 傳統(tǒng)網(wǎng)站與單頁應(yīng)用的對比

圖3.22 單頁應(yīng)用的翻頁操作

單頁應(yīng)用能避免頁面跳轉(zhuǎn)的發(fā)生，提高用戶體驗，但是單頁應(yīng)用也有不好的地方。由于單頁應(yīng)用是把多個網(wǎng)頁合并成單個網(wǎng)頁，所以這個網(wǎng)頁的內(nèi)容是相對龐大的，JavaScript腳本的內(nèi)容也是復(fù)雜的，導(dǎo)致了單頁應(yīng)用加載網(wǎng)頁資源的時間會比較長。如果把整個具有一定規(guī)模的網(wǎng)站做成一個單頁應(yīng)用（想達到App或者桌面軟件的效果）的話，那將會是一個很不理智的行為，因為每次打開頁面都可能要花上五六分鐘，配置差一點的機器甚至?xí)斐蔀g覽器崩潰。

因此，前端架構(gòu)不要極端地把一個網(wǎng)站做成單頁應(yīng)用，而是需要適當(dāng)?shù)厥褂脝雾搼?yīng)用，權(quán)衡哪些網(wǎng)頁需要合并成一個單頁應(yīng)用，哪些網(wǎng)頁則必須要分離，如圖3.23所示。

圖3.23 單頁應(yīng)用和多頁跳轉(zhuǎn)結(jié)合

本文給大家講解的內(nèi)容是大型網(wǎng)站架構(gòu)的技術(shù)細節(jié)：前端架構(gòu)，前端架構(gòu)需要解決的問題

下篇文章給大家講解的內(nèi)容是大型網(wǎng)站架構(gòu)的技術(shù)細節(jié)：前端架構(gòu)，規(guī)整化編碼規(guī)范，JavaScript庫，組件工具箱，框架

覺得文章不錯的朋友可以轉(zhuǎn)發(fā)此文關(guān)注小編；

感謝大家的支持！

總結(jié)

以上是生活随笔為你收集整理的跟着架构师学习大型网站架构的技术细节：前端架构需要解决的问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。