Monday, October 24, 2005
To Really Improve Your System You Can't Refactor
I've noticed I spread mistakes pretty evenly throughout my code. So
when I create an interface it has about an equal probability of needing
improvement as any other code I write.
I firmly believe in constantly improving my code and I see a difference
in quality because of that. Seemingly this would put me firmly in the
refactoring camp. But it doesn't. Why? Refactoring says you can't break
interfaces. That puts me in an awkward position.
According to the rules of refactor I have to not touch over 50% of my
code when that 50% needs just as much improvement as any of the other
code I write. But I want to keep improving my system. That often means
removing classes because I have figures out a better way. I may need to
change the signature of a method because a I have figured out a better
way. I may need to drop a method because I have figured out a better
way. I may need to make a lot of changes of all types to keep improving
Because I want to constantly improve all my code I can't refactor. I am
more extreme than that. If I see an improvement I make it. I don't care
if it breaks interfaces or not.
I hear we shouldn't be afraid of changing software, isn't the whole
idea of story based iterative development that evolves software? So why
shouldn't I break interfaces too?
No reason. Unit tests keep you safe from interface changes too.
Certainly an interface change may break a particular layer of software.
But interface changes should just impact that one layer. All your tests
above and below that layer should remain stable. If they don't then
that's probably a smell that should be taken care of anyway.
I've seen more time wasted because of the fear of change code than I
can shake a bit at. Interfaces aren't in any more sacred a position
than the code behind the interfaces.
So bee extreme. Don't refactor. Improve all of your system all of the time.
|| © Copyright
7/11/2006; 12:39:39 PM.