Code rot. It sounds terrible, and let’s be honest, it is. It’s when your code’s quality and responsiveness deteriorates over time, which can lead to it becoming unstable and unusable. This spells big issues for your project, so you obviously want to prevent it. How do you go about doing so?
Why is your code rotting?
Before you learn how to prevent code rot, it’s best to understand why your code is rotting. Most of the time, it’s because you’ve neglected a part of the code. While this could mean that you’ve plain old forgotten about it, it could also mean that this piece of code was cutting-edge in 1995 and has yet to be updated.
What can be done to prevent it?
There are three keys to preventing code rot.
1. Performing Unit Tests
The most effective way to prevent code rot is to perform both class level and method level unit tests. As Martin Fowler said, “legacy code is code without automated tests.” By performing these unit tests, you can be sure that your test code is fresh, stable and useable. If it’s not, you’ve caught the problem before it gets worse.
Good results from unit tests also give you the confidence to perform refactoring. When a unit test indicates that the code works, you can then look at the code, see where it looks dirty, and have the confidence to move stuff around and simplify without the fear of breaking things elsewhere.
2. Reducing Complexity
Another preventative method is to reduce code complexity. By limiting the pieces of code that are dependent on other pieces of code, you’re less likely to make a change that will impact a variety of other areas. Lessening code interdependence explains why unit testing and refactoring are so important; refactoring allows you to remove duplications and simplify your code, while unit tests give you the confidence to do so.
The final way to prevent code rot is to hold your team to high documentation standards. When there are strict rules about commenting on code, where everything has to be commented on, and everyone has to do this, you’ll have documentation that better reflects code interdependencies. Developers will have a better understanding of how code changes will affect other areas of code, which may then prevent them from making changes that will create code rot.
If you take the time to perform tests, refactor, and document, you’re going to have a lot less code rot. And that’s good news for you, your team, and the future stability of this project.
Looking for more information like this? Check out other blog posts on this topic by clicking on the button below:
Thanks to stevendepolo for the use of their images.