La creazione e l'eliminazione continue delle tabelle sono un segno di un difetto architettonico?

Di recente ho avuto una discussione con uno sviluppatore che ha affermato che durante lo sviluppo del programma, creano e cancellano regolarmente tabelle e colonne su base regolare mentre lavorano su nuove funzionalità e cose giustificate dicendo che questo è normale quando si utilizza un processo di sviluppo agile.

Dato che la maggior parte del mio background è in un ambiente di sviluppo a cascata, mi chiedo se questo sia effettivamente considerato corretto in fase di sviluppo agile, o se questo potrebbe essere un segno di un problema di fondo, o con l'architettura del programma o con il loro seguito del processo agile.

Mi sta diventando sempre più evidente ogni giorno che "agile" sta diventando un sinonimo di mal concepito, caotico, frettoloso e comodo. E nessuna di queste cose è compatibile con un approccio Agile come lo capisco.

Avere un processo Agile efficace e ripetibile non è facile e non credo che riduca intrinsecamente la quantità totale di lavoro da svolgere anche se può portare a prodotti migliori.

Se hanno detto che non hanno il tempo di "refactoring" del database, probabilmente non hanno nemmeno il tempo di impostare il versioning e la migrazione per il database. Probabilmente non si sono presi il tempo di creare una serie di test funzionali per questo. Tutte queste cose sono ciò a cui penso quando penso a un solido processo Agile che punta al successo.

Alla fine, Agile è solo una parola. Quello che stai facendo ogni giorno determina se avrai successo o meno.

Sebbene non sia insolito creare e eliminare tabelle man mano che il progetto evolve, potrebbe essere necessario un po 'di pulizia per assicurarsi che il database stia effettivamente utilizzando tutte quelle tabelle.

Sì, Agile ha a che fare con il refactoring, ma se ora stanno dicendo che il sistema è troppo grande per il refactoring, hanno smesso di fare Agile e ora stanno solo programmando Cowboy. Al team di sviluppo non piacerà essere chiamato così, ma è quello che stanno facendo. In sella alla gamma sparare a tutto ciò che si muove.

Un DBA ti aiuterà, assicurati solo di ottenere un DBA che comprenda lo sviluppo e lo sviluppo Agile. Il tuo team di sviluppo deve essere reintrodotto, non gettato in prigione.

In generale, spesso creare nuove tabelle e aggiungere nuove colonne è molto normale in un processo in cui la programmazione e l'amministrazione del database non sono strettamente separate. Una nuova funzionalità potrebbe creare nuovi dati che devono andare da qualche parte. Prova troppo rigorosamente per evitarlo e finisci con un modello di piattaforma interna .

Un software ben scritto difficilmente nota questi nuovi oggetti di database, quindi nulla si rompe solo a causa di una nuova colonna in qualche tabella.

D'altra parte, rilasciare regolarmente colonne o persino tabelle è sospetto. Una nuova funzionalità non ha mai bisogno di una tabella rimossa, quindi questo potrebbe essere un segno di persone che lavorano completamente senza piano.

Se il tuo database può essere facilmente aggiornato e migrato e hai i test per dimostrare che cambiare le cose non ha rotto le cose, probabilmente avrai avviato un processo piuttosto agile.

Alla luce dei commenti - generalmente per effetto di questi sono un mucchio di cowboy che si giustificano come agili - corrono urlando. Veloce. E pubblica tutto ciò che puoi su thedailywtf.com in modo che tutti possiamo goderti il ​​tuo orrore.

Come la maggior parte delle risposte qui su StackExchange, la risposta dovrebbe essere "dipende". Nello sviluppo agile, i requisiti e le specifiche vengono scoperti durante l'implementazione.

Tuttavia, dato lo sviluppo agile, quando un modello relazionale è correttamente normalizzato, l'aggiunta di nuovi attributi alle relazioni dovrebbe raramente essere una necessità, le nuove entità dovrebbero generalmente riferirsi a quelle più vecchie, dato un modello adeguato.

La maggior parte degli sviluppatori non normalizza i propri DB a causa di vincoli di tempo, pigrizia, incompetenza o complessità delle query. La rinormalizzazione richiede il trasferimento di dati esistenti, la modifica dei DAO, ecc. Ecc. Che genera un fattore di rischio.

Per rispondere alla tua domanda, no, non è normale in un processo Agile.

Dove può sembrare che derivi da un atteggiamento Agile è dal ciclo di progettazione / sviluppo / test di breve iterazione di Agile e dall'enfasi di Agile su soluzioni leggere che soddisfano i requisiti noti, ma sono ben strutturate per essere in grado di soddisfare i nuovi requisiti con cambiamento minimo. Date queste due cose, potresti dire che uno sviluppatore, non sapendo cosa potrebbe venire giù la linea ma sapendo che la sua modifica non dovrebbe avere un impatto sul DB in un modo che non può essere annullato, apporta semplicemente le modifiche necessarie allo schema nel Il modo "più leggero" possibile, e poi a intervalli diversi set di cambiamenti "leggeri" verranno trasformati in qualcosa di più permanente e stabile.

Detto questo, non ho ancora lavorato con uno sviluppatore che si è abbonato alla teoria e alla metodologia Agile e ho anche pensato che la creazione e l'eliminazione sistematiche di tabelle nello schema fossero necessarie per qualsiasi motivo. Agile non significa slap-dash o bolt-on. Se ti viene fornita una storia che richiede l'aggiunta di un nuovo campo di dati appartenenti a un particolare record, aggiungi il campo alla tabella. Se quella modifica rompe qualcosa, capisci perché e apporti altre modifiche che potrebbero essere necessarie (posso pensare a pochissime cose che potrebbero rompersi aggiungendo una colonna a un DB interrogato; se si rompe con questo tipo di modifica, tu hanno problemi più grandi). Il refactoring è normalmente limitato al codice; la modifica dello schema è in genere un processo più coinvolto rispetto alla modifica del codice, pertanto quando si verificano modifiche dello schema, di solito vengono eseguite con maggiore attenzione, e almeno qualche attenzione prestata alla conoscenza della direzione futura del progetto. Dover ristrutturare tutto o parte del database indica un fallimento fondamentale della progettazione; essere Agile non significa che non ci sia un "piano generale" di architettura di base e regole di progettazione da seguire durante la costruzione organica del programma e della struttura dei dati.

Ora, ci sono casi in Agile in cui ciò che "conosci" ora sarà contraddetto da ciò che imparerai in seguito. Supponi di avere un requisito secondo cui il tuo sistema deve avere un indirizzo per ogni persona. Poiché si tratta di una relazione 1: 1 e i dati saranno necessari nella maggior parte dei casi, è sufficiente aggiungere i campi Indirizzo alla tabella Persona. Una settimana dopo ricevi un requisito secondo cui una persona può avere più di un indirizzo. Ora è una relazione 1: N e per modellarla correttamente è necessario annullare le modifiche precedenti, suddividendo i campi in una nuova tabella degli indirizzi. Questo non è di routine, soprattutto tra gli sviluppatori senior. Uno sviluppatore esperto vedrà che una persona ha un indirizzo, li considera come concettualmente separati e crea una tabella persona e una tabella indirizzo, collegando la persona all'indirizzo con un riferimento FK a un indirizzo ID. Uno schema come questo è più semplice da modificare in caso di modifica della natura della relazione; senza creare o eliminare intere tabelle di dati "ampie", la relazione tra Persona e Indirizzo può essere facilmente modificata da 1: 1 a 1: N a N: N.

Non ci si concentra molto sulla progettazione in anticipo quando si lavora con Agile, quindi non vedo questo come un grosso problema, sicuramente per la prima versione.

È difficile commentare un sistema che ha 700 tabelle che non ho visto, potrebbe averne bisogno tutte, ma potrebbe anche accadere che il database non sia stato gestito abbastanza bene.

Anche sotto agile, per un grande sistema, è abbastanza comune avere ancora qualcuno / team responsabile dello schema.

Se apportano frequentemente tali cambiamenti, in particolare eliminando tabelle e colonne in applicazioni live, ciò sembra un segno di inesperienza. Non ha nulla a che fare con qualunque processo sostengano di seguire. "Agile" non è una scusa per non sedersi e pensare ai dati che è necessario archiviare e al modo in cui sono correlati prima di iniziare a martellare il codice. Se scoprono che stanno modificando più del 10-20% della struttura iniziale, per me questo è un indicatore del fatto che non stanno riflettendo o non hanno molta esperienza nell'analisi dei requisiti e nella progettazione di database, e quindi ottengono semplicemente molto sbagliato all'inizio.

Anche se sembra che la tua squadra sia semplicemente un codice da cowboy, in realtà non dovrebbe esserci nulla di sbagliato nel refactoring del codice O dei database. Non è lavoro perso - si sta adattando a una realtà appena appresa.

Suggerirei che il team ha bisogno di un sandbox per provare le modifiche, fare alcuni test, rimbalzare gli utenti e decidere se hanno senso. A quel punto, l'integrazione dei cambiamenti che hanno senso - con adeguati test di regressione - nel tuo schema dovrebbe andare bene.

Agile riguarda la programmazione, i database non sono codice. Cambiare un database dovrebbe essere trattato come rimodellare una casa. Le persone in qualche modo hanno avuto la convinzione che i mezzi agili agiscano ora in un piano successivo, il che è completamente falso. Anche con metodi agili è necessario dedicare tempo alla pianificazione, soprattutto per qualcosa di importante come la progettazione di database.

Il mio ultimo lavoro è stato in una squadra come questa. Quando si utilizza un processo agile, i requisiti cambiano. A volte le modifiche significano che un'entità esistente ha bisogno di un nuovo attributo risultante in una nuova colonna in una tabella esistente o è necessaria un'intera nuova entità risultante in una nuova tabella con relazioni con le tabelle esistenti. Questo tipo di modifiche viene fornito con il territorio e non può essere ignorato solo perché non si desidera toccare lo schema. Il successo è determinato dal mantenimento dell'integrità dei dati durante la migrazione da una versione del database alla successiva e corretta verifica dell'unità.

Cerca solo di non apportare modifiche inutili al tuo schema. Ad esempio, se una funzione richiede la creazione di una nuova tabella, assicurarsi di essere soddisfatti della definizione di tale tabella prima di effettuare il check-in e distribuirla nel proprio ambiente di test. Dover annullare una modifica allo schema del database dopo la migrazione dei dati può essere doloroso.