标签：
很多人可能会觉得项目初期的时候,可以先不考虑重构以及优化, 正如我当前这个项目就是这样做的,但是,最终的结果是什么?出现了一种比较悲剧的场面, 面对着复杂的类、函数、基类与派生类之间的耦合度过高,派生类的重复性,内聚性高低,都慢慢的暴露了出来，当项目完成之后，在想着重构的时候，会发现连自己写的东西都懒得动了。为什么会导致这样？ 原因就是前期没有注重它(重构)。
何时进行重构，如果进行重构?
如何进行重构?这个就是一个说不完的话题了，在这里先说说何时进行重构
重构的意思是在不改变程序原有功能基础上，对代码进行优化，使程序质量更好，使代码的可读性更好，使程序的结构更加清晰， 这样不仅仅是造福与后来人，对自己更是有益，当你看着你两个月前所写的代码，复杂，冗长，不清晰，你自己都会喷出 “Fuck” 。
重构应该在什么时候开始什么时候结束？
我个人觉得重构应该伴随着项目的始终，没错，在开始搭建项目的时候，就应该想到这个项目以后要如何的进行扩展、优化、如何达到耦合性更低，内聚性更高。
我们所写的每一行代码,每一个函数,都应该思考一下我为什么?出于什么样的业务目的去写,往往在实际的开发中,我们也许并没有过深的考虑很多东西,我们也并不可能面面俱到,总有遗漏点的,正如:世界上没有没有Bug的程序.但是通过我们的深入的思考,可以减少Bug出现的次数,并且稍微的思考多一些,那么代码的设计的会更好一些,从而后期的工作量也会更少一些.
重构是设计出来
为什么这样讲? 原因很简单,代码本身就是一种艺术,你写的每一行代码都形同与画一幅花中的一笔一划,最终形成的成果就是你所花的这幅画.那么,我们是否应该好好的构思出鼻子、眉毛怎么样的画（设计）才会更好呢？在重构的过程中,往往比我们真正实现这个功能的时候要考虑的事情多的多,在重构的同时我们可以合理的利用一些面向对象的设计原则以及设计模式,在使用它们的同时找到真正适合这个业务的模式.
所以我一直觉得我们不必特意的去学习设计模式,在进行程序重构的时候,我们在去看设计模式,这时候我们所学到的模式往往更加的容易理解.
重构需要做那些方面优化?
重构需要做那些方面的优化? 如我在重构目前的项目时主要注重一下几个方面;
1 : 功能实现了但请求响应速度较慢.
这一点是要解决的性能问题,界面反映速度慢,找出慢的功能点,然后找出导致这一功能点慢的原因,看能否先从业务逻辑上进行优化,如果不能的话,在思考是否能有更好的办法换一种方式达到同样的效果,同时功能还不受到影响( 一般达到这一点了,说明你的技术能力正在逐步的提升,高级程序员与中级和初级程序员的区别就在于能否深入技术,同样的问题,能有不同的处理方式,从而选最优 ).
2 : 基类与派生类之间耦合性高
在一般的开发过程中,我们往往是直接就新创建一个Class,然后,字段、属性什么的直接加上，然后实现。这样在Class逐步多了之后，就会发现类中是一团糟，每个类中的耦合度很高，这样我就需要花费点时间来好好的缕一缕了，包括如何选择基类、类与类之间的关系（解耦）、类中的属性。
3 : 冗余的类,无用的函数、字段、属性
查看那些类，那些函数没有使用、确认之后清除。
4 : 类、函数、字段、属性的命名
在重构的时候，会发现有些类、函数、字段、属性的名称自己都不清楚，那好把。修改了他把，因为你都不明白，别人就更不明白了。
5 : 冗长的函数拆分
冗长的代码可能功能性上没有问题,但是对于阅读理解上面可以是一个巨大的坑了,我们所写的代码一般都能被计算机所认识,但是更重要的是要被人所认识,那么之所有削减冗长的函数,是因为函数的代码块越小,代码的功能管理就会越简单,代码的处理和重构也会更加的方面,复用性也较强,更加的清晰直观.
6 ：对象的使用,类的设计.
对于目前已经完成的项目来讲,主要考虑以上几个方面优先级依次递减, 同时不建议过量的更改类的抽象层面的东西,除非这个只是一个很简单的业务类,只影响它本身.
为何重构？重构会影响那些东西?
还是那句话重构就是为了不改变原有功能的基础上，对代码结构进行调正，也可以理解为是一种整理，我们所写出的代码，计算机是识别的，但是你能保证接下来的另外一个程序员能够看得懂你写的代码吗？你能保证你的代码在两个月以后自己能看的明白吗？所以重构真正意义上是为了程序的结构更加清晰。
重构会影响那些东西？如何的避免？
重构本身就是为了修改冗余，繁琐，腐烂的代码，对于这些代码肯定不是那么好理解和修改的，期间也肯定会出现许多千奇百怪的问题，例如：我修改了登录功能，但是我首页的数据显示受到了影响，我重构了首页的加载数据的代码，从而导致我某个模块的数据显示不正常了，这就是我们重构了一个地方但是却对许多地方造成了功能上的影响。
那么如果避免这种情况或者说如果有效的使其不受到影响呢？测试、查看引用。在我们重构一个函数、或者一个类的时候，需要查看这个类或者这个函数被那些地方所引用，这些地方都是用来负责那些功能模块的，从而在我们重构完了（或者重构的中途）之后查看相关业务模块运行是否正常。另外就是对于业务代码进行测试。
本文是本人在开始进行重构时候一些总结,后续还会持续的更新...,如果您觉得有道理,不妨赞一个,如果您有其他的意见还请提出,毕竟个人的小小总结,或者您的回复,就能帮助很多人解决一些正在思考或者半知半解的问题呢?
何时进行代码重构?
标签：
原文地址：http://www.cnblogs.com/DeepLearing/p/4530400.html
