About重构
一. 什么是重构?
重构(Refactoring)就是在不改变代码外在行为的前提下,通过调整程序代码改善软件的质量、性能,使其程序的设计模式和架构更趋合理,提高软件的扩展性和维护性。
也许有人会问,为什么不在项目开始时多花些时间把设计做好,而要以后花时间来重构呢?要知道一个完美得可以预见未来任何变化的设计, 或一个灵活得可以容纳任何扩展的设计是不存在的。更多情况下我们需要特定的代码去做特性的事情
二. 什么时候重构?
完成某部份功能后,新增或修改某功能前。
一定要写好对应的测试
一定要了解程序代码。
一定要把重构时间加入时程里。
三. 怎么重构?
1.从现有版本分支。
2.决定要实做的方向。
3.小步前进。
4.测试。
5.完成一次小重构后,提交至版本控制系统。
6.继续步骤2 ~ 5 。
7.整个功能完成后,合并回主干。
四. 重构ing
1. 重复代码
这个可能算重构中遇到比较多的问题,代码冗余太多,很多地方都是ctrl+c,ctrl+v搞过去的,以至于越到后面,改个东西就越复杂,比如很典型的逻辑处理。
处理方式:提取重复部分成函数。
2. 过长函数
比如一个拥有1000行的函数。这样的函数和过程化处理无异,而且你很难保证这么长的函数里面不会出现什么错误。而且当你想只用这个函数中的其中一部分的时候将会变得很麻烦,所以你有可能会直接使用复制粘贴,于是,情形一中说的情况就出现了。
处理方式:函数细化,最好能将函数分离
3. 过大的类
我们的项目里面好像还用不到,原因是类都没怎么看见。这种情况一般可能容易出现在一些GUI应用里面,因为这类应用跨类调用很麻烦,而且有很多是在类里面封装的。于是为了省事,方便,这个类的成员函数就不断增多,类也就不断庞大起来。
处理方式:将每个层的职责进行分离,弱化类,细化类关联。
4. 过长的参数列
一般说来,函数的参数最好不要太长,如果确实需要传递那么多的参数。可以使用参数数组,或者参数类。如果是构造方法,可以使用构造器设计模式。让别的类去负责使用类的组装。
5. 发散式修改
这个的意思是如果某个类经常需要在不同的情况下做变动。你的类很有可能还没有考虑到即将到来的变化,所以你不得不做扩展性的修改。
比如一个叫鸭子的类,你只设计了游泳,鸣叫,飞。然后某天出现一个鸭鸣器(可以模仿鸭子的叫声的鸭子型玩具),你这个类就蛋疼了。
处理方式:可以预先想好有可能出现的情况。做好预设
6. 霰弹式变化
这个的意思是我们要改一个小功能,缺不得不改掉很多依赖的地方。比如本来我们设计的数据库只能兼容mysql。现在突然变成mssql了。要怎么去改?你懂的!
这个比较明显的体现可以在我们写的sql语句上。如果我们在数据库修改了一个字段。而且这个字段又是必须的。我们可能不得不去修改掉每一个sql语句。这样造成的后果是如果你一不小心漏掉了某个地方,你可能不会察觉出来。但是后果是这句话有可能就无法成功执行了。
处理方式:对于数据库操作这样的。类似的处理方式是使用模型层,数据模型就是这样诞生的,只负责数据对象的处理,而不用关心具体底层语句。如之前提到的新加字段,可以直接通过复写类成员的方式就可以达到目的了。
7. If和switch
对于oop来说是应该少用switch。但是对于php而言,个人觉得应该是善于使用switch。If过长的把代码拉开反而降低阅读。
一些比如If else if else if else if 反而不太好
当然,如果条件内的语句过长,分离出个函数出来也是非常不错的选择
8. 注释问题
注释,这里我包含无注释和过度注释两类,其实大多数的情况下,是无注释造成的危害更大。别总是想着让别人通过函数名,参数名就能了解这个函数,参数是做什么的就很好了。必要的注释一定不能少。名字并不能完全传达出你的函数做了什么事情,需要什么参数,返回结果是什么,逻辑上有什么需要注意的地方。如果你写的程序不能让另一个程序员在30秒之内看懂,那么你的代码很应该好好修改下了。
过度注释的一个说法是指将代码中的注释降低到最小,在你想写注释前先通过方法重名,字段提取等方式重构。个人不推荐这种方式。只是有的没有必要注释的地方就没必要写。比如,ifxxx什么之类显而易见的东西就可以省略了,当然,注释多页无妨。个人见解。
9. 业务逻辑相关
这个的重构前提是需要你对代码足够熟悉,别重构出bug哟!
五. after重构
1. 自我测试
测试代码的完整度,有没有重构出bug出来。有没有破坏原有功能
2. 让别人知道你重构了什么东西
3. 见好就收
别把重构最后弄成了重写。
六. 重构工具
非常遗憾,php的自动重构工具都不是特别理想,zend,netbeans改改函数名,变量名还是可以,但是不要太相信这些工具。
有一个rephactor官方网址:http://rephactor.sourceforge.net/ ,但是他只支持php5.2
沙发
桃子
5 4月 12 at 9:31 下午
写得真好 +1
尤其是这句
‘要知道一个完美得可以预见未来任何变化的设计, 或一个灵活得可以容纳任何扩展的设计是不存在的’
鼓浪鱼
4 5月 12 at 1:27 下午
你博客挂了.
princehaku
5 5月 12 at 11:01 下午
忙里偷闲的过来逛博客,又学习了
yurenchen
23 5月 12 at 10:56 下午