LabVIEW
LabVIEW Project Refactoring of Spaghetti Code
I am very sorry you have to deal with this. It won't be easy. Will it be worth it?
What does "inherited" mean. Does it meant that you have to do significant changes in the future or does it just mean that you are tasked to fix minor bugs discovered by customers?
Does the code currently work well? (not obvious race conditions, bugs, performance, etc.)
Do you understand the basic flow and functionality as currently implemented?
Do you have ways to fully validate functionality after any code change?
I have had projects like this and it's certainly no fun. Unfortunately, sometimes it's easiest to just document what you can and start from scratch. Move segments from the spaghetti version to the new version if you can, but otherwise just rewrite.
The last one I did was luckily "organized" chaos over the multiple screens, so the wires weren't crossed but they weren't labeled either!
Without seeing your code it's hard to give a good strategy, but here are some thoughts:
0- Document what the program is SUPPOSED to do and see if the program appears to do that thing! Bad programming might "accidentally" work now, but refactoring could reveal an existing race condition.
1- Pick an area of the BD and simplify it, then pick another one. Don't try to do the whole thing at once; do it in stages.
2- Don't try to "finish" a section in its entirety before moving on. You may replace a section with a subVI, then later that subVI will turn out to not be necessary. You may be able to eventually replace several sections with one modular subVI, but don't try to do that out of the gate unless you can really see an obvious reason to.
3- At the end of this you need to have zero global variables*. Start by picking a global variable and finding all instances of it (Ctrl-F is your friend!). Figure out what the global is doing and try to eliminate one instance of it at a time by replacing it with the right wires. You don't have to kill all instances at one time; you can kill one or two of global A, then one or two of B, then all of C, then back to A, etc. Untangling the spaghetti will take a multi-pass approach.
*The exception to this is "Write once read many" globals that contain non-changing configuration data, like language localization or something. I prefer to not use these, but it's definitely an OK usage.
4- Add a shift register and a "locals" cluster that you can begin passing to subVI's. This will let you replace lots of globals and will let you replace strict property nodes with generic property nodes that take a control reference.
5- Remember, you're going to go through all of the diagram about 100 times. Don't try to clean any one thing entirely at one time.
6- Add LOTS of wire labels to ensure you know what wire does what.
7- Remember, you're going to go through all of the diagram about 100 times. Don't try to clean any one thing entirely at one time. 😉
Good luck. I don't think VI Scripting would generally help me very much here.
Luckily, I have not had to do this for a while. In at least 2 instances, I replaced a PC with a cRIO (the determinism was a requirement). So those were obvious rewrites. Another that enters my brain I rewrote because I had to upgrade from Traditional DAQ to DAQmx (old XP machines to Windows 10). I know I've had others, but they aren't immediately coming to the front of my brain, some of which were general clean-ups.
Rule 1: Know your requirements. Find out exactly what the program is supposed to do. Talk to those who use it. I guarantee they will have plenty of feedback for you (this doesn't work, that is too slow, this feature isn't needed, this work flow is stupid, I really wish it did this, etc.). From there, you can decide if you need to rewrite or if you think you can patch something in the current code.
@crossrulz wrote:
Rule 1: Know your requirements. Find out exactly what the program is supposed to do. Talk to those who use it. I guarantee they will have plenty of feedback for you (this doesn't work, that is too slow, this feature isn't needed, this work flow is stupid, I really wish it did this, etc.). From there, you can decide if you need to rewrite or if you think you can patch something in the current code.
100 times this.
Although, I've had plenty of experiences where the people using the software were perfectly fine with "the old way" of doing things and didn't ask for a better way, simply because they weren't aware there could BE another way.
If you see something that could be improved, bring it up to them and ask if they'd like that instead. Often they'll go "Holy cow, yes, I didn't know you could change that!"
@BertMcMahan wrote:
@crossrulz wrote:
Rule 1: Know your requirements. Find out exactly what the program is supposed to do. Talk to those who use it. I guarantee they will have plenty of feedback for you (this doesn't work, that is too slow, this feature isn't needed, this work flow is stupid, I really wish it did this, etc.). From there, you can decide if you need to rewrite or if you think you can patch something in the current code.
100 times this.
Although, I've had plenty of experiences where the people using the software were perfectly fine with "the old way" of doing things and didn't ask for a better way, simply because they weren't aware there could BE another way.
If you see something that could be improved, bring it up to them and ask if they'd like that instead. Often they'll go "Holy cow, yes, I didn't know you could change that!"
I guess the flip side of the coin is "don't fix what's not broke". Try to leave the dataflow alone until you are sure you won't break something by eliminating a race condition, for instance. I've seen badly written code depend on race conditions to work. Creating a subVI is a subtle way of eliminating race conditions, so create subVIs with care. This is often the case with "spaghetti code".
If you can get funding to rewrite it from scratch (and you feel comfortable doing so!) then it MAY be the way to go. Couldn't say without seeing your code.
That said, if it's bad-but-working, then you have some tactics you can try. We have an old program like that around here. It was written in, I think, LV5 (!) and has been incrementally updated for 15+ years. Unfortunately, since it *does* actually work, there's never a budget for a full rewrite.
My tactic for this has been a very slow piecemeal approach. When someone asks for a new feature, I estimate how long I think it'll take, then double or triple it, depending on the complexity of the new feature. With a program like that, it's *very* tricky to update.
If I can get approval, I'll implement the new feature first, but if I have time left over in the allotted budget I'll fix or refactor something else while I'm in there. If I end up needing all of the estimated time, then that's fine too as I added a reasonable buffer for my estimate.
Over the years, the program has been slowly but steadily morphing into something SLIGHTLY less horrible to debug and use. It still needs a rewrite, but lots of things have been updated under the hood that really help make it work better.
