目錄結構優化
現在前端項目越來越變得像大型工程了，而且越來越復雜了，需要處理好組員之間的協作，也需要做好業務分塊、去耦合來降低維護成本，并且還要保持高效率開發。
工程目錄結構的優化是能達到這個目的的一種方式。一般而言，不是多頁面工程還是單頁面應用，抑或二者都有，目錄結構都是以下兩種方式：
- 類型分組（按文件類型、業務類型等進行分組）
- 模塊分塊（按頁面模塊、業務模塊等進行分塊）
1. 類型分組
這種方式是以文件類型、業務類型或其他類型進行分組。
多頁面工程
|-- 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 文件目錄（內部結構跟上面類似）
|-- ...
單頁面應用
|-- 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 文件目錄（內部結構跟上面類似）
|-- ...
這種方式的優勢是能使文件分類、功能分類非常清晰，并且能夠在一定程度上約束組員的書寫方式（目錄結構），也清晰明了、簡單易懂。但這種方式有很明顯的缺點：
- 不能很簡單快捷的知道某個頁面或某個功能塊有哪些文件；
- 創建、更新、刪除頁面會變得很低效，因為需要到不同文件類別目錄去找文件；
- 開發效率不高，并且很容易疲勞，因為編輯一個頁面的時候需要在編輯器的文件導航中展開各個文件，導航就會非常長。
所以，對前端項目而言，多數情況下我不會使用這種目錄結構。
2. 模塊分塊
這種方式是以頁面模塊、業務模塊或其他類型進行分塊。
多頁面工程
|-- 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 文件目錄
|-- ...
單頁面應用
|-- 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 等組件化框架）
|-- ...
|-- ...
4. 后續
更多博客，查看 https://github.com/senntyou/blogs
版權聲明：自由轉載-非商用-非衍生-保持署名（創意共享3.0許可證）
