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

 

 

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

 

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

是一套典型是基于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函数不删除,也不注释掉,避免影响到已经调用的代码。而是把这部分代码抽到一个类文件中去。

  先在某些地方使用