I think we have all been there before. You are happily doing some development, in short test-driven cycles, and you get to a point where you start thinking, "Couldn't I do this better?" Inevitably the answer to this question is "Of course! Yes, I can do it better." But now the question is, "Where do I begin?" Well, let's see, I only have 15 or 20 minutes invested in this code, why not just delete it and begin a new.
So it is with a fateful stroke of the "Delete" key that our story begins.
Fred Brooks wrote in the "Mythical Man-Month" that we should plan to throw the first one away. Just like Curly, the trail boss, in "City Slickers" he never really tells you what the "One" thing is, so I guess it could be some code as easily as it could be a whole project or part of a project. I never thought I'd be throwing things away at this level, or any level for that matter, but let's see how things play out.
There's a bit of panic after that one key stroke destroys 20 minutes worth of work, but there is solace in the seemingly bottomless undo buffer in IntelliJ so the panic quickly subsides. The focus now is rewriting the code that I just lost. But wait a second, I don't want to rewrite that code I want to refactor it. Let's not confuse those two concepts. Rewriting would be trying to recreate exactly what I had there previously, while refactoring the code involves improving the code without changing the intent. Okay, so I am not going to rewrite that code I am going to refactor it.
I run my tests for this method and, no surprise, they come back red. In surprisingly quick fashion, I refactor my way back to green. Really before I know it I'm done. Looking at the clock I realize that it took me less than 7 minutes to refactor the work that it took me 20 minutes to write the first time. So it took me a total of 27 minutes to do this Red-Green-Refactor cycle.
As I begin to reflect on the code to prepare to write this blog I realize that there are significant improvements over the initial code that I wrote. It solves the same problem but it is more readable, partly because it is about half of what I started with and partly because I've been through this once before and know more about the problem and the intent of the method. I also realize that there was some duplication in my original code so I made sure the second time through to eliminate that duplication.
Turning my mind back to the original exercise I start to wonder, "Should all the code I write be written this way?" "Of course." I always do my refactoring at the end so the answer is "Yes!" The next question in my mind is, "Could I have gotten to this code with other refactorings?" I think I could have but I certainly see that deleting the code and starting fresh is a very valid and useful refactoring. I especially see its usefulness for those times when you get about hip-deep into something and think to yourself, "Man, this is crap!" Don't try to unwind the mess, just throw it away and start again. If you're doing your work in small, test-driven cycles you only have 15 to 20 minutes invested in the code anyway. After all if it was a mess to begin with you can only make it better.
So it is with a fateful stroke of the "Delete" key that our story begins.
Fred Brooks wrote in the "Mythical Man-Month" that we should plan to throw the first one away. Just like Curly, the trail boss, in "City Slickers" he never really tells you what the "One" thing is, so I guess it could be some code as easily as it could be a whole project or part of a project. I never thought I'd be throwing things away at this level, or any level for that matter, but let's see how things play out.
There's a bit of panic after that one key stroke destroys 20 minutes worth of work, but there is solace in the seemingly bottomless undo buffer in IntelliJ so the panic quickly subsides. The focus now is rewriting the code that I just lost. But wait a second, I don't want to rewrite that code I want to refactor it. Let's not confuse those two concepts. Rewriting would be trying to recreate exactly what I had there previously, while refactoring the code involves improving the code without changing the intent. Okay, so I am not going to rewrite that code I am going to refactor it.
I run my tests for this method and, no surprise, they come back red. In surprisingly quick fashion, I refactor my way back to green. Really before I know it I'm done. Looking at the clock I realize that it took me less than 7 minutes to refactor the work that it took me 20 minutes to write the first time. So it took me a total of 27 minutes to do this Red-Green-Refactor cycle.
As I begin to reflect on the code to prepare to write this blog I realize that there are significant improvements over the initial code that I wrote. It solves the same problem but it is more readable, partly because it is about half of what I started with and partly because I've been through this once before and know more about the problem and the intent of the method. I also realize that there was some duplication in my original code so I made sure the second time through to eliminate that duplication.
Turning my mind back to the original exercise I start to wonder, "Should all the code I write be written this way?" "Of course." I always do my refactoring at the end so the answer is "Yes!" The next question in my mind is, "Could I have gotten to this code with other refactorings?" I think I could have but I certainly see that deleting the code and starting fresh is a very valid and useful refactoring. I especially see its usefulness for those times when you get about hip-deep into something and think to yourself, "Man, this is crap!" Don't try to unwind the mess, just throw it away and start again. If you're doing your work in small, test-driven cycles you only have 15 to 20 minutes invested in the code anyway. After all if it was a mess to begin with you can only make it better.
2 comments:
Interesting idea. What would your opinion be of, instead of physically deleting the code, to simply starting a fresh new version of it (perhaps in a different package, or perhaps by starting a whole new project)? That way, at least if the second trial turns out worse than the first, you can still go back to the first.
This kind of smells like the turn off your brain and write methodology. I personally do not support that methodology. I prefer to think a little before I sit down and start that first class. Maybe sketch out some ideas on a piece of paper. I also prefer to turn on my brain while I'm writing and look for smelly patterns occuring in the code (before I get completely done). That way I can refactor as I go. I find that following this pattern has saved me a lot of deleting.
Post a Comment