This short series of blogposts answers the “why”, “how” and “when” of code refactoring.
This short series of blogposts answers the “why”, “how” and “when” of code refactoring.
If you are...
- a manager/client of a dev team who needs to understand why your team wants to spend time on things that don’t show immediately tangible results
- a developer who needs to explain to a manager or client why you need to spend some time on something with non-tangible results.
...then this blog post was made just for you!
Definition
“Code refactoring is the process of restructuring existing computer code (...) without changing its external behavior. Refactoring improves nonfunctional attributes of the software.”
Some clever guy on wikipedia.
That’s a bit complicated. Here’s the ELI5 version:
“Refactoring makes existing code better to work with - easier to read, debug, maintain and extend with new features.“
Me, when writing this blogpost.
Why do we need to do it?
There are few reasons:
-
upgrades over time
- Say it’s been a while since somebody touched part of an application and it’s out of date. Meanwhile, people figured out new solutions and better approaches to problems solved in that section. This code might now be obsolete.
- The old code might also be using libraries that are not maintained or perhaps are now non-existent.
-
upgrades - security
- Keeping your code up-to-date makes it easier to apply security patches when they are needed (i.e. bumping a version when a new framework-stable release comes out).
-
preparation for new, incoming features
- This is one of the most important reasons to do refactoring and also the most popular one. It’s not possible to predict exactly what will happen in the future. So, most code will have to be altered in different places to work with new things you need to implement. One is example is the number of comments on a blog. If you display the number of comments on the post page, it’s ok to do a simple “comments count” query for this post and the feature is done. After a while, you might also display the counts on the index page. But somehow, you’ll need to cache the comments count, so you don’t end up making a count query for every single post. Refactoring is needed for the new feature to be implemented properly.
Business value
Refactoring on it’s own does not have innate business value. With the small exception of performance optimization (which are a form of refactoring), your business won’t immediately get better once refactoring is done.
However, most of us walk the unhappy path of realizing how important refactoring is for business when it has mutated into a huge problem.
If you are the project owner, you might push your developers to squeeze in all features you want into the application without really caring if they are connected with the rest of the application correctly. A developer can easily and blindly implement everything they’re asked to do without communicating the need to refactor—in order to avoid conflict.
This will work for few weeks, maybe months, but then you realize that:
- it’s taking a long time to implement even the simplest thing
- there are a lot of bugs in your project
Even in the oversimplified blog example, refactoring presents a case for the exponential harm that skipping refactoring can cause. If the blog gets popular, it will get slower and and slower, until it kills the database with unnecessary queries. The feature itself worked, yet it came back to bite us hard.
Refactoring is a long-term view for business value, and there is a huge potential for value loss in not doing it.
In our next blogposts, we take on the “how” and “when” of refactoring - stay tuned!
