Embrace Your Legacy Code. But Only Once
If you have to deal with legacy code (and we all do) one of the standard techniques to deal with it is to hide it behind a layer of abstraction.
While this is a valid pattern that helps in many cases, it comes with its own anti pattern.
I call it Legacy in an Onion.
It’s what happens when every generation of developer considers whatever they find to be horrible legacy code.
So they create a layer of abstraction. The next generation considers the abstraction to be legacy and adds another layer of abstraction.
After a couple of generations all the different layers start to cause serious problems when trying to understand the code and possibly even when executing it.
So the next time you encounter legacy code and want to add a layer of abstraction, rub the legacy code a little. Maybe you can peel of a layer of abstraction. If you find such a layer, you have multiple options:
- Improve it so it fits your needs
- Replace it with your layer
- Directly work with the stuff below the layer
Just don’t add a layer of abstraction just for the sake of adding a layer of abstraction.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)