Nello sviluppo agile, dovrei provare la persistenza in un file flat prima del database?

Qualcuno mi ha spiegato che poiché nello sviluppo agile, la politica e la logica dell'applicazione dovrebbero essere più importanti dei dettagli come il metodo di persistenza, la decisione sulla persistenza dovrebbe essere presa alla fine. Quindi potrebbe essere una buona idea iniziare con una persistenza più semplice come i file flat, fino a quando non raggiungiamo il punto in cui la debolezza di questo metodo diventa evidente e solo allora cambiamo la persistenza, ad esempio utilizzando un database relazionale.

È vero o ho frainteso il concetto? È così che il team agile di solito crea un'applicazione? Quali sono i motivi per cui e quando non dovrei adottare questo approccio?

Il concetto che viene trasmesso è qualcosa che fa sicuramente parte dell'agile e pertinente, l'idea di spingere le cose all'ultimo momento responsabile.

Tuttavia l'esempio preso in realtà si basa su un presupposto completamente falso per iniziare:

che è più facile / meno lavoro implementare un database flat-file piuttosto che usare un RDBMS. - Spesso completamente falso

L'esempio dovrebbe essere: il livello di persistenza viene mantenuto alla più semplice implementazione possibile fino a quando non viene deciso che non è adeguato.

Per molti team di sviluppo, ottenere un database in piedi per fare questo è una questione di un'ora o due (o 15 minuti per database di piccole dimensioni con ORM) mentre un database di file flat che non continuano a intromettersi potrebbe essere un enorme dolore e fastidio perché devono scrivere manualmente tutto il codice del tipo di costruzione di ricerca e tabella dei dati manualmente, quando un database può essere semplice come creare una tabella in un'interfaccia utente, aggiungere alcune colonne e quindi avere un ORM che genera tutto altrimenti hai bisogno.

Inoltre, se non conosci il tuo livello di persistenza per cominciare, è un atto ancora più appropriato iniziare con un RDBMS comune che il tuo team conosce bene, poiché rendere il passaggio da flat-file a RDBMS è molto più grande di quello successivo passando da un RDBMS a un altro. Esistono molti strumenti per la conversione dalla maggior parte dei RDBMS comuni ad altri simili, e suggerimenti e simili perché è un percorso ben percorso. Esistono pochissimi strumenti per la conversione da un file flat a un determinato RDBMS in cui il file flat ha un formato proprietario per il quale gli strumenti non sono stati precedentemente scritti a parte le proprie librerie.

In sintesi: il concetto è corretto e preciso, ma l'esempio si basa su un'ipotesi terribilmente ampia e spesso (quasi sempre) imprecisa .

Poiché sai che utilizzerai un DB, non ha molto senso scrivere codice per gestire file flat. Potresti superare alcune iterazioni usando alcuni CSV di sola lettura, ma ti ritroverai rapidamente a scrivere codice che sai di buttare via.

Una cosa che puoi fare per semplificare la complessità iniziale usando qualcosa come SQLite (una libreria che ti offre un database SQL senza server archiviato in un file). Ha un sistema di tipo flessibile, quindi non devi impegnarti seriamente in uno schema, nessun server per configurare / connettersi e ricostruire il tuo DB è semplice come eliminare un file. Consente inoltre di includere semplicemente l'immagine DB insieme al codice nel controllo versione, se necessario.

È un esempio, usato per dimostrare un concetto, piuttosto che un concetto in sé e per sé.

Il concetto è che non si prende una decisione architettonica fino all'ultimo momento responsabile , ma non più tardi. Ma, in realtà, spesso hai una decisione sul database che userai molto presto. Potrebbe non essere perfetto, ma è un dato di fatto.

Una volta presa quella decisione, non la eviti attivamente. Archiviare qualcosa in un database esistente è spesso facile come archiviarlo in un file flat.

Ma passare da MySql su Linux a SQL Server su Windows potrebbe non essere semplice come passare da un file flat ovunque a SQL Server su Windows. Questo è il vero punto. Quindi, mentre c'è dubbio sulla soluzione finale, prendi l'opzione più semplice possibile, tenendo conto del cambiamento. Una volta presa una decisione, attenersi ad essa.

Cosa stai persistendo?

Faccio parte di un team agile e, per una sola applicazione, persistiamo quasi tutto nel database. Intendiamoci, se non lo facessimo, non ci sarebbe molto da fare per questa applicazione: perseverare in un database è una grande parte della sua ragion d'essere .

Quindi: cosa stai persistendo e cosa fa la tua applicazione? Se l'applicazione in realtà non importa dove sono conservati i suoi dati, è possibile scrivere un piccolo livello che prende la decisione (tale decisione può essere memorizzata in un file di configurazione da qualche parte) di file flat vs. database. Penso che è necessario valutare l'applicazione e i dati e decidere se ha senso nel vostro caso specifico di investire tempo nella persistenza del database, o semplicemente leggere / scrivere file flat (che sarà probabilmente più veloce in termini di tempo di sviluppo).

Molte persone fraintendono quell'aspetto agile come significato che non dovrebbero pianificare in anticipo per le caratteristiche future. Nulla potrebbe essere più lontano dalla verità. Quello che non fai è consentire alla pianificazione delle funzionalità future di ritardare l'erogazione di valore ai tuoi clienti ora.

Come ciò si applica a qualcosa come la persistenza dipende molto dalla tua applicazione. Uno dei miei attuali progetti di hobby è una calcolatrice. Alla fine, vorrei essere in grado di memorizzare costanti e funzioni definite dall'utente e salvare lo stato quando chiudo il programma. Ciò richiede perseveranza, ma non ho nemmeno iniziato a pensare a quale forma prenderebbe. Il mio programma sarà molto utilizzabile senza perseveranza e aggiungerlo ora aggiungerà un ritardo significativo alla mia prima versione. Preferirei avere una calcolatrice funzionante con meno funzioni di nessuna, mentre aspetto che sia perfetta.

Un altro mio progetto per hobby è la correzione del colore di video e fotografie. Questa applicazione sarà completamente inutilizzabile senza poter salvare il mio lavoro in corso e il codice necessario per farlo è diffuso in tutto il programma. Se non lo capisco fin dall'inizio, cambiarlo potrebbe essere proibitivo in modo proibitivo, quindi ho speso parecchio sforzo sulla persistenza in anticipo.

La maggior parte dei progetti cadrebbe da qualche parte nel mezzo, ma non dovresti mai sentirti male nella pianificazione di funzionalità future se non aggiunge poco o nessun ulteriore sforzo ora. I database possono essere complessi, ma la maggior parte di quella complessità è nascosta dietro un'interfaccia solida e ben testata. Il lavoro che dovrete fare nella vostra applicazione potrebbe benissimo essere inferiore per un database rispetto a un file flat, a causa di tutte le funzionalità che un database offre gratuitamente. Ci sono opzioni "ibride" come SQLite se non vuoi ancora affrontare la seccatura di un server di database.

Penso che ti stai concentrando su valori sbagliati. In agile, il valore aziendale è al centro. Si crea un prodotto al fine di offrire valore aziendale ad alcuni utenti finali.

Se crei il livello di persistenza in ritardo o lo fai lungo la strada è la tua strategia per fornire valore aziendale al cliente. Non credo che il termine "agile" stesso determini se dovresti fare l'uno o l'altro.

Il punto di vista sul differimento della strategia di archiviazione dei dati è sostenuto in questa presentazione da Robert C. Martin (uno degli autori del manifesto agile).

È un'ottima presentazione, posso consigliarti di guardarla.

Ma non sono d'accordo! Almeno fino a un certo punto.

Non credo che tu possa chiamare una user story per "Fatto", se la user story include dati che dovrebbero essere persistenti e in realtà non hai implementato alcun tipo di persistenza.

Se il proprietario del prodotto decide che ora è il momento di andare in diretta, non è possibile farlo. E se non hai iniziato a implementare la persistenza fino a tardi nel progetto, non hai anche informazioni su quanto tempo ci vorrebbe per implementare il livello di persistenza, lasciandolo un grave rischio del progetto.

I progetti agili a cui ho lavorato non hanno rinviato la strategia di accesso ai dati. Ma è stato disaccoppiato, permettendoci di cambiarlo lungo la strada. E l'intero schema del database non è progettato in anticipo. Le tabelle e le colonne vengono create lungo la strada quando sono necessarie al fine di implementare l'utente memorizzato che, alla fine, fornisce valore aziendale.

Ci vuole buon senso ed esperienza per vedere a quali domande bisogna prima rispondere quando si intraprende un nuovo progetto.

Se il prodotto finale è ancora sconosciuto, la costruzione / prototipazione ti aiuterà rapidamente a capirlo, e sì, iterare in modo agile ti aiuterà. Ciò ovviamente introdurrà rischi come scoprire in ritardo nel processo che l'implementazione della persistenza richiederà più tempo di quanto comunicato agli stakeholder.

Se il prodotto finale è ben noto, capire come funzionerà la persistenza nella vostra applicazione potrebbe essere più importante sapere in anticipo. Il rischio è che si verifichino problemi con le specifiche del prodotto più avanti nel processo di sviluppo.

I file flat non sono semplici!

Consentono l'archiviazione e questo è tutto. La struttura dei dati, i percorsi di accesso ecc. Dipende tutto da te e ci sono molti modi per sbagliare.

Ci sono ragioni per cui esistono database e uno di questi è quello di rendere le cose più semplici per gli sviluppatori.

Gran parte del mio sviluppo è fatto per grandi sistemi all'interno di grandi aziende. Abbiamo sempre un modello di dati completo e ben ponderato prima di procedere con qualsiasi ulteriore progettazione o sviluppo. Un modello di dati consente di comprendere il problema e consente un'implementazione pulita.

Elementi di dati dimenticati, strutture di dati non corrispondenti e altri incubi possono essere evitati producendo un modello di dati in anticipo.

È possibile lasciare la scelta effettiva della tecnologia del database fino a dopo il modello di dati. Ma la maggior parte delle tecnologie di "persistenza" sono strettamente legate alla programmazione e persino agli stili di progettazione. Se codifichi un database relazionale e in seguito decidi di passare a un valore chiave nuvoloso, dovrai riscrivere completamente metà del codice.

Se inizi con file flat e passi a un DB relazionale probabilmente finirai per buttare via metà del tuo codice poiché i tuoi sviluppatori avranno perso tempo a implementare un database piscio scadente.

Dovresti provare la persistenza in un file flat prima del database?

Sì, dovresti provarlo. Soprattutto se non l'hai mai provato prima. Non importa come andrà a finire, imparerai qualcosa.