Lately, I’ve been refactoring some code for a software engineering project completed earlier this year and for which additional work is expected. As a result, I’ve come to the conclusion that doing occasional refactoring is an absolute must for any programmer.
I believe in always trying to do your best at whatever it is you do. For me, as a software engineer, that means striving to produce code that is reliable, maintainable and secure. In grade school and high school, we learn the writing process of “first draft, revision, final draft” but in college how many reports followed the “write, scream at printer to go faster, run to class” model? And for how many of us did that carry over into our professional lives and the kind of code we write?
If “the unexamined life is not worth living,” then what should we do with “unexamined code”? Let’s take a look at five reasons code refactoring is beneficial not only for the code you produce, but for you as a developer.
1. Poor code is like a debt that accrues interest
The longer it sits untouched and the further removed from it you become, the more you’ll pay for it when you eventually revisit it. Suppose you want to add a feature to an old program but it takes a week to untangle the logic and re-teach yourself how the program works before you can start adding code. If the developer tasked with doing this earns $50K annually, you’ve just spent nearly $1000 to simply have them look at it and remember how it works before they’re even able to start doing the work you requested! The original program may work perfectly, but if its style and documentation are cryptic or non-existent your maintenance costs will be dramatically higher.
2. Condensing code makes it more robust and improves security
When you repeat yourself in code, you introduce opportunities for inconsistency. Any modifications made down the road are going to necessitate knowing all the duplicate code sections that must be changed. If it’s not your code to begin with, there’s a higher chance you’ll introduce bugs by failing to update all the duplicate code blocks. Refactoring the code such that duplication is eliminated creates a “single source of truth”, allowing for more comprehensive testing and paving the way for better program security.
3. Refactoring using common patterns and naming conventions makes your code more portable
By “portable” I mean that you can give it to any developer with an awareness of such patterns and conventions and they will be much more efficient in understanding what the code is doing. Refactoring to patterns also makes the code easier to discuss in conversation because it provides a common language for describing well documented relationships and techniques within a program.
4. Refactoring is a learning tool
In psychology, the Levels of Processing theory of cognition, suggests that the degree to which we understand something is correlated to how frequently and deeply we interact with it. In the case of programming, we may have a good idea of how a program works by looking through it and reading the API, but there’s a whole new level of understanding that comes from breaking it, reworking it, and writing the documentation. By refactoring a piece of code, we become much more intimately aware of how it works. We also become more aware of our own bad habits. Having to go back through something we wrote in the past and deal with the results of those bad habits can help teach us to avoid some of them as we write new code.
We can also use refactoring as an occasion to practice implementing new techniques we have learned since the code was originally written. Instead of experimenting with a technique on “new work” that isn’t complete, it can be helpful to refactor an old completed project so that you can compare your outcomes against known results.
5. Refactoring is applied learning
The majority of us did not start out as rock star programmers and even if we did, the hope is that we’ve improved our skills as the years have gone by. Refactoring a project so that it reflects our current abilities and standards, not to mention industry standards, is a professional must. Of course, this assumes the old code is not as good as it could be. If the code is fine, then refactoring just for the sake or refactoring (and not as a learning tool) is pointless. The goal of refactoring is to make a program more understandable and maintainable.
Instead of viewing refactoring as simply going back to “fix mistakes”, I would suggest that it take on a larger meaning. Refactoring represents an investment in the future or your application as well as an investment in your developers. It can reduce the overall maintenance costs of your application and it can serve as a valuable learning tool for junior and senior developers alike.
I’m not suggesting that code refactoring is always appropriate or always necessary, but I am suggesting that it has many benefits that go beyond the obvious, and is an activity worthy of the time devoted to it. Refactoring not only produces better code, it produces better coders.
Next Steps:
- Contact SPK and Associates to see how we can help your organization with our ALM, PLM, and Engineering Tools Support services.
- Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
David Hubbell
Software Engineer
SPK and Associates
