Dans le développement agile, dois-je essayer la persistance dans un fichier plat avant la base de données?

Quelqu'un m'a expliqué que, puisque dans le développement agile, la politique et la logique d'application devraient être plus importantes que des détails tels que la méthode de persistance, la décision de persistance devrait être prise à la fin. Donc, ce pourrait être une bonne idée de commencer avec une persistance plus simple telle que des fichiers plats, jusqu'à ce que nous atteignions le point où la faiblesse de cette méthode devienne apparente, et seulement alors nous changerons la persistance, par exemple en utilisant une base de données relationnelle.

Est-ce vrai ou ai-je mal compris le concept? Est-ce ainsi que l'équipe agile construit généralement une application? Quelles en sont les raisons et quand ne devrais-je pas adopter cette approche?

Le concept véhiculé est quelque chose qui fait définitivement partie de l'agilité et de la pertinence, l'idée de pousser les choses au dernier moment responsable.

Cependant, l'exemple pris repose en fait sur une hypothèse complètement fausse pour commencer:

qu'il est plus facile / moins de travail d'implémenter une base de données à fichier plat que d'utiliser un SGBDR. - Souvent complètement faux

L'exemple devrait être: La couche de persistance est maintenue dans la mise en œuvre la plus simple possible jusqu'à ce qu'une décision soit prise qu'elle est inadéquate.

Pour de nombreuses équipes de développement, obtenir une base de données debout pour ce faire est une question d'une heure ou deux (ou 15 minutes pour une petite base de données avec ORM) tandis qu'une base de données à fichier plat avec laquelle ils n'ont pas besoin de se mêler peut être un énormément de douleur et d'ennui car ils doivent écrire manuellement tout le code de type de construction de recherche et de table de données, lorsqu'une base de données peut être aussi simple que de créer une table dans une interface utilisateur, d'ajouter quelques colonnes, puis qu'un ORM génère tout sinon vous avez besoin.

De plus, si vous ne connaissez pas votre couche de persistance pour commencer, il est encore plus approprié de commencer avec un SGBDR commun que votre équipe connaît bien, car le passage ultérieur d'un fichier plat à un SGBDR est beaucoup plus important que plus tard. passer d'un SGBDR à un autre. Il existe de nombreux outils pour convertir la plupart des SGBDR courants en d'autres, et des conseils et autres, car c'est un chemin bien parcouru. Il existe extrêmement peu d'outils pour convertir un fichier plat en un SGBDR donné où votre fichier plat a un format propriétaire pour lequel l'outillage n'a pas été précédemment écrit en dehors de vos propres bibliothèques.

En résumé: Le concept est correct et précis, mais l'exemple est basé sur une hypothèse terriblement large et souvent (presque toujours) inexacte .

Puisque vous savez que vous utiliserez une base de données, il n'y a pas grand intérêt à écrire du code pour gérer des fichiers plats. Vous pouvez passer par quelques itérations en utilisant des CSV en lecture seule, mais vous vous trouverez rapidement en train d'écrire du code que vous savez que vous allez jeter.

Une chose que vous pouvez faire pour simplifier la complexité initiale en utilisant quelque chose comme SQLite (une bibliothèque qui vous donne une base de données SQL sans serveur qui est stockée dans un fichier). Il a un système de type flexible afin que vous n'ayez pas à vous engager sérieusement dans un schéma, aucun serveur pour configurer / se connecter à & reconstruire votre base de données n'est aussi simple que de supprimer un fichier. Il vous permet également d'inclure simplement l'image DB avec le code dans le contrôle de version si nécessaire.

C'est un exemple, utilisé pour démontrer un concept, plutôt qu'un concept en soi.

Le concept est que vous ne prenez une décision architecturale qu'au dernier moment responsable , mais pas plus tard. Mais, en réalité, vous avez souvent une décision sur la base de données que vous allez utiliser très tôt. Ce n'est peut-être pas parfait, mais c'est un fait.

Une fois cette décision prise, vous ne l'évitez pas activement. Stocker quelque chose dans une base de données existante est souvent aussi simple que de le stocker dans un fichier plat.

Mais passer de MySql sous Linux à SQL Server sous Windows peut ne pas être aussi simple que de passer d'un fichier plat n'importe où à SQL Server sous Windows. Voilà le vrai point. Donc, même s'il existe un doute sur la solution finale, prenez l'option la plus simple possible, en tenant compte du changement. Une fois la décision prise, respectez-la.

Que persistez-vous?

Je fais partie d'une équipe agile et pour une application, nous persistons presque tout dans la base de données. Remarquez que si nous ne l'avons pas fait, il n'y aurait pas grand-chose à faire pour cette application - la persistance de choses dans une base de données est une grande partie de sa raison d'être .

Alors: que persistez-vous et que fait votre application? Si l'application ne se soucie pas réellement de l' emplacement de ses données, vous pouvez écrire une petite couche qui prend la décision (cette décision peut être stockée quelque part dans un fichier de configuration) de fichier plat par rapport à la base de données. Je pense que vous devez évaluer votre application et vos données et décider s'il est judicieux dans votre cas spécifique d'investir du temps dans la persistance de la base de données, ou simplement de lire / écrire des fichiers plats (ce qui sera probablement plus rapide en termes de temps de développement).

Beaucoup de gens interprètent mal cet aspect de l'agilité comme signifiant qu'ils ne devraient pas planifier à l'avance les fonctionnalités futures. Rien ne pouvait être plus loin de la vérité. Ce que vous ne faites pas, c'est de permettre la planification de futures fonctionnalités pour retarder la livraison de valeur à vos clients maintenant.

Comment cela s'applique à quelque chose comme la persistance dépend beaucoup de votre application. Un de mes projets de loisirs actuels est une calculatrice. Finalement, j'aimerais pouvoir stocker des constantes et des fonctions définies par l'utilisateur et enregistrer l'état lorsque je ferme le programme. Cela demande de la persévérance, mais je n'ai même pas commencé à réfléchir à la forme que cela prendrait. Mon programme sera très utilisable sans persistance, et l'ajouter maintenant ajoutera un retard important à ma première version. Je préférerais avoir une calculatrice fonctionnelle avec moins de fonctionnalités que pas du tout en attendant qu'elle soit parfaite.

Un autre de mes projets de loisir est la correction des couleurs vidéo et photo. Cette application sera complètement inutilisable sans pouvoir sauvegarder mon travail en cours, et le code nécessaire pour le faire est omniprésent dans tout le programme. Si je ne comprends pas bien dès le départ, il peut être extrêmement difficile de le changer, alors j'ai consacré beaucoup d'efforts à la persévérance.

La plupart des projets se situent quelque part entre les deux, mais vous ne devriez jamais vous sentir mal à propos de la planification de futures fonctionnalités si cela n'apporte que peu ou pas d'efforts supplémentaires maintenant. Les bases de données peuvent être complexes, mais la majeure partie de cette complexité est cachée derrière une interface solide et bien testée. Le travail que vous aurez à faire dans votre application peut très bien être moindre pour une base de données qu'un fichier plat, en raison de toutes les fonctionnalités qu'une base de données vous offre gratuitement. Il existe des options "hybrides" comme SQLite si vous ne voulez pas encore gérer les tracas d'un serveur de base de données.

Je pense que vous mettez l'accent sur les mauvaises valeurs. En agile, la valeur commerciale est au centre. Vous créez un produit afin de fournir une valeur commerciale à certains utilisateurs finaux.

Si vous créez la couche de persistance tardivement ou que vous la composez en cours de route, c'est votre stratégie pour offrir une valeur commerciale au client. Je ne crois pas que le terme "agile" lui-même dicte si vous devez faire l'un ou l'autre.

Le point de vue sur le report de la stratégie de stockage des données est défendu dans cette présentation de Robert C. Martin (l'un des auteurs du manifeste agile).

C'est une très bonne présentation, je peux vous recommander de la regarder.

Mais je ne suis pas d'accord avec ça! Au moins dans une certaine mesure.

Je ne pense pas que vous puissiez appeler une user story pour "Done", si la user story implique des données qui doivent être conservées et que vous n'avez en fait aucun type de persistance implémenté.

Si le propriétaire du produit décide que le moment est venu de le mettre en ligne, vous ne pouvez pas le faire. Et si vous n'avez commencé à implémenter la persistance que tard dans le projet, vous ne disposez également d'aucune information sur le temps qu'il faudrait pour implémenter la couche de persistance, ce qui représente un risque majeur pour le projet.

Les projets agiles sur lesquels j'ai travaillé n'ont pas différé la stratégie d'accès aux données. Mais il a été découplé, ce qui nous a permis de le changer en cours de route. Et l'ensemble du schéma de base de données n'est pas conçu à l'avance. Des tables et des colonnes sont créées en cours de route selon les besoins afin de mettre en œuvre l'utilisateur stocké qui, au final, offre une valeur commerciale.

Il faut un bon jugement et de l'expérience pour voir à quelles questions il faut d'abord répondre lors du lancement d'un nouveau projet.

Si le produit final est encore inconnu, la construction / prototypage vous aidera rapidement à comprendre cela, et oui, itérer de manière agile vous aidera. Bien sûr, cela introduira des risques tels que la découverte tardive du processus que la mise en œuvre de la persistance va prendre plus de temps que ce que vous avez communiqué à vos parties prenantes.

Si le produit final est bien connu, il peut être plus important de savoir dès le début comment comprendre la persistance dans votre application. Il y a le risque de trouver des problèmes avec les spécifications de votre produit plus tard dans le processus de développement.

Les fichiers plats ne sont pas simples!

Ils permettent le stockage et c'est tout. La structure des données, les chemins d'accès, etc., dépendent de vous, et il existe de nombreuses façons de se tromper.

Il existe des raisons pour lesquelles les bases de données existent et l'une d'elles est de simplifier les choses pour les développeurs.

La majeure partie de mon développement se fait pour de grands systèmes au sein de grandes entreprises. Nous avons toujours un modèle de données complet et bien pensé avant de procéder à toute autre conception ou développement. Un modèle de données vous aide à comprendre votre problème et permet une implémentation propre.

Les éléments de données oubliés, les structures de données incompatibles et d'autres cauchemars peuvent tous être évités en produisant un modèle de données à l'avance.

Vous pouvez laisser votre choix réel de technologie de base de données après le modèle de données. Mais la plupart des technologies de "persistance" sont des programmes étroitement liés et même des styles de conception. Si vous codez pour une base de données relationnelle et décidez plus tard de passer à une chose de valeur de clé nuageuse, vous devrez réécrire complètement la moitié de votre code.

Si vous commencez avec des fichiers plats et passez à une base de données relationnelle, vous finirez probablement par jeter la moitié de votre code car vos développeurs auront perdu leur temps à implémenter une base de données pauvre en pisse.

Devriez-vous essayer la persistance dans un fichier plat avant la base de données?

Oui, vous devriez l'essayer. Surtout si vous ne l'avez jamais essayé auparavant. Peu importe comment cela se passe, vous apprendrez quelque chose.