Refactoring is changing code after it already works. It is a series of small steps to minimize bugs. Should use unit tests to verify you don't break it. Refactoring does not change the behavior or add new features.
Code is not for computers to read, it is for programmers to read. Most programs spend 90% of their time in maintenance mode - refactoring makes code easier to maintain. Since the code is easier to read, bugs are easier to find. In the long term it is faster, short term it will take longer. Reduces chaos in long-lived code. Fowler formalizes and names the best practices of refactoring.
Opportunities for Refactoring
- When adding functionality - makes adding new features easier, but keep refactoring separate from changes.
- When fixing a bug
- During a code review
- Refactoring does take time though
- May need to sneak it past managers at first
- Eventually you will refactor as you go and will not be separating it.
Points to Note
- Refactoring is typically based on OO
- More atomic then patterns, but may use patterns
- Most don't concern interfaces, but some may work with them
- Many refactorings include other refactorings, or one is required before the other can be applied.
- Some are opposites (extract method, inline method)
Thoughts on Refactoring: Most successful applications spend most of their time in maintenance mode, where you are fixing minor bugs or making other minor changes. If the application has been properly refactored then these small changes take very little time. Otherwise these changes are very expensive. Refactoring pays for itself in the long run if your application has any sort of life span. Refactoring doesn't mean the code was written wrong to begin with either.
No comments:
Post a Comment