來源：轉(zhuǎn)載 發(fā)布時間：2018-11-22 14:42:30 閱讀量：1180
0、前注
鑒于作者本人的能力有限（非常有限），并且依然在學(xué)習(xí)中，因此本文的高度和深度必然有所欠缺。
歡迎（并且非常歡迎）大家來批評指正，如果能詳細(xì)的說明問題在哪里，如何解決和改正，那么就太感謝了?。?！
我最喜歡聽有理有據(jù)的批評了??！
本人QQ：20004604，郵箱：20004604@qq.com，期待你的交流。
1、為什么要有一個好的架構(gòu)
首先明確一點，架構(gòu)是為需求服務(wù)的。
前端架構(gòu)存在的目的，就我個人理解來說，有以下幾點：
1、提高代碼的可讀性。
一個好的架構(gòu)，代碼的可讀性一定是很強(qiáng)的。
簡單來說，假如有一個新人加入團(tuán)隊，那么他接手這個項目，一定是容易上手的，能簡單輕松的了解整個前端部分的相互關(guān)系，從而找到自己需要重點關(guān)注的點。而不是需要花很多時間去熟悉這個項目的很多細(xì)節(jié)，才能開始上手做東西。
就文件來說，可以從文件名上，分清哪些是頁面、哪些是邏輯、哪些是樣式、哪些是可以復(fù)用的組件、哪些是圖標(biāo)組、又有哪些是移動端或是PC端專享的樣式/邏輯等。
就代碼來說，包括統(tǒng)一的命名風(fēng)格，封裝在同一個文件里的代碼的相關(guān)性足夠強(qiáng)等。
2、提高代碼的可維護(hù)性。
一個好的架構(gòu)，一定是易于維護(hù)的，例如在新增需求、更改需求、修正bug，都不會造成意料之外的變化，比如說修改了一個頁面組件的內(nèi)容，卻導(dǎo)致另外一個頁面組件發(fā)生變化（這也太坑了）。
因此，要低耦合，高內(nèi)聚，以及輸入和輸出是可預(yù)期的。
3、提高代碼的可擴(kuò)展性。
一個好的架構(gòu)，一定擴(kuò)展性要強(qiáng)，不能寫死。
需求變更太TM正常了，新增需求也太TM正常了。因此好的架構(gòu)，必須要考慮到這些情況的發(fā)生，因為他們是一定會發(fā)生的。
所以，一定要避免把代碼寫死。
比如頁面組件A里需要有一個日歷組件，而這個日歷組件引用的是別人的（比如從github上找的）。
那么盡量不要直接在頁面組件A里面直接引用這個日歷組件，而是將寫一個日歷組件B，在這個日歷組件B里封裝你引用的日歷組件C，然后通過這個日歷組件B來進(jìn)行操作。
原因很簡單，假如某天產(chǎn)品經(jīng)理說，這個日歷組件太丑了，我們換一個吧。如果你直接在頁面組件A里內(nèi)嵌這個引用的日歷組件C，你很可能就要改很多代碼（因為不同日歷組件的使用方法和暴露的接口可能不同）。假如你還在其他多個地方引用了這個日歷組件，那就更糟糕了！每個地方都要改。
而若是將引用的日歷組件C封裝到自己寫的日歷組件B之中，那么你只需要改日歷組件B里的相應(yīng)代碼即可，而因為日歷組件B暴露的接口是不變的，那么自然不用修改頁面中的代碼了。
附圖，以日歷組件為例，是否考慮到擴(kuò)展性的結(jié)果
未考慮到擴(kuò)展性
考慮到擴(kuò)展性：
4、便于協(xié)同。
包括前端和后端的協(xié)同，前端和前端之間的協(xié)同。
具體來說，前后端的協(xié)同通常是以ajax為交互，那么應(yīng)至少有一個用于專門封裝了所有ajax請求的文件，所有ajax請求都封裝在這里。在開發(fā)時，這里封裝的方法應(yīng)該可以模擬發(fā)送和接收約定好的交互內(nèi)容，方便開發(fā)聯(lián)調(diào)。
而前端和前端的協(xié)同，主要體現(xiàn)在同時在更改代碼時，不會影響對方代碼的正常運行。因此要求封裝、解耦以及低干擾度是必須的。
5、自動化
自動打包，壓縮，混淆，如果有必要，再加上自動單元測試。
總結(jié)：
總結(jié)來說，一個好的架構(gòu)的目的是，讓前端寫代碼寫的舒服，讓后端聯(lián)調(diào)的舒服，讓產(chǎn)品經(jīng)理改需求改的舒服。
2、我如何設(shè)計架構(gòu)
我不敢說自己的架構(gòu)是好的架構(gòu)（顯然不是啦），只能分享自己最近做的一個項目，它的架構(gòu)的如何做的。
首先，確定需求：
1、一個中小型網(wǎng)站，同時面向移動端和PC端（單端大概15個頁面，算上彈窗大約20個）。
2、預(yù)算有限（給的錢少），開發(fā)時間有限（一個月）。
3、可能存在一定程度上的需求變更（比如增加頁面或修改某些頁面內(nèi)容）。
4、客戶可能不太在乎優(yōu)化（但是我自己在乎啊?。?/span>
5、要求兼容IE9以上。
其次開始決定：
1、兼容IE9以上說明可以使用主流框架，而無需必須使用jquery。因此我采用了vue，版本是2.0；
2、預(yù)算有限，時間有限，因此PC端和移動端共html和js，獨立css。
3、頁面有限，因此無需將架構(gòu)層級劃分的比較細(xì)，只需要按其類型劃分即可；
4、根據(jù)原型圖來看，頁面復(fù)雜程度有限，復(fù)用部分不是很多，因此可以確定哪些東西需要封裝復(fù)用，哪些比較復(fù)雜需要獨立封裝，哪些比較簡單為了簡化開發(fā)難度可以直接耦合。
5、自己比較熟練單頁面網(wǎng)站，因此采用以單頁面為主，異步加載其他頁面的形式。
于是使用相關(guān)配套的東西，比如webpack，vue-router等，另外為了開發(fā)和生產(chǎn)的方便性，采用以下模式進(jìn)行開發(fā)。
第三，劃分功能。
首先有一個根html，用戶需要通過訪問它來加載我們的js邏輯，因此js邏輯的代碼被寫在main.js之中。
在main.js之下，我們的前端代碼可以被劃分為三部分：
組件樹；
功能模塊；
各種資源；
如下圖：
功能劃分好之后，相同功能的放在同一個文件夾下，命名風(fēng)格應(yīng)該類似。
具體來說，組件樹相關(guān)的東西，通常是以.vue結(jié)尾，放置在components文件夾下；
資源，有圖片或者國際化資源等，以.png或者.js或.json結(jié)尾，放置在resources文件夾下；
而功能插件、服務(wù)等，因為可能被多處引用，因此為了方便引用，放在src文件夾下，并且該文件夾是components文件夾和resources文件夾的上級文件夾；
第四、細(xì)化功能模塊
功能、組件樹以及資源，我們已經(jīng)明確了有哪些東西，那么接下來，我們要明確這些東西該如何以文件的形式來劃分。
如下圖：
1、項目構(gòu)建相關(guān)
因為要使用vue.js，也要使用es6語法，因此babel是必須的；
又因為要自動化混淆打包，因此webpack也是必須的；
最后因為要方便多人協(xié)同，因此npm的package.json的配置，方便不同人可以快速自動化通過npm install來安裝依賴，也是必須的；
2、CDN相關(guān)
而又因為我們要采用外部字體（需求要求引入非常見字體），因此CDN加速是必須的，該字體文件放在html中來配置引用即可；
3、配置和插件
我們需要直接引入一些插件和配置文件；
為了使用vue，我們需要一個根組件，那么就是App.vue；
使用vue-router，我們需要配置路由文件，因此router-config.js這個路由配置也是必須的；
然后我們還需要以插件形式引入一些功能和服務(wù)，因此有了Plugin-開頭的若干個vue插件，這些都是根據(jù)需要封裝好的低耦合高內(nèi)聚方法；
4、需要的npm依賴
當(dāng)然，要使用vue肯定要引入vue.js；
類似的還有vue-router.js和各種兼容性polyfill和全局插件；
5、抽離出的功能模塊
除了直接引用的這些插件，我們還有一些和項目高度耦合的功能服務(wù)，我認(rèn)為不能作為插件，但依然需要抽離出來封裝好，方便使用和修改；
如封裝ajax請求的ajax.js，所有的ajax請求都放置其中，只對外暴露接口，方便管理和使用；
又如實時國際化功能的組件LanguageManager.js，他需要引入國際化資源和管理國際化資源的加載；
又例如實現(xiàn)跨組件通信的event-bus.js
又比如管理用戶信息的user.js
6、總結(jié)
而這些劃分，都體現(xiàn)在上圖之中。這就是src目錄下的功能模塊文件，我們需要的絕大多數(shù)功能都可以包括在其中，我們只需要按照實際開發(fā)中的需要，將對應(yīng)的功能寫入在這些文件中并引用即可；
第五、組件樹
之前談了功能模塊的劃分，接下來是組件樹；
因此是中小型頁面，因此組件樹的層級無需太深，但該抽離出來的依然還是要抽離，盡量保證抽離出來的組件解耦以及一個頁面組件的邏輯不要太多；
如下圖：
0、根組件
所有組件最終往上找，都會找到共同的根組件App.vue，根組件只負(fù)責(zé)管理他的直接子組件；
每個組件都只負(fù)責(zé)管理自己的直接子組件，不跨級管理，并且不依賴于自己的子組件（否則可能因為子組件的未加載或錯誤而導(dǎo)致父組件錯誤），做到解耦和內(nèi)聚；
1、彈窗dialog和彈窗tips
因為彈窗dialog和彈窗提示tips可能同時存在，因此將其劃分為2個組件，方便管理；
2、未登錄頁面和登錄頁面
因為頁面存在登錄和未登錄狀態(tài)，而為了加載速度考慮，當(dāng)未登錄時，不加載已登錄頁面，因此需要劃分出來，并進(jìn)行異步加載處理；
3、未登錄頁面
未登錄頁面又分為三種情況：
1、初始頁面：毫無疑問要直接加載
2、登錄彈窗：點擊登錄時加載（異步）
3、注冊彈窗：點擊注冊時加載（異步）
之所以分拆開，是因為根據(jù)需求，已登錄用戶刷新頁面，可以直接進(jìn)入登錄后頁面，因此無需登錄和注冊，這種處理可以減少流量消耗，提升加載頁面加載速度（特別是注冊彈窗需要加載的內(nèi)容還比較多）；
4、已登錄頁面
已登錄頁面有較多頁面，采用默認(rèn)加載初始頁，然后異步加載其他頁面（訪問時）；
5、彈窗dialog
由于邏輯較少，代碼量不多，因此為了方便管理，統(tǒng)一將其合并在一個vue文件中，共同相同的打開邏輯，根據(jù)傳遞的key決定打開哪一個。
這樣在新增彈窗時，無需再去寫彈窗的打開、關(guān)閉邏輯。
假如有較復(fù)雜的彈窗，可以以子組件的形式引入到當(dāng)前vue文件中，如此也方便管理；
6、國際化管理
和頁面高耦合，負(fù)責(zé)加載對應(yīng)的國際化資源，并進(jìn)行切換管理；
7、頁面組件
可能有子頁面和復(fù)用的組件，按照正常方式引用即可。
8、樣式文件
可以獨立寫為.css文件，但因為我的公共樣式文件比較少，因此我還是將其放在一個.vue文件中，并在App.vue里來引用
8、頁面組件起名
通常以.vue為結(jié)尾，除了國際化LanguageManager.js因為高耦合度，因此以.js結(jié)尾并是一個單獨的vue實例，表示他更像是一個功能模塊，而不是一個vue的頁面組件；
基礎(chǔ)頁面，如登錄和未登錄頁面，公共組件（并且是header和footer這種），以base-開頭；
彈窗統(tǒng)一以box-為開頭；
可復(fù)用的組件以extend-開頭；
引入的外部組件以import-開頭；
普通頁面組件以page-開頭（這些頁面往往是一個獨立的頁面，并且掛靠在登錄或未登錄頁面下）；
注冊彈窗因為邏輯比較復(fù)雜，并且同類較多，因此以register-為開頭；
通過以文件名來劃分，不同的頁面組件之間的區(qū)分可以說是一目了然，同時也方便管理；
3、還沒有談到的內(nèi)容
想了想，目前還沒有談到的內(nèi)容有以下幾點：
1、路由：
以路由為驅(qū)動來寫頁面，似乎是一種不錯的選擇；
好處是只需要通過查看路由的配置文件router-config.js，就可以了解頁面組件的架構(gòu)；
不過我自己關(guān)于vue-router的實踐經(jīng)驗比較少，因此就略過不談了；
2、單元測試：
按道理說，單元測試是非常有必要的，因此在進(jìn)行架構(gòu)設(shè)計時，必須考慮到這一點；
不過作者我目前在的公司關(guān)于前端方面都不太正規(guī)，實在沒這方面的經(jīng)驗，
又因為作者我本人轉(zhuǎn)行做前端的時間也比較短，雖然周周9.12.7，但也沒來得及學(xué)習(xí)這方面的知識（沒有需求驅(qū)動，這方面動力不足哈哈），
所以只能望有這方面經(jīng)驗的同學(xué)，愿意和我交流一下這方面的知識，先謝謝啦。我的QQ是：20004604，郵箱是：20004604@qq.com
3、自動化配置：
關(guān)于webpack的自動化，是前端架構(gòu)的重要組成部分，因此配置也是蠻重要的；
不過一是這方面需要很多筆墨的，二是網(wǎng)上也有一些別人分享的文章（肯定比我的好），所以我這里就不細(xì)說了；
4、一些自動化工具：
依然尷尬，沒有大廠經(jīng)驗，路子比較野，所以大廠專有的一些工具是木有的，
而自己找的話又嫌麻煩，所以沒有優(yōu)化到極致，只做到了基本滿足目前項目需求的程度，見諒見諒；
等以后有這方面經(jīng)驗的話我再寫博客來分享吧~
---------------------
13450931319
微信登錄
QQ登錄
微博登錄
售前咨詢
