Molti progetti LabVIEW sviluppati prima del 2010 si basano su più cicli While paralleli che comunicano tramite variabili globali. Sebbene questo approccio potesse funzionare all’epoca, presenta oggi limiti architetturali significativi.
Le variabili globali rendono il codice vulnerabile a race condition, con conseguenti malfunzionamenti intermittenti e difficili da riprodurre. Questi problemi sono notoriamente complessi da individuare e possono compromettere la stabilità dell’applicazione, soprattutto quando il sistema cresce o viene modificato.
Criticità da affrontare
A complicare ulteriormente la situazione, questi sistemi legacy spesso mancano di:
- Requisiti documentati
- Documentazione adeguata
- Struttura modulare o scalabile
Nella maggior parte dei casi, solo lo sviluppatore originale — quando ancora disponibile — è in grado di orientarsi nel sistema, affidandosi più alla memoria che alla chiarezza del codice. Quando arriva il momento di aggiornare l’hardware o introdurre nuove funzionalità, i problemi sono praticamente inevitabili.
Una nuova era per l’architettura LabVIEW
Intorno al 2008 la situazione ha iniziato a cambiare. Con l’introduzione delle code (queues) e del modello Queued Message Handler (QMH), NI ha iniziato a guidare gli sviluppatori verso architetture più strutturate e modulari. Da allora sono emersi framework più solidi, come:
- DQMH (Delacor Queued Message Handler, ora DQMH Consortium, dal 2019)
- Actor Framework (NI, dal 2012)
- Modelli basati su Workers di Scarfe Controls (dal 2012)
Queste architetture favoriscono pratiche di sviluppo più robuste: disaccoppiamento, riutilizzabilità, manutenibilità e scalabilità.
Il Ciclo del Refactory
Come pianifichiamo
Organizziamo il lavoro in tre momenti chiave:
- Sprint Plan: durante la pianificazione dello Sprint definiamo le priorità e gli obiettivi.
- Nel corso dello Sprint: svolgiamo revisioni del codice per garantire qualità e coerenza.
- Dopo rilascio in produzione: analizziamo eventuali debiti tecnici (Tech Debt) e lacune funzionali (Functional Gap), così da migliorare nei cicli successivi.
💡 La nostra raccomandazione
Se il tuo software LabVIEW risale ai primi anni 2000, è il momento di valutare un refactoring o una modernizzazione dell’applicazione. Preservare il valore del tuo software significa garantirne basi solide e moderne.
