General approach for dealing with LabVIEW spaghetti code
There are additional details of course, but here’s the general flow of fixing spaghetti code:
Review the existing documentation and interview someone who knows how the code works. This will help orient you, but without extensive documentation you’ll still have to crawl through the code because the devil’s in the details. And yet, even with extensive documentation, you might still need to rely on the code for the details if you don’t trust that the documentation reflects the actual code.
Re-write the code
Decide how much to re-use vs re-write. This involves diagnosing things like modularity, architecture, variable utilization, maintainability, and readability.
The code should be salvaged and/or re-written by a LabVIEW expert this time so that you don’t end up in a messy code situation again. That expert could be in-house or outsourced.
Acceptance testing / regression testing –
This phase is all about answering two questions:
- How do we know when it works?
- How do we know we didn’t break something?
The amount of modularity in the code drives the criteria for acceptance testing. If it is true spaghetti code, your acceptance test criteria is going to need to be more comprehensive because it will be difficult to know if a change in one location affected another part of the code. If there is some modularity, an argument can be made to reduce the scope of the acceptance testing to encompass only the areas impacted by the changes.