Using metrics to find the pain points in a legacy codebase
When you are new to a codebase, you may realise that it’s new for you, but not new to the world. It’s code that has been around for ages and is hard to change, it’s hard to maintain. This is legacy code by definition, and it’s your job to work with it. Even if code hasn’t been around for long, or if it was perfect when the project started, it easily gets worse over time. I see it as the second law of thermodynamics, which says that the entropy of an isolated system does not decrease over time, but evolves towards an equilibrium of maximum entropy.
The entropy – or disorder – of large, badly tested classes which we are asked to change. In this post, I will explain how I like to approach such a codebase. Is it hopeless? If not, where do we start cleaning it up?