Change code to... improve code. You Refactor.
When dealing with unreleased code, but not always.
Code that was written without tests, is basically free play when change is needed. You have to accept the downside of high probabilities of changing behavior.
You can move code arround without an specific goal but a somewhat defined idea that will hopefully clear out as you go.
To refactor code is hard. Refactoring techniques point you to design patterns, but only few times the entire pattern emerge.
The more is known about the codebase the better.
The refacotring intent starts off by the desire to improve a particular part of the system. Determining the priority of these areas commonly arises a challenge wich requires conversation.
Communication is important. Regular IM or face-to-face conversations can be helpful, While pair programming stands as the most natural and fastest option.
Once you understand that all other technical goals in software are secondary to man- aging complexity, many design considerations become straightforward. From code complete.