When Refactoring Goes Bad(collectiveidea.com)
collectiveidea.com
When Refactoring Goes Bad
http://collectiveidea.com/blog/archives/2011/02/23/when-refactoring-goes-bad/
1 comments
I couldn't agree more, which is why I wrote the post ;)
Most of the time we do lots of rapid iterating (we're in Ruby and JS, mainly) and it goes great. That's why I thought it important to highlight when we do it wrong.
Most of the time we do lots of rapid iterating (we're in Ruby and JS, mainly) and it goes great. That's why I thought it important to highlight when we do it wrong.
That's why I thought it important to highlight when we do it wrong.
I've also had the experience where I pulled out a lot of the refactoring tricks from Martin Fowler's book applied them, then looked at what I did and found it had made it worse! Instead of good code, I had an "anti-pattern" sometimes called "Macaroni." Things were done, like replace conditional with polymorphism, which one would expect to result in well factored code, but instead we just chopped up the code into little pieces that didn't make much sense and fatigued us when reading and debugging.
Refactorings are experiments. Some of them need to be thrown away.
I've also had the experience where I pulled out a lot of the refactoring tricks from Martin Fowler's book applied them, then looked at what I did and found it had made it worse! Instead of good code, I had an "anti-pattern" sometimes called "Macaroni." Things were done, like replace conditional with polymorphism, which one would expect to result in well factored code, but instead we just chopped up the code into little pieces that didn't make much sense and fatigued us when reading and debugging.
Refactorings are experiments. Some of them need to be thrown away.
A surprise asset to my refactoring process has been git with its ultra-lightweight branches. When I start thinking that maybe this refactoring was a bad idea, I check my changes so far into a new branch, go back to trunk and start again.
Then an hour or a week later, when I realize my idea wasn't so bad, it's easy to switch back to the branch and continue from where I left off.
Then an hour or a week later, when I realize my idea wasn't so bad, it's easy to switch back to the branch and continue from where I left off.
Awesome things about Smalltalk:
Refactorings which have unlimited "Undo" and "Redo." There's also the "Change Log" which is like a DB transaction log for your code state. You don't even need to think to check in a new branch. (Mostly, you save images when you're done for now, or you want to save log-replay time.)
Refactorings which have unlimited "Undo" and "Redo." There's also the "Change Log" which is like a DB transaction log for your code state. You don't even need to think to check in a new branch. (Mostly, you save images when you're done for now, or you want to save log-replay time.)
When you get down a deep rabbit hole, you lose focus and passion. We had great things happening, but couldn’t show them to anyone since they weren’t done.
If you're going "down a deep rabbit hole" then you're doing it wrong. Refactor in small chunks. Be prepared to throw out a chunk. It's an experiment.
If your language doesn't support rapid refactoring -- this is something to think about.