前端進階（2） - 目錄結構優化

時間 2019-11-05

原文原文鏈接

目錄結構優化

如今前端項目愈來愈變得像大型工程了，並且愈來愈複雜了，須要處理好組員之間的協做，也須要作好業務分塊、去耦合來下降維護成本，而且還要保持高效率開發。css

工程目錄結構的優化是能達到這個目的的一種方式。通常而言，不是多頁面工程仍是單頁面應用，抑或兩者都有，目錄結構都是如下兩種方式：html

類型分組（按文件類型、業務類型等進行分組）
模塊分塊（按頁面模塊、業務模塊等進行分塊）

1. 類型分組

這種方式是以文件類型、業務類型或其餘類型進行分組。前端

多頁面工程vue

|-- src/ 源代碼目錄

    |-- html/ html 文件目錄
        |-- page1.html page1 頁面的 html 文件
        |-- module1/ 子目錄
            |-- page2.html page2 頁面的 html 文件
            |-- ...
            
        |-- ...    
        
    |-- js/ js 文件目錄
        |-- common/ 公共文件目錄
        |-- page1/ page1 頁面的 js 目錄
        |-- module1/ 子目錄
            |-- page2/ page2 頁面的 js 目錄
            |-- ...
            
        |-- ...
        
    |-- css/ css 文件目錄
        |-- common/ 公共文件目錄
        |-- page1/ page1 頁面的 css 目錄
        |-- module1/ 子目錄
            |-- page2/ page2 頁面的 css 目錄
            |-- ...
            
        |-- ...
        
    |-- less/ less 文件目錄（內部結構跟上面相似）
    |-- images/ 圖片文件目錄（內部結構跟上面相似）
    |-- data/ api-mock 文件目錄（內部結構跟上面相似）
    |-- ...

單頁面應用react

|-- src/ 源代碼目錄
    |-- components/ 組件文件目錄（如 react）
        |-- common/ 公共文件目錄
        |-- page1.js page1 頁面的組件文件
        |-- module1/ 子目錄
            |-- page2.js page2 頁面的組件文件
            |-- ...
            
        |-- ...    
        
    |-- services/ service 文件目錄
        |-- service1.js page1 頁面的 service
        |-- module1/ 子目錄
            |-- service2.js page2 頁面的 service
            |-- ...
            
        |-- ...
        
    |-- models/ model 文件目錄
        |-- model1.js page1 頁面的 model
        |-- module1/ 子目錄
            |-- model2.js page2 頁面的 model
            |-- ...
            
        |-- ...
        
    |-- ...
    
|-- images/ 圖片文件目錄（內部結構跟上面相似）
|-- data/ api-mock 文件目錄（內部結構跟上面相似）
|-- ...

這種方式的優點是能使文件分類、功能分類很是清晰，而且可以在必定程度上約束組員的書寫方式（目錄結構），也清晰明瞭、簡單易懂。但這種方式有很明顯的缺點：git

不能很簡單快捷的知道某個頁面或某個功能塊有哪些文件；
建立、更新、刪除頁面會變得很低效，由於須要到不一樣文件類別目錄去找文件；
開發效率不高，而且很容易疲勞，由於編輯一個頁面的時候須要在編輯器的文件導航中展開各個文件，導航就會很是長。

因此，對前端項目而言，多數狀況下我不會使用這種目錄結構。github

2. 模塊分塊

這種方式是以頁面模塊、業務模塊或其餘類型進行分塊。ajax

多頁面工程json

|-- src/ 源代碼目錄

    |-- page1/ page1 頁面的工做空間
        |-- index.html html 入口文件
        |-- index.js js 入口文件
        |-- index.(css|less|scss) 樣式入口文件
        |-- html/ html 片斷目錄
        |-- js/ js 文件目錄
        |-- (css|less|scss)/ 樣式文件目錄
        |-- data/ 本地 json 數據模擬
        |-- images/ 圖片文件目錄
        |-- components/ 組件目錄（若是基於 react, vue 等組件化框架）
        |-- ...
        
    |-- module1/ 子目錄
        |-- page2/ page2 頁面的工做空間（內部結構跟 page1 相似）
        
    |-- ...
    
|-- html/ 公共 html 片斷
|-- less/ 公共 less 目錄
|-- components/ 公共組件目錄
|-- images/ 公共圖片目錄
|-- data/ 公共 api-mock 文件目錄
|-- ...

單頁面應用api

|-- src/ 源代碼目錄
    |-- page1/ page1 頁面的工做空間
        |-- index.js 入口文件
        |-- service.js
        |-- model.js
        |-- data/ 本地 json 數據模擬
        |-- images/ 圖片文件目錄
        |-- components/ 組件目錄（若是基於 react, vue 等組件化框架）
        |-- ...
        
    |-- module1/ 子目錄
        |-- page2/ page2 頁面的工做空間（內部結構跟 page1 相似）
        
    |-- ...
    
|-- images/ 公共圖片目錄
|-- data/ 公共 api-mock 文件目錄
|-- components/ 公共組件目錄   
|-- ...

這種方式避免了「類型分組」的問題，但也有一些不足：

對組員的約束很小，每一個工做空間下的目錄結構能夠徹底不同；
工做空間下的目錄結構不是很容易定義好，對開發人員水平要求要高一些。

儘管有一些不足，可是能夠配合構建工具消除，因此通常狀況下我會選擇這種目錄結構。

3. 配合使用

不少狀況下，這兩種方式是能夠配合使用的，好比多頁面工程中有小型單頁面應用。

|-- src/ 源代碼目錄

    |-- page1/ page1 頁面的工做空間
        |-- index.html html 入口文件
        |-- index.js js 入口文件
        |-- index.(css|less|scss) 樣式入口文件
        |-- html/ html 片斷目錄
        |-- js/ js 文件目錄
            |-- ajax/ 對 ajax 封裝的目錄
            |-- util/ 工具類函數的目錄
            |-- pages/ spa 應用頁面目錄
            |-- data/ 靜態數據目錄
            |-- tpl/ 模板目錄
            |-- (event|view)/ 事件監聽文件目錄
            |-- ...
        |-- data/ 本地 json 數據模擬
        |-- (css|less|scss)/ 樣式文件目錄
        |-- images/ 圖片文件目錄
        |-- components/ 組件目錄（若是基於 react, vue 等組件化框架）
        |-- ...
        
    |-- ...