Urari: un gestionale
del 2013 riportato
a nuova vita.
Quattro sedi, decine di dipendenti,
un software che si inceppava.
Il cliente gestisce una catena di slow fast food a Torino, quattro sedi, personale variabile, turni da organizzare settimanalmente su più punti vendita. Da anni usano una web application custom per gestire i dipendenti e i relativi turni.
Quando sono arrivato, il software aveva un problema serio: ogni volta che si cercava di creare o modificare i turni, l'applicazione ci metteva troppo tempo a rispondere. Secondi di attesa che si trasformavano in minuti, operazioni che si bloccavano, dati che non si salvavano correttamente.
Il problema era aggravato da due fattori: il software era stato sviluppato nel 2013, con tecnologie e approcci di allora, e lo sviluppatore originale aveva abbandonato il progetto senza lasciare documentazione. Il cliente si trovava con un sistema critico per le operazioni quotidiane e nessuno a cui rivolgersi.
Capire un codebase del 2013
senza aggiungere debito tecnico.
Il lavoro più delicato non è stato il bug fixing in sé, è stato capire il sistema prima di toccare qualsiasi cosa. Codice scritto con le convenzioni di una decina di anni prima, senza documentazione, con logiche implicite che si capiscono solo leggendo il flusso completo.
- 01 —
Analisi del codice vecchio: prima di scrivere una riga, ho letto e mappato il codebase esistente, struttura del database, flussi applicativi, punti critici. L'obiettivo era capire come funzionava realmente, non come avrebbe dovuto funzionare.
- 02 —
Identificazione dei colli di bottiglia: la latenza nella gestione turni aveva cause specifiche, query non ottimizzate, logiche ridondanti, operazioni che giravano in serie quando potevano girare in parallelo. Trovare la radice senza rompere nulla richiedeva molta attenzione.
- 03 —
Refactoring mirato: intervenire su codice legacy senza un piano preciso significa spostare i problemi, non risolverli. Ho riscritto selettivamente i componenti critici, mantenendo compatibilità con il resto del sistema e aprendo la strada alle nuove funzionalità richieste.
Due giorni per tornare operativi.
Poi si è costruito sopra.
Dopo il primo intervento — avvenuto in un paio di giorni — la web app è tornata a rispondere normalmente. La latenza nella creazione dei turni era sparita, il software era usabile, il cliente poteva tornare a lavorare senza interruzioni.
Blocco operativo risolto in 48 ore — il software critico è tornato funzionante in tempi rapidi.
Codebase legacy stabilizzato — il sistema è stato aggiornato ed è manutenibile da chiunque abbia competenze PHP.
Nuove funzionalità integrate — flussi economici e nuovi moduli costruiti sopra una base solida, non rappezzata.
Il software abbandonato
non è software morto.
Progetti come Urari capitano più spesso di quanto si pensi. Un'azienda piccola o media costruisce un software su misura, funziona bene per anni, poi lo sviluppatore scompare o non è più disponibile. Il sistema diventa un oggetto misterioso: nessuno sa come funziona dentro, nessuno sa come toccarlo.
La capacità di leggere codice scritto da altri, anche vecchio e senza documentazione è una delle competenze più utili in questo tipo di lavoro artigianale.
Lavorare su software legacy insegna a distinguere tra "codice scritto male" e "codice pericoloso da toccare". Spesso le due cose non coincidono. Il refactoring efficace non è riscrivere quello che non piace, è capire cosa può essere cambiato senza rischi e cosa va lasciato stare, almeno per ora. Questa valutazione è tanto tecnica quanto strategica.
«Il problema più grave che avevamo era un blocco totale nella gestione dei turni: ogni volta che provavamo a creare o modificare un turno, il sistema si bloccava per minuti, rendendo impossibile organizzare il lavoro. Inoltre il programmatore che lo aveva creato nel 2013 era sparito, quindi eravamo completamente bloccati. L'intervento di Denis è stato rapido e efficace: ha capito il codice del programma e in due giorni ha risolto il problema critico. Da lì è stato un lavoro di rifinitura e miglioramento continuo, ma la parte più importante è stata quella prima fase: senza di lui saremmo rimasti bloccati per chissà quanto tempo, con un software che non funzionava e nessuno a cui rivolgerci.»
Non sai ancora da
dove iniziare ?
Il primo passo è una valutazione tecnica per capire il contesto, i vincoli e se abbiamo la visione allineata per lavorare bene insieme.
Call di 15–20 minuti. Nessun impegno, nessun preventivo al buio.