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 the system. 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. comment[] 6:13:48 PM

© Copyright 2006 todd hoff. Last update: 7/11/2006; 12:39:39 PM.