Ho visto aziende buttare via mesi di lavoro e decine di migliaia di euro perché convinte che migrare o mantenere un sistema basato su Harbour fosse una semplice operazione di ricompilazione. Ricordo un cliente, una media impresa metalmeccanica del Nord Italia, che decise di aggiornare il proprio software gestionale interno scritto originariamente in Clipper. Pensavano che bastasse passare al nuovo compilatore per risolvere i problemi di compatibilità con i moderni sistemi operativi a 64 bit. Hanno assegnato il compito a un programmatore junior che conosceva solo Java e Python. Dopo tre mesi, il sistema crashava costantemente durante l'indicizzazione dei file DBF, i report di stampa erano illeggibili e l'azienda è rimasta ferma per due giorni interi, perdendo ordini per un valore stimato di 40.000 euro. Il problema non era lo strumento, ma l'illusione che l'automazione potesse sostituire la comprensione profonda della gestione della memoria e dei lock dei file.
Pensare che Harbour sia solo un vecchio cimelio per nostalgici
Molti manager tecnici commettono l'errore di considerare questo ecosistema come un vicolo cieco tecnologico. Vedono il codice e pensano agli anni '90. La realtà è che Harbour è un compilatore moderno, open source e cross-platform che permette di far girare logiche di business complesse su Windows, Linux e macOS. L'errore fatale è trattarlo come se fosse un pezzo di antiquariato da chiudere in una teca invece di sfruttare la sua capacità di interfacciarsi con il C e il C++.
Se approcci il progetto con l'idea di "tirare a campare" finché non avrai i soldi per riscrivere tutto in una tecnologia web moderna, hai già perso. La riscrittura completa di un software gestionale che ha accumulato vent'anni di regole fiscali e logiche di magazzino richiede anni, non mesi. Ho visto progetti di migrazione verso il cloud fallire miseramente perché non avevano considerato la precisione del calcolo decimale o la velocità di accesso ai dati locali che questo ambiente garantisce. Invece di scappare, dovresti integrare. Usa questa tecnologia per quello che sa fare meglio — gestire dati massivi e logiche procedurali — e affianca interfacce moderne o API REST dove serve. Non è un limite, è un ponte.
La gestione dei file DBF e l'incubo della corruzione dei dati
Il mito degli indici indistruttibili
Uno degli errori più costosi che ho osservato riguarda la gestione della concorrenza sui file di dati. Chi viene dai database relazionali come SQL Server o PostgreSQL pensa che il motore gestisca tutto. Qui non c'è un server che media; c'è il tuo eseguibile che parla direttamente con il file system. Molti sviluppatori dimenticano di configurare correttamente i lock dei record o, peggio, utilizzano driver RDD (Replaceable Database Drivers) non adatti al carico di rete.
Ho visto un ufficio contabile perdere l'intero bilancio annuale perché il software non gestiva correttamente i conflitti di scrittura su una rete Windows mal configurata (con l'opzione "oplocks" attiva sul server SMB). La soluzione non è sperare che non succeda, ma implementare routine di validazione degli indici all'avvio e utilizzare sistemi di log delle transazioni. Se non hai un piano di emergenza che preveda la ricostruzione automatica dei file CDX o NTX in meno di cinque minuti, il tuo sistema è una bomba a orologeria.
Ottimizzare Harbour per le moderne architetture hardware
Il codice scritto vent'anni fa non è stato pensato per processori multi-core o dischi NVMe. Un errore comune è mantenere le stesse routine di polling che consumano il 100% della CPU mentre aspettano un input dall'utente. È un comportamento che distrugge le prestazioni dei server Terminal Services o Citrix, dove decine di utenti condividono le stesse risorse.
Dalla mia esperienza, la soluzione pratica consiste nel rivedere i cicli di attesa inserendo funzioni di idle che rilasciano il controllo al sistema operativo. Sembra un dettaglio tecnico da poco, ma in un ambiente con 50 utenti collegati, questo accorgimento può dimezzare il carico sul server, risparmiandoti l'acquisto di nuovo hardware inutile. Non servono macchine più potenti, serve codice che non sprechi cicli di clock inutilmente.
L'illusione della compatibilità totale senza refactoring
Prima: Il disastro della migrazione pigra
Immagina un'azienda che prende il vecchio codice Clipper 5.2 e lo compila direttamente. Funziona? Forse. Ma poi scoprono che la gestione della memoria è instabile. I puntatori non vengono rilasciati. Le variabili "Public" e "Private" creano collisioni inaspettate in un ambiente multithread. Il risultato è un software che sembra funzionare ma produce errori di calcolo casuali ogni mille operazioni. È l'incubo di ogni responsabile finanziario: i conti non tornano e nessuno sa perché.
Dopo: L'approccio del professionista consapevole
Il programmatore esperto, invece, inizia isolando la logica di business dalla UI. Trasforma le vecchie procedure in classi o funzioni "Thread-safe". Introduce un sistema di gestione degli errori centralizzato che scrive su file log dettagliati, includendo lo stato delle aree di lavoro e i valori delle variabili al momento del crash. Invece di usare i vecchi comandi grafici limitati, integra librerie che permettono di generare PDF nativi o comunicare con servizi web tramite JSON. Il software rimane lo stesso nel cuore, ma diventa affidabile, monitorabile e capace di dialogare con il mondo esterno. Il costo iniziale è più alto, ma il risparmio sulla manutenzione nei successivi cinque anni è del 70%.
Non sottovalutare la scelta delle librerie grafiche
Un altro errore che prosciuga i budget è la scelta della libreria GUI. Molti si buttano su soluzioni vecchie solo perché gratuite o perché sembrano facili. Poi si accorgono che non supportano l'alta risoluzione (HiDPI) dei monitor moderni o che hanno bug con le ultime versioni di Windows 11. Ho visto aziende costrette a riscrivere l'intera interfaccia per la seconda volta in due anni perché la libreria scelta era stata abbandonata dallo sviluppatore originale.
La scelta deve cadere su strumenti che abbiano una comunità attiva o un supporto commerciale solido. Non guardare solo alla bellezza dei bottoni. Guarda alla frequenza dei commit su GitHub o alla qualità del supporto tecnico. Se la libreria non viene aggiornata da più di dodici mesi, stanne alla larga. La stabilità del tuo software dipende da fondamenta solide, non da fronzoli estetici che smettono di funzionare al prossimo aggiornamento di sistema.
La trappola del fai-da-te nella sicurezza dei dati
In Italia, con le normative GDPR e le ispezioni del Garante, non puoi più permetterti di tenere i dati in chiaro in semplici file DBF accessibili a chiunque apra la cartella di rete. L'errore che ho visto commettere più spesso è pensare che la password dell'applicazione sia sufficiente. Se un dipendente può copiare il file dei clienti su una chiavetta USB, la tua azienda è legalmente scoperta.
La soluzione non è criptare i file manualmente con algoritmi scritti in casa — un errore che ho visto fare spesso, portando a performance disastrose e file irrecuperabili dopo un crash. La strada corretta è l'adozione di driver che supportino la crittografia AES a livello di file system o, meglio ancora, la migrazione verso un'architettura client-server dove Harbour comunica con un database SQL. Non devi buttare via il tuo codice; devi solo cambiare il modo in cui legge e scrive i dati. Esistono librerie specifiche che permettono questa transizione senza riscrivere ogni singola riga di codice, mantenendo la sintassi a cui sei abituato ma garantendo la sicurezza richiesta oggi.
Gestione delle dipendenze e build process amatoriali
Ho perso il conto delle ore passate a cercare di compilare progetti dove le dipendenze erano sparse in dieci cartelle diverse sul PC di un ex dipendente. Se il tuo processo di build dipende da "quel particolare computer in magazzino", hai un problema serio. Molte aziende falliscono nel creare un ambiente di sviluppo riproducibile.
Devi usare script di build chiari (come hbmk2) e sistemi di controllo versione come Git. Non è opzionale. Se non puoi ricreare l'intero eseguibile da zero su una macchina pulita in dieci minuti, stai rischiando il futuro del tuo prodotto. Ho visto un'azienda perdere il codice sorgente dell'ultima versione rilasciata a un cliente importante a causa di un disco fisso rotto e l'assenza di un repository centralizzato. Hanno dovuto pagare un consulente esterno (me) per fare il reverse engineering del proprio software. È un costo che non avrebbero mai dovuto sostenere.
Controllo della realtà
Smettiamola di raccontarci favole. Se pensi che lavorare con Harbour sia un modo economico per evitare di evolvere, ti sbagli di grosso. Richiede una competenza tecnica specifica che sta diventando rara e, di conseguenza, costosa. Non troverai facilmente programmatori pronti all'uso sul mercato; dovrai formarli o pagare profumatamente i pochi senior rimasti.
Il successo con questa tecnologia non deriva dal risparmio, ma dalla sua incredibile efficienza operativa se gestita da mani esperte. È uno strumento di precisione, non un giocattolo per dilettanti che vogliono risparmiare sulle licenze dei database. Se non sei disposto a investire tempo nella pulizia del codice, nella messa in sicurezza dei dati e nella creazione di un processo di sviluppo moderno, faresti meglio a chiudere tutto e comprare un software standard già pronto. Ti costerà meno nel lungo periodo. Ma se hai un sistema verticale che è il vero cuore pulsante della tua operatività, allora usalo correttamente. Smetti di trattarlo come un peso morto del passato e inizia a gestirlo con il rigore che si deve a un'infrastruttura critica. La tecnologia non è mai il problema; lo è quasi sempre la mancanza di una strategia di manutenzione seria e professionale.
L'unico modo per non fallire è smettere di cercare scorciatoie. Non esistono plugin magici che trasformano un vecchio codice disordinato in un'applicazione moderna con un click. Esiste solo il lavoro metodico di refactoring, la protezione rigorosa dei dati e la comprensione dei limiti fisici dell'hardware su cui il tuo codice deve girare. Fallo bene, o non farlo affatto.
