目录结构优化

现在前端项目越来越变得像大型工程了，而且越来越复杂了，需要处理好组员之间的协作，也需要做好业务分块、去耦合来降低维护成本，并且还要保持高效率开发。

工程目录结构的优化是能达到这个目的的一种方式。一般而言，不是多页面工程还是单页面应用，抑或二者都有，目录结构都是以下两种方式：

1. 类型分组（按文件类型、业务类型等进行分组）

2. 模块分块（按页面模块、业务模块等进行分块）

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 文件目录（内部结构跟上面类似）
 -- ...

这种方式的优势是能使文件分类、功能分类非常清晰，并且能够在一定程度上约束组员的书写方式（目录结构），也清晰明了、简单易懂。但这种方式有很明显的缺点：

1. 不能很简单快捷的知道某个页面或某个功能块有哪些文件；

2. 创建、更新、删除页面会变得很低效，因为需要到不同文件类别目录去找文件；

3. 开发效率不高，并且很容易疲劳，因为编辑一个页面的时候需要在编辑器的文件导航中展开各个文件，导航就会非常长。

所以，对前端项目而言，多数情况下我不会使用这种目录结构。

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/ 公共组件目录   
 -- ...

这种方式避免了“类型分组”的问题，但也有一些不足：

1. 对组员的约束很小，每个工作空间下的目录结构可以完全不一样；

2. 工作空间下的目录结构不是很容易定义好，对开发人员水平要求要高一些。

尽管有一些不足，但是可以配合构建工具消除，所以一般情况下我会选择这种目录结构。

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 等组件化框架）
         -- ...
        
     -- ...

以上就是前端项目中目录结构优化的方法总结的详细内容，更多请关注php中文网其它相关文章！