Il database legacy è l'unico che non mente (...e ti odia).

La verità è banale e scomoda: prima di toccare una riga di codice, devi capire il database. Ecco perché il refactoring fallisce.

Sai qual è la fase che tutti adorano dei progetti IT? La “riscrittura del software”. È sexy, è nuova, ti fa sentire come se stessi cancellando anni di schifezze, patch messe a caso e soluzioni creative disperate.

Peccato sia quasi sempre una gran bella bugia a fin di bene. La verità è banale e scomoda: prima di toccare una riga di codice, devi capire il database. E qui, amico mio, casca l'asino.

Benvenuti in soffitta (AKA il tuo DB)

I database aziendali sono come quelle soffitte che nessuno ha il coraggio di aprire. Ci trovi dentro cartoni ammucchiati da vent’anni, roba duplicata, regole sparse e pezzi di logica buttati lì a caso.

• Ogni team ha lasciato la sua bella “impronta”.
• Ogni consulente ha piantato un trigger “temporaneo” in giro.
• Ogni urgenza ha generato una scorciatoia che, sorpresa, è diventata per sempre.

Poi un giorno arriva il boss e dice: “Dobbiamo modernizzare”. Capire un DB legacy non è leggere un manuale. È farsi una maratona di un thriller. Il codice, fidati, può mentire: lo mascheri, lo riscrivi, lo spalmi in mille micro-servizi. Ma il database? Quello è l’unico punto che non bara. Tiene tutto, nel bene e nel male.

La radiografia è obbligatoria

Il database ti dice chi è chi e cosa è successo:

• Le chiavi primarie ti urlano cosa conta davvero.
• Le foreign key svelano relazioni che nessuno si ricorda più (o finge di non ricordare).
• Gli indici ti mostrano dove il sistema perde tempo prezioso.
• Viste e procedure raccontano i falliti tentativi passati di “fare pulizia”.

I Trigger: Il retrobottega dove nessuno vuole guardare

E poi ci sono i trigger. Ah, i trigger. Sono l'equivalente digitale del "favore" fatto al volo che è sfuggito di mano.

• Logica Nascosta: Invece di avere la logica di business nel codice, i trigger la nascondono nel cuore del database. Quando il developer legge l'app, non vede un tubo di quello che succede davvero.
• Veleno Silenzioso: Sono il retrobottega dove succedono le cose di cui nessuno vuole parlare. Spesso fanno cose in *background* innescando un effetto domino su altre tabelle. Rallentano tutto, ma l'errore non lo conosci e lo cerchi altrove.
• Il “Temporaneo” Definitivo: Molti sono stati messi lì da un consulente 12 anni fa come soluzione “temporanea”. Nessuno sa perché sono lì, ma toglierli fa una paura folle.

Il refactoring fallisce quando parti dal codice, perché stai mettendo il carro davanti ai buoi. Lo dico dopo anni di progetti deragliati: team eccellenti riscrivono l’applicazione facendo finta che il database sia un dettaglio. Peccato che quel dettaglio governi ogni singolo comportamento del sistema.

La catastrofe del lancio

Succede questo: la nuova app funziona benissimo in locale, poi arriva in produzione, tocca una tabella, parte un trigger antico come l'azienda... e il sistema esplode. E nessuno capisce perché.

Oppure:

• Scopri che una foreign key mai documentata blocca metà dei record. O che una vista “storica” si rompe.
• O che procedure scritte dieci anni fa fanno ancora il 70% del lavoro.

E lì capisci che stai navigando a vista. Non stai modernizzando: stai scommettendo.

Prima capisci, poi tocchi

Il primo passo non è programmare. È guardare (e magari capire). Prima di riscrivere, ti serve una radiografia del database. Una mappa. Non un disegnino fatto in fretta, ma un inventario vero che ti dica:

• quali tabelle esistono davvero (non quelle che “dovrebbero” esistere)
• come sono collegate
• quali trigger interferiscono con quello che farai dopo

Un tool come Pulse prende la soffitta e te la fa vedere in piena luce. Non risolve il problema, ma finalmente ti dice quali problemi hai. E fidati: sapere cosa non funziona è già metà del lavoro. Modernizzare non è “scrivere da zero”. Significa assicurarsi di non portarsi dietro i fantasmi. Senza un’analisi del database, stai solo copiando vecchi errori dentro un sistema nuovo. Il vero refactoring non lo fai con il framework del momento: lo fai leggendo con calma il cuore del sistema. Solo quando quell’immagine è chiara puoi scegliere che strada prendere. Ma senza questa fotografia, qualsiasi decisione è cieca.

Conclusione: la dura verità

Prima capisci, poi tocchi. Sempre. Pulse non fa magie e non modifica niente. Ti mostra com’è davvero il tuo sistema, senza miti, senza leggende aziendali, senza il bias di chi “ci lavora da vent’anni”. È un momento di verità.

Se stai per mettere mano a un database legacy, ricordati questa frase: non si può fare il refactoring di ciò che non si capisce. E non si capisce ciò che non si vede.