项目中使用最广泛最典型的目录结构，就是将类似功能的代码放在一起。简单易懂，一眼就能看出来某个模块是用来做什么的。
由于没有具体的规则，因此每个项目的情况都不同。在大多数情况下，它通常看起来像这样：
├── src
│ ├── apis
│ ├── actions
│ ├── assets
│ ├── components
│ ├── controller
│ ├── helpers
│ ├── hooks
│ ├── pages
│ ├── services
│ ├── stores
│ └── utils
└- pages 页面 - 页面目录
- components UI-kit、业务组件和工具组件的目录。通常是项目污染最严重的地方
- api 服务器交互逻辑的目录
- helpers 一堆不同实用程序的目录
- store 状态管理目录（Redux Reducers 等）
- hooks 常见可重用 hook 的目录
- assets -资产 - 图像、图标字体等的目录
“经典”架构有很多问题，最明显的缺点就是：系统的所有元素耦合无序，组件之间的隐式连接和模块混乱，分散在整个项目中（高耦合）。 UI、业务逻辑和 utils 之间没有任何明确的关系（低内聚性）。随着时间的推移，项目就会越来越难以梳理和维护。
安全地重构它极其困难。一个模块中的更改可能会导致应用程序另一个地方出现意外错误！
它完全不适合中等或更复杂的项目。另外，不建议在超过 3 名开发人员的团队中使用它。
但有一些情况，你可以尝试一下：
- 适用于小型和普通项目，比如简单的管理面板
- 临时工作，无需进一步维护
- 产品的 MVP 版本，快速演示版本
- 进行练习和实验的项目