中小型項目前端架構

1、.wd.wd.wd.中小型工程前端架構一、為什么要有一個好的架構首先明確一點，架構是為需求服務的。前端架構存在的目的，就我個人理解來說，有以下幾點：1. 提高代碼的可讀性一個好的架構，代碼的可讀性一定是很強的。簡單來說，假設有一個新人參加團隊，那么他接手這個工程，一定是容易上手的，能簡單輕松的了解整個前端局部的相互關系，從而找到自己需要重點關注的點。而不是需要花很多時間去熟悉這個工程的很多細節(jié)，才能開場上手做東西。就文件來說，可以從文件名上，分清哪些是頁面、哪些是邏輯、哪些是樣式、哪些是可以復用的組件、哪些是圖標組、又有哪些是移動端或是PC端專享的樣式/邏輯等。就代碼來說，包括統(tǒng)一的命名風格，

2、封裝在同一個文件里的代碼的相關性足夠強等。2. 提高代碼的可維護性一個好的架構，一定是易于維護的，例如在新增需求、更改需求、修正bug，都不會造成意料之外的變化，比方說修改了一個頁面組件的內容，卻導致另外一個頁面組件發(fā)生變化這也太坑了。因此，要低耦合，高內聚，以及輸入和輸出是可預期的。3. 提高代碼的可擴展性一個好的架構，一定擴展性要強，不能寫死。需求變更太TM正常了，新增需求也太TM正常了。因此好的架構，必須要考慮到這些情況的發(fā)生，因為這些是一定會發(fā)生的。所以，一定要防止把代碼寫死。比方頁面組件A里需要有一個日歷組件，而這個日歷組件引用的是別人的比方從github上找的。那么盡量不要直接在頁

3、面組件A里面直接引用這個日歷組件，而是將寫一個日歷組件B，在這個日歷組件B里封裝你引用的日歷組件C，然后通過這個日歷組件B來進展操作。原因很簡單，假設某天產(chǎn)品經(jīng)理說，這個日歷組件太丑了，我們換一個吧。如果你直接在頁面組件A里內嵌這個引用的日歷組件C，你很可能就要改很多代碼因為不同日歷組件的使用方法和暴露的接口可能不同。假設你還在其他多個地方引用了這個日歷組件，那就更糟糕了！每個地方都要改。而假設是將引用的日歷組件C封裝到自己寫的日歷組件B之中，那么你只需要改日歷組件B里的相應代碼即可，而因為日歷組件B暴露的接口是不變的，那么自然不用修改頁面中的代碼了。附圖，以日歷組件為例，是否考慮到擴展性的結

4、果未考慮到擴展性：考慮到擴展性：4. 便于協(xié)同包括前端和后端的協(xié)同，前端和前端之間的協(xié)同。具體來說，前后端的協(xié)同通常是以ajax為交互，那么應至少有一個用于專門封裝了所有ajax請求的文件，所有ajax請求都封裝在這里。在開發(fā)時，這里封裝的方法應該可以模擬發(fā)送和接收約定好的交互內容，方便開發(fā)聯(lián)調。而前端和前端的協(xié)同，主要表達在同時在更改代碼時，不會影響對方代碼的正常運行。因此要求封裝、解耦以及低干擾度是必須的。5. 自動化自動打包，壓縮，混淆，如果有必要，再加上自動單元測試?？偨Y：總結來說，一個好的架構的目的是，讓前端寫代碼寫的舒服，讓后端聯(lián)調的舒服，讓產(chǎn)品經(jīng)理改需求改的舒服。二、我如何設計架

5、構我不敢說自己的架構是好的架構顯然不是啦，只能分享自己最近做的一個工程，它的架構的如何做的。首先，確定需求：1、一個中小型網(wǎng)站，同時面向移動端和PC端單端大概15個頁面，算上彈窗大約20個；2、預算有限給的錢少，開發(fā)時間有限一個月；3、可能存在一定程度上的需求變更比方增加頁面或修改某些頁面內容；4、客戶可能不太在乎優(yōu)化但是我自己在乎??；5、要求兼容IE9以上。其次開場決定：1、兼容IE9以上說明可以使用主流框架，而無需必須使用jQuery。因此我采用了vue，版本是2.0；2、預算有限，時間有限，因此PC端和移動端共html和js，獨立css；3、頁面有限，因此無需將架構層級劃分的比較細，只需

6、要按其類型劃分即可；4、根據(jù)原型圖來看，頁面復雜程度有限，復用局部不是很多，因此可以確定哪些東西需要封裝復用，哪些比較復雜需要獨立封裝，哪些比較簡單為了簡化開發(fā)難度可以直接耦合；5、自己比較熟練單頁面網(wǎng)站，因此采用以單頁面為主，異步加載其他頁面的形式。于是使用相關配套的東西，比方webpack，vue-router等，另外為了開發(fā)和生產(chǎn)的方便性，采用以下模式進展開發(fā)。第三，劃分功能：首先有一個根html，用戶需要通過訪問它來加載我們的js邏輯，因此js邏輯的代碼被寫在main.js之中。在main.js之下，我們的前端代碼可以被劃分為三局部：組件樹功能模塊各種資源如以以下圖：功能劃分好之后，一

7、樣功能的放在同一個文件夾下，命名風格應該類似。具體來說，組件樹相關的東西，通常是以.vue結尾，放置在components文件夾下；資源，有圖片或者國際化資源等，以.png或者.js或.json結尾，放置在resources文件夾下；而功能插件、服務等，因為可能被多處引用，因此為了方便引用，放在src文件夾下，并且該文件夾是components文件夾和resources文件夾的上級文件夾。第四，細化功能模塊：功能、組件樹以及資源，我們已經(jīng)明確了有哪些東西，那么接下來，我們要明確這些東西該如何以文件的形式來劃分。如以以下圖：1. 工程構建相關因為要使用vue.js，也要使用es6語法，因此bab

8、el是必須的；又因為要自動化混淆打包，因此webpack也是必須的；最后因為要方便多人協(xié)同，因此npm的package.json的配置，方便不同人可以快速自動化通過npm install來安裝依賴，也是必須的。2. CDN相關而又因為我們要采用外部字體需求要求引入非常見字體，因此CDN加速是必須的，該字體文件放在html中來配置引用即可。3. 配置和插件我們需要直接引入一些插件和配置文件；為了使用vue，我們需要一個根組件，那么就是App.vue；使用vue-router，我們需要配置路由文件，因此router-config.js這個路由配置也是必須的；然后我們還需要以插件形式引入一些功能和服

9、務，因此有了Plugin-開頭的假設干個vue插件，這些都是根據(jù)需要封裝好的低耦合高內聚方法；4. 需要的npm依賴當然，要使用vue肯定要引入vue.js，類似的還有vue-router.js和各種兼容性polyfill和全局插件。5. 抽離出的功能模塊除了直接引用的這些插件，我們還有一些和工程高度耦合的功能服務，我認為不能作為插件，但依然需要抽離出來封裝好，方便使用和修改；如封裝ajax請求的ajax.js，所有的ajax請求都放置其中，只對外暴露接口，方便管理和使用；又如實時國際化功能的組件LanguageManager.js，他需要引入國際化資源和管理國際化資源的加載；又例如實現(xiàn)跨組件

10、通信的event-bus.js；又比方管理用戶信息的user.js?？偨Y：而這些劃分，都表達在上圖之中。這就是src目錄下的功能模塊文件，我們需要的絕大多數(shù)功能都可以包括在其中，我們只需要按照實際開發(fā)中的需要，將對應的功能寫入在這些文件中并引用即可。第五，組件樹：之前談了功能模塊的劃分，接下來是組件樹。因為是中小型頁面，因此組件樹的層級無需太深，但該抽離出來的依然還是要抽離，盡量保證抽離出來的組件解耦以及一個頁面組件的邏輯不要太多。如以以下圖：0. 根組件所有組件最終往上找，都會找到共同的根組件App.vue，根組件只負責管理他的直接子組件。每個組件都只負責管理自己的直接子組件，不跨級管理，并

11、且不依賴于自己的子組件否那么可能因為子組件的未加載或錯誤而導致父組件錯誤，做到解耦和內聚。1. 彈窗dialog和彈窗tips因為彈窗dialog和彈窗提示tips可能同時存在，因此將其劃分為2個組件，方便管理。2. 未登錄頁面和登錄頁面因為頁面存在登錄和未登錄狀態(tài)，而為了加載速度考慮，當未登錄時，不加載已登錄頁面，因此需要劃分出來，并進展異步加載處理。3. 未登錄頁面未登錄頁面又分為三種情況：初始頁面：毫無疑問要直接加載登錄彈窗：點擊登錄時加載異步注冊彈窗：點擊注冊時加載異步之所以分拆開，是因為根據(jù)需求，已登錄用戶刷新頁面，可以直接進入登錄后頁面，因此無需登錄和注冊，這種處理可以減少流量消耗

12、，提升加載頁面加載速度特別是注冊彈窗需要加載的內容還比較多。4. 已登錄頁面已登錄頁面有較多頁面，采用默認加載初始頁，然后異步加載其他頁面訪問時。5. 彈窗dialog由于邏輯較少，代碼量不多，因此為了方便管理，統(tǒng)一將其合并在一個vue文件中，共同一樣的翻開邏輯，根據(jù)傳遞的key決定翻開哪一個。這樣在新增彈窗時，無需再去寫彈窗的翻開、關閉邏輯。假設有較復雜的彈窗，可以以子組件的形式引入到當前vue文件中，如此也方便管理；6. 國際化管理和頁面高耦合，負責加載對應的國際化資源，并進展切換管理。7. 頁面組件可能有子頁面和復用的組件，按照正常方式引用即可。8. 樣式文件可以獨立寫為.css文件，但因為我的公共樣式文件比較少，因此我還是將其放在一個.vue文件中，并在App.vue里來引用。9. 頁面組件起名通常以.vue為結尾，除了國際化LanguageManager.js因為高耦合度，因此以.js結尾并是一個單獨的vue實例，表示他更像是一個功能模塊，而不是一個vue的頁面組件；根基頁面，如登錄和未登錄