Database legacy? Un ricordo del passato con TDDD

Essere in presenza di un database legacy può essere altrettanto frustrante quanto fare i conti con del codice legacy, e spesso anche di più. Una delle strategie per non scontrarsi con un database che costringe a forti compromessi e soprattutto per non ritrovarsi con un database che a causa della sua fragilità ha perso la sua consistenza concettuale, è di decidere lo schema solo nel momento in cui i nostri oggetti di dominio hanno assunto una forma pressoché stabile. In pratica la strategia è quella di cercare di minimizzare il cambiamento dello schema stesso. Tale strategia ovviamente ha forti limitazioni: sappiamo ad esempio che nel ciclo di vita di un’applicazione vi saranno sempre cambiamenti che la interesseranno, che spesso avranno un impatto anche sul database. Inoltre il mismatch impedance ci ricorda che è rischioso ignorare completamente il mondo relazionale.

Il problema è molto simile a quanto avviene quando si applica una strategia di Up Front Design sul codice. Perché quindi non provare ad adattare una soluzione simile? Perché cioè non dare vita ad un design evolutivo ed adattativo anche per quanto riguarda il database?

Scott Ambler ormai da qualche tempo sta studiando ed ha sperimentato con successo questoa soluzione dando vita ad un approccio Test Driven anche sul database: il Test Driven Development Database. Anche qui il passo fondamentale è il refactoring ed il lavoro di Scott è degno di nota proprio per la maggiore intrinseca difficoltà concettuale del refactoring sul modello dati. Per implementare il refactoring Scott suggerisce ad esempio di servirsi di trigger di infrastruttura che abilitano al refactoring in oggetto. Ad esempio supponiamo di voler rinominare una colonna da FName a FirstName. I passi da eseguire saranno quattro:

1. Introdurre FirstName come nuova colonna, con un semplice trigger che tenga allineato il valore di tale colonna con quello di FName.
2. Ribaltare su FirstName i valori di FName delle righe già su db.
3. Gradualmente convertire il codice di produzione affinché utilizzi la nuova colonna
4. Dopo avere effettuato i test del caso, eliminare la vecchia colonna ed il trigger

Quali test effettuare al passo 4.? Anche qui dobbiamo creare dei test di regressione a piccoli ed in modo incrementale, testando sia il “database code” (ad esempio stored procedure, funzioni, trigger, etc), sia gli aspetti più di interfaccia (ad esempio l’esistenza di tabelle, procedure, le definizioni di viste, etc). Stiamo quindi facendo un forte salto in avanti rispetto al solo testing del codice agganciato al db con strumenti quali utPLSQL.

Per un refactoring sostenibile nel tempo vengono a riscuotere un ruolo chiave i tool, così come accadde vari anno fa con l’avvento delle IDE di nuova generazione (Eclipse, IntellIDEA, etc.). La comunità open source si sta dedicando sempre con maggiore energia in questo ambito, credo comunque ci vorrà ancora del tempo per raggiungere i livelli che abbiamo oggi sul codice OO. Questa però non deve diventare una scusa per non cominciare a prendere quanto di buono è già stato fatto in questo ambito (si veda ad esempio utPLSQL per nominarne uno soltanto).

Avere un database malleabile (sia per l’aspetto di integrità dei dati che per quello di integrità della semantica) quanto il codice sarebbe infatti una grande conquista nella scrittura di applicazioni più facilmente mantenibili ad ogni livello.