In a recent meeting, our own self-proclaimed agile guru (not saying I disagree!), Odd Helge Gravalid, came up with a good suggestion on when refactoring can be really troublesome.
If you are working on a "legacy project", a system in production, lot's of ugly code, no structure - in other words refactoring heaven, refactoring can actually be dangerous. Say you do refactor lot's and lot's of the code, and at the same time, someone else need to do a fix and they bring in a bug in the code. If this is patched into the live system, and you try to find out what went wrong, you have a problem.
Why? Often you can simply start out by doing a code-comparison in these cases, to see what has been changed. Try doing that after a big refactoring (Refactoring here normally includes removing unused code, etc. Not really refactoring, but for lack of a more complete word....)
I'm not saying that you shouldn't refactor in these cases. Just be aware of the risks involved. And hopefully you do write a complete test suite for the code before you refactor it, making it a lot easier to track down any problems with both the refactoring and any new functionality.. (Remember: Typemock + legacy code testing = true)
Friday, August 22, 2008
When is refactoring unappropriate?
Subscribe to:
Post Comments (Atom)
1 comment:
Try adding maintaining two branches in that scenario and let's say the code is following the "magic push button" paradigm. Ohh.. Nice.
My suggestion is that one should consider doing dedicated Sprints/Iterations where the entire team does nothing but refactor to avoid these kind of scenarios. This would ofcourse be something the Product Owner should recognize as a way to go. Something they seldom do.
Great post and a great point. Been there for 6.5 years, so I know a great deal about this subject. :)
Post a Comment