项目的目录结构进行分类规划对可维护性的意义
以前也没有深刻意识到它的重要性。直到后来,去接手一些遗留系统,那种混乱,寻找代码和代码文件多么费力。系统经过了很多人手,人员调岗,人员离职。每个人都有自己的风格，折腾一下，就闪了。丢下一个千疮百孔的系统。
人的眼睛是相信现实的东西，没有经历过那种坑，就无法理解。所以当我们怎么说要规划好目录结构，要好的命名方式，一些技术都不以为然。包括我以前也一样，我以前能够接受好的东西，但是我没理解，就不会有深刻发自自觉性去这样做。内心只是想:这个问题不大吧。
因为现实案例最让人印象深刻。总结一下遇到的问题
上面两个是比较坑人的目录结构，接手的人员太多了，加的目录也重复。
-------------------------------------------------------
后面这个系统使用mvc框架，相对好，但是也出现不清晰的地方，暂时系统的功能不是很多，所以目录很少，看起来很清晰。但是，随着时间的推移，加的功能越来越多，才会看起来混乱。
比如：上面这个curl目录就不太好。不应该放到根目录下的。这样会给人误导，使得接手的技术，某天增加新功能，也会新增加一个文件夹放到根目录。那么，后面功能加的多了，大家都会这样子做。
那个时候才去思考解决办法。我一直在想,怎样才能让项目在可控的范围内呢?
出现问题的原因是什么
虽然好的风格在业界都是有共识的。但为什么造成那么混乱的系统。原因是什么呢?
有人说原因是:各个技术人员水平不一样。所以这个问题很难解决。束手无策。
也有人说,原因是,系统经受的人太多了。这个技术维护一段时间,然后另一个技术维护一段时间。这样就造成了千疮百孔。除非公司保证技术人员的稳定性，但这个很难。所以这个问题也很难解决。
仔细，深入去思考。我在想,这些都只是表明上的原因。难道因为这样就没有解决办法吗?
如何解决，很多人也有自己的想法，归纳起来有:
1、要求系统维护人员遵循风格统一。写好规范文档。让大家按照规范来做。提交修改代码,需要进行代码审核,可是这需要成本。一个中小型公司,技术人员有限,都是忙着开发功能去了，抽出时间来审核代码(哪怕是大体审核)，也是需要时间投入的。
所以现实情况是,进行代码审核,在很多公司往往做不到。
2、成员培训。归根结底还是要放到人的自觉性上去。所以要经常给大家灌输好的风格意识,进行培训。这个方案其实有效果。具体得依赖于团队技术领导本人的个人影响力，能不能以身作则，用代码示范影响到成员。所以还是依赖于某一个经验丰富且有影响力的人,一旦缺了这个人,就会导致一盘散沙。尤其是当这个人如果离职怎么办呢?
上面办法都是正确的。但是会有阻碍和困难。我在想,能不能做到不依赖于某个特别的人而让团队成员自觉做到呢? 并且,可不可以,忽略掉团队成员技术水平的差异性呢?
根据心理学，就是示范效果。虽然大家水平不一样,但是看到一个好的示范,会不自觉的遵守。另外就算其不遵守,也会感到无法使用。自己都会感到羞耻。
比如mvc的框架，定好了controllers，views，models，后面刚入门的人,都能按照目录结构去加代码。
具体要做的是:对系统的代码和目录预先设计好。规划好目录结构。什么目录放哪种类型的文件的。
以前听过一句话说:架构师的目标就是让程序员变得更加不用很费很多精力,按照预先规划设计好的方式去做就可以。
现在看来这个非常有道理。
心理学:如果已经有的东西是混乱的,那么也会觉得痛苦,干脆凑合一下算了
做系统前，把系统的规划好
不规划好，后面接手的人就会不知道标准。
安装目录包括一下几个文件夹：
安装目录/public/
安装目录/app/
安装目录/cache/
说明:
1、public目录下是对外开放的目录。也就就是nginx配置指向的目录。目录里面的子目录接下来在详细介绍
2、app，所有源码存位置。
3、cache,模版编译缓存存放到这个里面。为什么要放到这个里面呢?
public目录下的子目录
public/index.php
public/js/
public/images/
public/css/
app目录下的子目录
app/controllers 控制器文件
app/models 模型文件存放目录
app/views 模版文件目录
app/config/ 所有的配置文件存放
app/library/ 所有的公共库文件。文件夹名称也可以命名为lib，就是library单词的简写。
app/logs/ 日志文件目录。php代码记录的日志信息
app/api/ 里面放一个sdks文件夹。所有的sdk放入里面去。每个sdk一个文件夹。比如sdks/pmsSdk/ sdks/memberSdk/
app/tools/ 一些工具放入到里面去。比如定时脚本，则放入task文件夹中去。app/tools/tasks