Jun 07
Was discussing this today. Refactoring is the process of modifying code without changing the external functionality of the code. Check out Refactoring: Improving the Design of Existing Code (The Addison-Wesley Object Technology Series)
- Increasing readability (changing variable names, method names, etc.)
- Increasing performance (faster sorting, introducing caching, clustering techniques, etc.)
- Decoupling classes
- Increasing class coherence
- Fixing broken windows (unused objects, unreachable code fragments, etc.)
- Simplifying (Introducing Enumerations, constants, putting common functionality into a single method)
- Reorganizing packaging of classes
- Further abstraction and extensibility
For the principles exemplifying 3, 4, 7 & 8 see Uncle Bob’s Principles of OOD. All of the above (except # 2) can be thought of as reducing complexity. And it is a lot easier to be successful at #2 if you can reduce complexity.
Great points on why refactor, but when? In my world all software development is related to a project, and projects have timelines. Too often the mentality of those in charge of the timeline is if it works, why change it? Reducing complexity decreases maintenance costs but that doesn’t help to meet a date on a plan, or at least not the current date on the current plan.
Tom,
That is a great point and a tough situation. My strategy in that situation is to continuously refactor as I am building out new features during the project. For example as I am writing a new method I might see that it would be a lot easier to do this if I refactored another part of the code so that it could be extended. Clearly this works best if the refactorings are small. However, my belief is that this will eventually allow the project to be delivered faster and at a higher quality. Higher quality can also reduce those timelines if they include time for testing and fixing defects.
In your situation, it will probably be difficult to refactor after you have completed a feature. Thus it will probably fly under the radar more if you refactor at the start of coding a new feature or during the coding of the feature. What is the process that your team uses for scheduling work and tasking it out?
A little bit of refactoring is better than none.
Good luck and thanks for the comment.
[...] Why Refactor? Jun 08 [...]