提高项目的可维性:目录组织结构清晰和目录的深度不要多

 

 

不使用单一入口的框架开发，代码和目录的数量越来越臃肿，项目维护成本很高

 

没有反面例子来做借鉴，人的大脑不以为然。下面的截图就是一个中型项目后来变成的目录结构，项目的代码越来越乱，开发人员不愿意去维护这个系统的代码，因为去找代码进行修改，变得很痛苦，代码混乱，目录很众多，找代码会看花眼。

是一套典型是基于discuz的ucenter的系统，随着公司业务量越来越大，随着时间的推移，对系统增加的功能越来越多，后来开发人员越来越多。这样一套系统，维护起来很困难。

 

 

 

具体到里面代码，找代码去修改，特别吃力，很难去定位到这个变量是从哪里来的。程序员在开发的时候，由于使用的不是框架，就不需要遵循放文件的规范。

目录的组织结构可以随意，造成了可以随处丢代码文件，只要include进来就可以使用，代码跑通即可。

 

下面的根目录可以放很多的文件，只要把核心类include进来仍然可以跑通代码。

 

 

因为不是单一入口式的框架，可以随意放很多目录，也放了很多文件

 

下面的目录已经够多了。

 而目录下面还有更多子目录

 

 目录这么多，目录没有规律性，大脑的记忆负担很重。去寻找代码修改，往往看花眼了。做开发的同行会有类似的感觉。

 

 

 

 

思考：如今深有体会，代码不仅仅是完成功能。而组织结构清晰，其实不是写代码方面。我们做其他事情也需要条理清晰。

 

从代码的编写，可以看出一个人的条理性。比如，目录分得很有层次性。层级很多，上面拉开都很深的目录。这样看起来的确比较混乱。

 

目录太多，文件太多，不符合人的大脑清晰阅读的习惯。从文字，从代码其实是可以看出一个人的思路是不是清晰。

 

其实特别不喜欢phpcms，discuz系统的代码组织方式，比较混乱。多个入口的形式，代码维护起来费力。

 

由于不是单一入口，所以接手的开发人员可以随便放目录。进行拷贝文件夹，拷贝文件，同名的文件和目录多。很难记忆。

 

 

 

 

单一入口式框架的代码组织目录的方式会让项目更加清晰

 

从最外层看项目。public是web资源，可见的。app才是项目的后端代码。

进入到具体的目录下面去

 

具体到目录里面的代码，看起来也很清晰，找起来很方便。接手的开发人员，要修改一个功能，拉开目录能够猜测到去哪里找。

 

 

一个目录下面放二十个代码文件，这个系统都能完成很多的功能了。

 

 上面看，整个项目目录控制在有限的数量内，上面的组织结构，应对的是一个日访问量千万的系统。

 

 

即便上面目录文件会比较多，但是有个特点，非常清晰有条理，大脑看起来就很容易知道这个目录下的东西是干嘛的。

 

静态文件存放的时候也可以非常清晰

 

 

css、图片、js文件都是分开目录存放。而有个wap版本涉及到的静态文件，我干脆直接建一个目录算了。其实也可以这样：在css里面建一个wap目录，在img目录里面建一个wap目录，在js目录里面建一个wap目录。

看情况而定。因为本身文件少。所以我干脆分开一个单独的wap文件夹算了。只要符合大脑清晰阅读，条理性，就好。

 

用户上传的大量图片

 

可以放到img里面，在里面建一个文件夹，专门区分是什么方面的图片。

 

1、比如是头像，那么就head_img文件夹。然后文件夹里面按年月日生成文件夹。

2、如果是商品图片，就建立一个goods_img文件夹。

如下，做一个示范：

 

 

单独用文件夹命名，看起来也非常清晰。以后迁移图片，也方便直接拷贝这个文件夹里面的图片。

 

 

 

 

 

经验积累

 

 

一，目录的深度要控制住。层级不能太深。太深的话。找代码修改，找文件。变得比较吃力。看花眼。

      在项目初始开发的时候，就规划好目录。这需要经验，能够预料到未来的增长。不过预料不到也没关系，可以模仿其他领域做事的办法，保持清晰和条理性就好了，这样接手的人能够看出项目的清晰结构。

 

  一开始清晰，后面参与开发的成员就会遵循清晰的方式。一开始不清晰，后面每个人就会随便。榜样的力量还是很大的。

  不管对其他人有没有明显影响，但是以身示范是非常需要的。连自己都不是那样，周围的人就不会形成正面向上的改进。

二，分类整理。静态和动态文件要分开。项目的静态文件(css,js,图片)都与动态php文件分开存储。

 

三，共同的部分，要抽出来。避免复制、拷贝相同代码到各个目录去，最后导致项目越来越难以维护，因为很乱，不清晰。

     定期重构代码，专门花费时间去做，对于很多公司不现实，因为往往业务方有新的功能总会要求做。所以专门在留时间去做。可能不太现实。

     我的思路是，在增加新的功能的时候，发现需要对某部分代码进行重构才能更好的增加现在的功能，那么我就会重构一下。如果不能，那我会先记下来，有时间我就去重构这部分代码。采用逐步替换的方式，摸着石头过河。

 

 

   

 

 

   随着时间推移，发现其他地方也需要验证手机验证码，那么思考，这一块验证短信验证码代码、生成验证码部分代码，是不是可以抽成共同的部分，封装成两个函数方便其他地方调用。

 

 

 于是就想抽成一个PhoneVerfiyCode类存这些函数。

 

  我们不是神，无法完全预估到未来的需要，厉害的程序员也不例外，但是我们能够采用定期重构代码的方式来解决。其实在设计模式中也看过类似观点，当发现代码有坏的味道的时候，就要进行清理，重构代码了。

 

  线上的代码在跑，这个控制器有好几处是使用$this->____ValidatePhoneCode($phone_code)的方式进行调用的。

 

  到底是重构代码，还是不重构代码呢？不重构代码，仍然可以正常开发功能。其他地方需要用到相同的验证、生成验证码，复制同样的代码过去？

 

  但是代码会越来越臃肿。冗余、重复的代码会让系统越来越臃肿。维护性越来越差。定期重构代码，能够让系统变得清晰。

  

  所以必须要做。只是什么时间做，如何不影响新功能的开发的前提下、如何修改不至于影响在线上跑代码的前提下去重构一下代码

 

  我的实施方式是：

  原来的____ValidatePhoneCode函数不删除，也不注释掉，避免影响到已经调用的代码。而是把这部分代码抽到一个类文件中去。

  先在某些地方使用