I’ve taken an interest in improving legacy software. I use the term legacy broadly here, to refer to software that does something in an outdated way.
It is possible to spend many hours and days trying to figure out WHY a bug occurs. Lately, I’ve decided that the fine detail of why the bug occurs doesn’t matter in some cases. That’s right, it doesn’t matter.
All you need is a deep understanding of the problem.
If the problem is that the data going into a function is good but the data coming out of that function is bad, then you can simply replace that function with your own function.
You just have to make sure that you perform all of the necessary actions of that function, so that you don’t mess up any other aspects of the program by accident. THAT is the tricky part!
Or, your wrapper can just do the really important buggy part of that function and then you might call the original function afterwards, so that your bug fix only adds something extra. Performing careful code changes in a complex system can be similar to surgery. You don’t want to excise too much, as that could cause other, new bugs.
When should you use a wrapper?
- When you can’t change the buggy code because it’s outside of code that you control. For example, the bug may be in the framework, NPM package, WordPress core or third-party plugin, other library or dependency, or, operating system, browser, etc.
- When it would take too much development time to rewrite the code in question. Everyone loves a quick fix.
I love elegant software design, but at the same time I’m happy to have a fix that works any day of the week.
If you’re interested in learning more about software design, you may enjoy Head First Design Patterns.