C'è qualche speranza di scrivere un buon codice su un database progettato in modo orribile?

18

Ecco la mia situazione. Uno dei numerosi programmi che ho ereditato di recente è costruito con un database orribile nel back-end. A quanto pare, i suoi stimati creatori non apprezzavano i concetti relazionali. Una tabella per ogni singolo cliente, indicata come ID cliente univoco. Ottantatré campi con nomi criptici. Il codice è tutto procedurale con dozzine di istruzioni SQL inline concatenate.

Dato che non ci è stata fornita un'importante applicazione ausiliaria che esegue lo stesso database, sono stato incaricato di ricreare tutto da zero. Sono un unico sviluppatore, che non è nemmeno la mia responsabilità principale in quanto almeno la metà del mio tempo è occupata da operazioni. È previsto un termine di scadenza inevitabile tra 30 giorni.

Nonostante la mia inesperienza, sono certo che avrei potuto progettare questo database e l'applicazione esistente molto meglio di loro, ma non penso davvero che sia realistico per me modificare il database, regolare l'applicazione esistente ed essere sicuro Non ho infranto nulla pur avendo bisogno di creare rapidamente l'applicazione aggiuntiva.

Quindi supponiamo di essere bloccato con il terribile database. Avendo bisogno di lavorare con una struttura così cattiva, tutto ciò che scrivo è conforme al cumulo di debito tecnico che deve essere accantonato fino a quando qualcosa non si rompe completamente o sono necessarie nuove funzionalità? Come potrei approcciare a questa situazione e ricavarne qualcosa di buono oltre a un'applicazione sperabilmente funzionale?

modifica: nel caso in cui qualcuno fosse interessato, abbiamo finito con lo smantellare questo orribile database e l'applicazione che si stava verificando. Abbiamo esternalizzato la creazione della domanda ausiliaria (non ero coinvolto nella creazione di questo) in definitiva a due diversi appaltatori che hanno finito per cadere su di noi, senza realizzare nulla. Ho finito per scappare da un attacco orribile, parzialmente funzionale, di una correzione in tre giorni che è ancora in uso oggi.

    
posta John Straka 02.06.2011 - 16:33
fonte

6 risposte

27

C'è speranza, ma è una battaglia in salita, soprattutto se nessuno si rende conto che il design del database è orribile. Puoi provare ad astrarre la cattiveria con i livelli di astrazione, ma è probabile che non valga la pena della battaglia.

Il mio consiglio sarebbe di creare abbastanza astrazioni sul database che l'applicazione stessa sia pulita e progettata correttamente; in questo modo se puoi sempre correggere il database, l'applicazione non ne risentirà poiché non gli interessa come è stato progettato il database.

Questo è l'approccio che uso normalmente quando si ha a che fare con un database che è installato e, il più delle volte, progettato con zero pensiero. Alcune applicazioni di scelta dei modelli di repository o gateway, con alcuni livelli di servizio per comunicare con il gateway / repository, dovrebbero aiutare a mettere in quarantena il design scadente.

    
risposta data 02.06.2011 - 16:43
fonte
10

Costruisci un livello di interfaccia che gestisca tutte le cose del database, quindi scrivi la tua app per interfacciarlo. Nel caso in cui il database venga "riparato", basta semplicemente sostituire / aggiornare la tua "interfaccia". Questo approccio mi ha permesso di risparmiare un sacco di tempo quando si trattava di un cattivo database o di un database che alimentava altre applicazioni e non poteva essere modificato.

    
risposta data 02.06.2011 - 16:49
fonte
6

Ahi ... Hai ereditato un casino da incubo, hai 30 giorni per renderlo utilizzabile per la tua organizzazione e metà della tua giornata è occupata da attività operative?

Sono sicuro che potresti refactoring ma certamente non in quel lasso di tempo.

Per rispondere alla tua domanda, non penso che tu possa effettivamente scrivere un buon codice su un tale progetto. Il debito tecnico è già troppo. Se fossi in te, modificherei le funzionalità che potrei, e premerò per un completo refactoring in un secondo momento, quando avrai più tempo e persone nella tua squadra per affrontarlo meglio.

Fai attenzione a spingere per il refactoring. A volte un superiore prenderà la decisione di acquistare un codice sorgente di prodotti e diritti di proprietà e non vogliono pensare di aver completamente sprecato i loro soldi in spazzatura. Questo è stato il mio caso per un lavoro che ho avuto. Sfortunatamente i manager prendono decisioni sull'acquisto di software come questo e non ottengono mai un coinvolgimento tecnico per valutare cosa stanno acquistando e vedere se è manutenibile e ha una grande quantità di debito tecnico. In questo caso, la decisione sbagliata è politica e spingere per il refactoring può mettere a repentaglio il tuo lavoro.

    
risposta data 02.06.2011 - 16:55
fonte
6

I database possono essere rifattorizzati come un altro codice. Correggere la parte interessata dal codice che è necessario scrivere e scrivere test per assicurarsi che nient'altro si interrompa. Fai un piccolo pezzetto alla volta come qualsiasi altro refactoring. C'è un buon libro sul refactoring del database che potrebbe aiutarti a iniziare a ripulire il casino. link

Ce ne sono anche altri, ma io personalmente ho letto e lavorato con le tecniche in questo.

E non dimenticare che puoi ristrutturare il modo in cui hai bisogno di interrogare il database creando viste per fare il lavoro di trasformazione per te in una struttura che è più facile da interrogare.

    
risposta data 02.06.2011 - 16:44
fonte
5

Per ottenere il più grande successo, crea viste aggiornabili per ripristinare parte della "relazionalità" e fornire nomi di colonne più significativi.

    
risposta data 02.06.2011 - 19:22
fonte
4

Una possibilità potrebbe essere quella di creare un secondo database strutturato (almeno più vicino a) come lo si desidera e impostare la replica tra i due database. Quindi puoi scrivere il tuo codice contro il nuovo database e lasciare il database (e l'applicazione) esistente intatto, da gestire quando hai più tempo.

Sinceramente, è ancora aperto a un lotto di dubbio se puoi farlo in ~ 15 giorni di lavoro. In particolare, è probabile che dipenda dal fatto che sia necessaria la duplicazione a due vie (ad esempio, la nuova applicazione aggiornerà effettivamente i dati) o solo in un modo (la nuova applicazione consente semplicemente alle persone di visualizzare i dati). L'ultimo caso è (ovviamente) molto più facile da gestire.

Se hai bisogno di una replica a due vie, è probabile che non sia abbastanza tempo per fare il lavoro. In particolare, la replica a due vie che implica la trasformazione sostanziale della struttura non è mai banale e gli strumenti disponibili spesso la supportano in modo piuttosto scadente (ad esempio, dovendo scrivere a mano tutto l'SQL per tutte le trasformazioni di dati in entrambe le direzioni).

Se hai bisogno solo di una via, è proprio al punto che potrebbe limitare il possibile. Dipenderà anche un bel po 'dal fatto che sia permesso o meno spendere soldi - ci sono alcune applicazioni di data warehousing che sono pensate per esattamente questo tipo di compito che probabilmente farebbe è un po 'più veloce e facile da gestire, ma la maggior parte di loro sono non a buon mercato.

    
risposta data 02.06.2011 - 17:02
fonte

Leggi altre domande sui tag