Refactoring
I read Martin Fowlers book entitled "Refactoring - Improving The Design Of Existing Code". Refactoring, as defined by Fowler, is "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior".
As software is written, it normally "decays", that is, the code becomes harder to read and more difficult to maintain. Refactoring, is doing the opposite. It is making the code easier to read and easier to maintain. It also can mean an improvement in the code itself, say a better algorithm.
Refactoring can be done in large or small chunks. One of the issues with refactoring in large chunks is that it opens up the possibility of regressions. If you change a large chunk of code, you'd better ensure your tests will catch any change in behavior. Of course, sometimes you need to refactor in large chunks, so this isn't necessarily bad, it just touches more code and therefore, is more likely to change the behavior of the code.
Refactoring in small chunks tends to have less of an effect on behavior, but it also can mean less of an improvement. Sometimes trying to change a small amount of code leads to refactoring which really requires changes elsewhere. This cascade effect may cause large changes in code and behavior.
Whatever refactoring you do, you should make sure you have sufficient testing in place to ensure there are no unwanted behavioral changes in your refactored code.
