“Avrei potuto usare Visual Basic, Java o C# e risparmiare tempo. Ma non sarebbe stato il mio software.”
Negli anni in cui lo sviluppo software si orientava sempre più verso la rapidità e l’astrazione, io ho fatto una scelta controcorrente: scrivere tutto in codice nativo. Non per nostalgia, ma per principio tecnico ed estetico.
Velocità reale, non simulata
Le macchine virtuali promettono portabilità, ma spesso sacrificano prestazioni. Il mio software gestionale doveva essere reattivo, leggero, preciso. E solo la compilazione nativa mi dava quel controllo millimetrico sulla memoria, sul flusso, sull’ottimizzazione.
Un esempio concreto è l’uso di liste virtuali per la gestione dei dati: caricano solo le righe visibili, direttamente dal database, garantendo una velocità incredibile anche con dataset enormi. Ogni lista può contenere oltre 100 milioni di righe, senza compromettere la fluidità dell’interfaccia. I dati vengono gestiti tramite ATL e messi in memoria in modo selettivo: solo quelli visibili vengono caricati, con un enorme risparmio di RAM. E anche se oggi le memorie sono gigantesche, questa scelta rende il software ancora più veloce e reattivo.
Connessione a basi dati eterogenee
Un altro vantaggio del codice nativo è la possibilità di collegarsi a diverse basi dati tramite OLEDB. Attualmente uso Access e SQL Server, ma con i client giusti si potrebbe accedere anche a MariaDB, PostgreSQL o persino a sistemi legacy come AS400. Questo approccio garantisce flessibilità e compatibilità, mantenendo prestazioni elevate e controllo diretto sul flusso dei dati.
Interfacce pensate, non imposte
Le GUI generate da ambienti come Visual Basic o Java sono comode, ma impersonali. Io volevo interfacce che parlassero all’utente, che fossero belle nella loro semplicità, costruite pixel per pixel, evento per evento. Ogni finestra, ogni pulsante, ogni icona è frutto di una scelta, non di uno standard imposto.
Ribbon bar: chiarezza funzionale e scalabilità
Nel mio approccio alle interfacce, ho scelto spesso la ribbon bar per i software gestionali come MerciGest e ThermoCal. Non per imitare MS Office, ma per ridefinirla con rigore: ogni tab risponde a un argomento preciso — magazzino, fatture, ordini — evitando dispersione e confusione. Se strutturata bene, la ribbon bar diventa una mappa mentale del software, dove l’utente si orienta con naturalezza. Inoltre, è una soluzione che permette di ampliare il programma senza compromettere la chiarezza: ogni nuova funzione trova il suo posto, senza stravolgere l’esperienza.
Personalizzazione dell’interfaccia con semplici sottoclassi
Un altro vantaggio del codice nativo è la possibilità di personalizzare ogni elemento dell’interfaccia tramite semplici sottoclassi. Questo approccio consente di estendere il comportamento di controlli standard, aggiungere funzionalità, modificare l’aspetto grafico e gestire eventi in modo preciso. È una tecnica che uso regolarmente per rendere ogni finestra coerente con il contesto funzionale, senza dover reinventare tutto da zero.
Un esempio concreto è la finestra di selezione clienti: ho creato una sottoclasse del controllo listview che mostra solo i dati visibili, con colonne personalizzate, icone contestuali e ordinamento dinamico. Ogni interazione — doppio clic, tasto invio, selezione multipla — è gestita direttamente, senza passaggi intermedi. Questo rende l’interfaccia fluida, coerente e perfettamente integrata con la logica del gestionale.
Usabilità reale, non simulata via web
Molti utenti pensano che per accedere a dati condivisi online sia necessario usare applicazioni web-based. Ma questa è una semplificazione fuorviante. I miei software, pur essendo nativi, possono collegarsi a dati ospitati su server remoti, come Azure, AWS o qualsiasi altro servizio cloud. Questo permette di mantenere un’interfaccia veloce, coerente e usabile, senza sacrificare la condivisione o la sincronizzazione. Inoltre, i controlli web-based sono spesso poco usabili, lenti, e privi di coerenza visiva: io preferisco controlli nativi, pensati per l’utente, non per il browser.
Una filosofia di sviluppo
Scrivere in codice nativo è come scolpire: richiede tempo, attenzione, ma il risultato è un’opera unica, non un assemblaggio. È il modo in cui ho sempre concepito il software: come estensione del pensiero umano, non come prodotto industriale.
Verso un’interazione naturale con l’utente
L’evoluzione futura dei miei software è dialogare direttamente con l’utente per l’inserimento dei dati. Non solo tastiera e mouse, ma voce: parlare al programma, dettare comandi, descrivere operazioni. Questo sarà possibile grazie all’intelligenza artificiale, che permetterà di interpretare il linguaggio naturale e tradurlo in azioni concrete. Un gestionale che ascolta, capisce e agisce: questa è la prossima frontiera.
Nota finale
La velocità di calcolo nei software gestionali è un fattore cruciale. Ma non si deve inseguire la velocità affidandosi a hardware sempre più costoso. La vera ottimizzazione nasce dal codice ben scritto, dalla gestione intelligente della memoria, e da scelte architetturali consapevoli. È qui che il codice nativo dimostra tutta la sua forza: prestazioni elevate, controllo totale, e sostenibilità tecnica.
Seguimi su LinkedIn
Seguimi su Facebook
