目录的重要性事物总是这样，一开始是非常简单的，但是随着项目需求量变大，事物就变得复杂了，甚至是不可控的，这里的复杂也是概念间相互关系复杂。可是概念的精准定义是建立在对客户需求的理解深度上，而且对需求的深度理解是需要天赋或者时间沉淀的，可能是理解力极强又或者需要5天甚至1一个月时间才能够理解到位。如果概念定义精准了，并且清晰易懂，也不会存在复杂一说，事物变得简单了，那么这个世界也许就不会那么多痛苦了。但是也不要消极，如果代码写起来很复杂，很乱，最大可能是自己对需求理解不到位。这是真的。在项目实践的过程中，也是为了赶时间在加上自己的基本功确实还是需要提高，写出了很多if…else语句，这样的代码是根本无法维护的。最后还是把过程式的代码整理成了面向对象的代码。这里并不是说面向对象的代码块好于过程式的代码。后面之所以能够能够写好，是因为随着时间推移，对项目业务需求理解深了，自然而然写出来的代码就特别简单，清晰易懂。可是，哪个公司又愿意给一个开发者这么多时间呢？一个业务逻辑需要迭代多次，才能把代码写到更好。也许是高级工程师或者专家的话，就不会存在自己目前面对的问题。
借鉴同事说的话：谁都不是一开始就做到最好的。事物多了，那么就应该把事物进行归类整理。23种设计模式，最后被归为3大类，构建类（创建对象的最佳实践），结构类（构建对象与对象之间，类与类之间，类与接口之间的组织架构关系的最佳实践），行为类（某个具体类的需要完成它单一职责的最佳实践）。问题是一步一步出现的，是一个逐渐迭代的过程。非常清楚地记得在项目实践过程，需要给某一类功能添加一个具体的功能，这样的情况一开始，是无法预测的。当自己面对这样的问题，直接把代码重构了，就行了，不需要去责备和抱怨，能够遇见问题真的是缘分。所以在写代码的过程中，不要想太多了，什么多访问一次数据库了，什么多了一次循环，没有必要，先跑起来。解决办法就是：我们根本无需去焦虑未来。淘宝的架构体系，也是从单机一步一步演化到服务化的。最近一次项目实践中，在dto目录下就出现了失控情况。于是对项目目录的一个标准做法做出总结。如果自己没有出现这样的问题，也许永远也不会引起对项目目录结构的重视程度。maven约定目录
.idea文件
不用管这个文件。.idea文件存放项目的配置信息（版本控制信息，历史记录）。
.iml
iml是idea的工程配置文件，存放当前的一些配置信息。
mvc目录结构
com..
是公司名称
是项目名称
这是一个基础设置目录，存放所有基础设施文件，比如配置文件，枚举文件，异常文件，常量文件，注解文件。存跟业务逻辑隔离开的文件即可。
控制器，现在采用前后端分离，主要响应json数据到前端。但是需要引入并获取到想要的数据，然后在把所有的需要的数据组装起来，最后响应的前端。

一 项目目录实践总结

一项目目录实践总结