In an Extreme Programming environment, continuous, merciless refactoring is a way of life. Though the concept of refactoring isn't woven so tightly and explicitly into the workflow of most software developers, knowing when to stop what you're about to do and take an extra hour to rewrite a few methods or a few classes instead of adding yet another condition to that logic block could be the difference between 6 hours of head scratching and a simple in-and-out update when you see this code again 6 months from now.
If you're already working with a well written project it's frequently completely appropriate to add a few lines of code to a method or two, to pass in a new parameter, or run out and grab some additional data, and be done with it. Sometimes a bug is really just a bug: a loop is off by one, a boolean expression is incorrectly nested, some little bit of business logic was overlooked, whatever.
Sometimes though, a bug (or the process of fixing the bug) is an indication of a bigger problem. Here are 5½ signs that the patch you're about to make will cause you bigger headaches down the road if you haven't already considered and dismissed refactoring:
1: A new component doesn't seem to fit.
When you're holding a square peg and looking at a round hole, you should be asking yourself why the hole is round, instead of looking for a sledgehammer. Forcing a component into an archicture where it doesn't belong is going to cause problems now, while you try to trick the current architecture into supporting the new functionality, and it's not going to make it any easier in the future when you revisit the new component or add more new components.
read more...
