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...
...then this blog post was made just for you!
“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.
There are few reasons:
upgrades over time
upgrades - security
preparation for new, incoming features
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:
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!