简介

目录结构规范，其实大多数人都不会去很在意，相对来说，去研究一些框架或者库的源码更能在面试或者工作中能更好的表现自己。但是有一些东西其实看似不重要，但却影响着项目的代码质量以及维护性。

为什么会想写目录结构的文章

为什么会想写目录规范的文章？其实想法还是来自工作，因为业务繁忙，排期紧张，有些人为了更快的开发，就会出现一些问题点，例如把公共组件当非公共组件来改，导致这个模块好了，其他模块白屏了。

为什么会出现这个问题？表面上是开发者的不谨慎，但透过问题看本质其实还是目录规范的问题，好的目录规范能让开发着一幕了然，不会去犯这些低级错误，而不好的目录规范就会让项目变的难以维护。

常用目录结构

扁平式结构

* components // 公共组件
* page // 页面
* types  // 类型
* constant // 常量

这种结构大家其实都经常会见到。如注释所言大家可以很明确的知道哪些地方改放哪些东西。

components

放在该文件夹里面的应该是一些公共组件，这些组件应该是像搭积木一样，那样一小块一下块的，而不是那些拥有特殊逻辑或者包含业务逻辑的。但是一些开发者还是会把一些特殊逻辑的组件放进去，这些组件其实不应该放在这里，因为这些组件是属于某个模块的，应该放在某个模块下。这样清晰易懂。

page

页面组件，页面级的。

types

放一些通用的类型声明，而不是一些不通用的。

constant

同理

树结构

* components // 公共组件
* page // 页面
      home  index 入口文件
            constant //页面下的常量 非通用
            types //类型 非通用
            component //页面下的组件 非通用
            ...
      
* types  // 类型
* constant // 常量

这种结构是树状结构，开发者所看到的就是一颗树，哪些是公共组件哪些是页面组件一目了然，能快速定位回归范围，component下还有component，这里层级不宜太深。如果有一些组件使用范围有提升，则组件所在目录逐步往上提高。 在这里特别提一下入口文件，这里负责这个目录的出口，为什么要这样做，其实是因为有时候我们组件内部目录结构或者内容会从一个文件到一个文件，而这时候如果是从对应文件引，那么数量少还好说，如果数量大，你就要去注意回归范围了。批量更改有风险，修改需今生。

总结

其实两种结构类似，但是我更推荐后者。 最后，文章内容少，只是一道开胃小菜。谢谢。