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

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

Tuttavia l'esempio preso in realtà si basa su una supposizione completamente falsa per iniziare con:

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

L'esempio dovrebbe essere: il livello di persistenza è mantenuto per l'implementazione più semplice possibile fino a quando non viene presa una decisione che è inadeguato.

Per molti team di sviluppo, ottenere un database in piedi per farlo è questione di un'ora o due (o 15 minuti per un piccolo database con ORM) mentre un database di file flat che non continuano a dover interferire con può essere un enorme dolore e fastidio perché devono scrivere manualmente tutto il codice del tipo di costruzione della ricerca e del data-table manualmente, quando un database può essere semplice come creare una tabella in un'interfaccia utente, aggiungere poche colonne e quindi avere un ORM genera tutto il resto necessario.

Inoltre, se non si conosce il livello di persistenza per iniziare, è un atto ancora più appropriato iniziare con un RDBMS comune che il team conosce bene, in modo da rendere la modifica più tardi da file flat a RDBMS è molto più più grande di più tardi passando da un RDBMS a un altro. Esistono molti strumenti per convertire dalla maggior parte degli RDBMS comuni ad altri simili, e suggerimenti e così via perché è un percorso ben organizzato. Esistono pochissimi strumenti per la conversione da un file flat a un determinato RDBMS in cui il file flat ha un formato proprietario che gli strumenti non sono stati precedentemente scritti a parte le tue librerie.

In sintesi: Il concetto è corretto e accurato, ma l'esempio si basa su un'assunzione terribilmente grande e spesso (quasi sempre) imprecisa .

Dal momento che sai che userai un DB, non ha molto senso scrivere codice per gestire file flat. Potresti passare attraverso alcune iterazioni utilizzando alcuni file CSV di sola lettura, ma ti ritroverai presto a scrivere codice che sai di voler eliminare.

Una cosa che puoi fare per semplificare la complessità iniziale usando qualcosa come SQLite (una libreria che ti dà un database SQL senza server che è memorizzato in un file). Ha un sistema di tipo flessibile, quindi non devi impegnarti seriamente in uno schema, nessun server da configurare / connettere a & ricostruire il tuo DB è semplice come cancellare un file. Permette anche di includere semplicemente l'immagine del DB insieme al codice nel controllo della versione, se necessario.

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

Il concetto è che non prendi una decisione architetturale fino al 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 questa decisione, non la eviti attivamente. Memorizzare qualcosa in un database esistente è spesso facile come archiviarlo in un file flat.

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

Cosa stai persistendo?

Sono su un team agile e per un'applicazione, manteniamo quasi tutto nel database. Intendiamoci, se non lo facessimo, non ci sarebbe molto da fare per questa applicazione - le cose persistenti in un database sono una parte importante della sua ragion d'essere .

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

Molte persone interpretano erroneamente questo aspetto dell'agile nel senso che non dovrebbero pianificare in anticipo le funzionalità future. Nulla potrebbe essere più lontano dalla verità. Ciò che non fai è consentire la pianificazione di funzionalità future per ritardare la consegna di valore ai tuoi clienti ora.

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

Un altro mio progetto di hobby è la correzione del colore di video e fotografia. 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 sin dall'inizio, cambiarlo potrebbe essere proibitivo, quindi ho speso un bel po 'di impegno sulla persistenza in anticipo.

La maggior parte dei progetti cadrà in qualche modo tra di loro, ma non dovresti mai preoccuparti di pianificare le funzionalità future se ora non aggiunge alcuno sforzo in più. I database possono essere complessi, ma la maggior parte di questa complessità è nascosta da un'interfaccia solida e ben testata. Il lavoro che dovrai fare nella tua applicazione potrebbe essere molto meno per un database di un file flat, a causa di tutte le funzionalità che un database ti offre gratuitamente. Ci sono opzioni "ibride" come SQLite se non vuoi ancora affrontare il problema di un server di database.

Penso che stai concentrando l'attenzione sui valori sbagliati. In agile, il valore aziendale è a fuoco. Crei un prodotto per fornire valore aziendale ad alcuni utenti finali.

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

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

È un'ottima presentazione, posso consigliarti di guardarlo.

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

Non credo che tu possa chiamare una user story per "Fatto", se la storia dell'utente coinvolge 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 sei in grado di farlo. E se non hai iniziato a implementare la persistenza fino a tardi nel progetto, non disponi di informazioni su quanto tempo occorrerebbe per implementare il livello di persistenza, lasciandolo un grosso rischio per il progetto.

I progetti agili su 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 nel modo in cui sono necessarie per implementare l'utente memorizzato che, alla fine, fornisce valore aziendale.

Ci vuole buon giudizio ed esperienza per vedere quali domande devono prima rispondere quando si inizia un nuovo progetto.

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

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

I file piatti non sono semplici!

Permettono lo stoccaggio e questo è tutto. La struttura dei dati, i percorsi di accesso ecc. Sono tutti a te, e ci sono molti modi per sbagliare.

Esistono dei database di motivi e uno di questi è 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 congegnato prima di procedere con ulteriori progetti o sviluppi. Un modello di dati ti aiuta a capire il tuo problema e ti consente un'implementazione pulita.

È possibile evitare elementi di dati dimenticati, strutture di dati non corrispondenti e altri incubi creando un modello di dati in primo piano.

Puoi lasciare la tua attuale scelta della tecnologia di 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 si esegue la codifica per un database relazionale e successivamente si decide di passare a un valore di chiave nuvoloso, sarà necessario 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 perché i tuoi sviluppatori avranno perso tempo ad implementare un database 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.