聊聊代码目录结构
本文写于 2020 年 11 月 20 日
为什么需要纠结目录结构
好的代码结构最重要的目的，就是让人看着舒服。
如果不需要人看的舒服，对代码结构、目录结构的思考根本没有任何必要。但代码是给人看的，我们读代码需要一个好的结构才能让我们更好的在脑子里对项目进行拆解和组装。
例如一个 1000 行的代码文件，和 5 个 200 行的互相关联的代码文件，你觉得谁更好理解呢？
因此我们要做的，就是让项目的目录结构变得像瑞士军刀一样，清晰明了。
好的结构是怎么样的？
墙裂推荐《Unix 编程艺术》，里面讲述了很多工程师编写代码的宝贵经验，例如：功能单一原则。
如果我们已有代码实现了 A 功能，那么当需要添加 B 功能时请重新写新的代码，而不是在 A 的代码中“添砖加瓦”。
我认为，好的目录结构应该有三条：
- 好的结构应该保持单一职责；
- 好的结构应该是通用的；
- 好的结构应该是有明确定义的。
util 目录
util 是工具的意思，该目录可以用来放一些公共的工具函数、工具类。
当代码的私有方法越多时，代码就会显得越乱，更有可能出现功能重复的不同函数。这时候就应该进行整理，抽离出公共的函数，放入 util 中。
util 是最好做单元测试的目录，因为里面的函数、方法、类都是有明确的输入和输出的。
service 目录
service 是服务的意思，用来提供一个服务，该服务可能包括数据处理、发送请求，或是调用别的服务。
和 util 的区别在于，service 会包含有项目逻辑，而 util 中的代码往往是所有项目都通用的。
不是所有的功能都能抽离成为一个 service，service 需要相对独立，是一个独立的功能模块。例如：身份验证、文件储存、请求数据……
controller 目录
controller 是控制器的意思。所有的指令、调度都从这里发出，哪一个 service 做什么事情，获得的数据提供给谁，都是 controller 来实现。
这里最容易产生脏代码，所以需要时常清理，将公用的代码逻辑提升到 util 或者 service 中去。
但是对于前端来说，一般也不存在这个目录，因为我们的逻辑一般都是由用户触发的。
model 目录
model 是模型的意思。该目录承载的功能就是负责数据的抽象，即描述一个个数据的定义。
在前端项目中，这个目录几乎不会出现。
model 应该是一个纯数据的集合，通常项目会有很多 model，一条业务流就是对应一条或者多条数据流。
拿知乎为例：
- 文章是一个 Model，一般叫 Article，包括 Title，Summary，Author，Content 等等；
- 评论也是一个 Model，一般叫 Comment，包括 Content，userID 等等。
dao 目录
这个目录前端真的不会用，因为这是用来存放和底层数据库通信代码的目录，负责对数据库增删改查。其中不含判断逻辑，dao 只关心增删改查，而不在乎是否存入正确的数据。
service 会和 dao 相对应，有人认为一个 service 对应一个 dao 为最佳——service 检查数据，dao 存取数据。
但是从本质上来说，dao 并不需要和数据库有什么必然的联系，他只是 data access object 的缩写。所以，只要是需要持久化数据，并包装成一个对象，这个对象都可以称之为 dao。
views / components 目录
这是前端会有的两个目录，分别用来存放页面与组件。
通常我倾向于在 components 中再进行分类：
- 一类以页面名字分类，里面存放该页面的独立组件；
- 公共组件直接放在 components 目录中，如果是一系列的组件，例如 modal 模态窗、button 按钮，就存放于 uikit 目录中。
assets 目录
用于存放各种素材，png、jpg、svg 图片等等。
如果一个素材图片是一个组件独有的，那么建议和该组件放在一个目录中。
拥有这些结构就是一个好的项目吗？
项目中是否包含这些目录或者模块，和项目结构是否完善根本没有关系！！！
但是当你的项目结构相对完善的时候，你就会发现有他们的存在。不要弄反了！
目录结构就是项目架构么？
是，但是只是一点点。项目架构还涉及到 service 的具体设计，互相之间如何调用、解耦……等等等很多东西。良好的目录结构只是皮毛中的皮毛罢了。
但这是第一步，养成好习惯，理解设计的本来目的，而不是不停的模仿。持之以恒，才是进步。
参考文献：
https://www.zhihu.com/question/58410621/answer/156868800
https://www.zhihu.com/question/58410621
（完）