As developers we are always eager to learn new things and better ourselves at what we do.
You’ve all had moments when you look at your old code and get that feeling:
“WTH, I can’t believe I used to write code like this“
Well, when it comes to long term projects that you’re working on, what do you do when you look at your old code? You probably have learnt new techniques that you didn’t use when you started the project. So you probably are very eager to refactor or restructure, or swap out modules in your project.
But when is the right time to do this, and how often do you do this?
Also, there are risks involved if you do some major refactoring. There’s also budget constraints so you may have the urge to make changes but your project manager won’t give you the time to do so.
How do people approach such situations?
4
what do you do when you look at your old code
When I look at that code, and the code is working in production, without any bugs, with no new requirements and adequate performance – I do nothing. Never!
When I have to maintain or evolve that code, because of bugs or new requirements, then I follow the boy scout rule – leave the code always in a better state behind than the state it was before.
The (sometimes) hard part is: to decide how much refactoring should be applied, how big the scope of the refactoring should be, and how much is enough. To get this right is what makes the difference between an unexperienced and an experienced programmer. I won’t elaborate this more here, since there already a lot of posts and articles on the web where this topic has been discussed in detail, see for example here:
- How much time should I dedicate to refactoring my code?
- http://c2.com/cgi/wiki?WhenToStopRefactoring
- https://stackoverflow.com/questions/455271/how-do-you-stop-yourself-from-refactoring-working-but-awful-code
0
But when is the right time to do this, and how often do you do this?
The right time is when the old and bad code is actually causing problems, or is becoming so difficult to maintain that the cost of not refactoring is greater than the cost of refactoring, which thankfully does not happen often (at least not in my experience).
Generally, if it ain’t broke, don’t fix it. Changing working code simply for the sake of making it “nicer” is risky.
Also, there are risks involved if you do some major refactoring?
Yes. If you change your code siginificantly, you must ensure that it works the same as before. Automated unit tests can help with this.