La création et la suppression continues de tables sont-elles le signe d'un défaut architectural?

Récemment, j'ai eu une discussion avec un développeur qui a mentionné que pendant le développement du programme, il crée et supprime régulièrement des tables et des colonnes tout en travaillant sur de nouvelles fonctionnalités et justifie des choses en disant que c'est normal lors de l'utilisation d'un processus de développement agile.

Comme la plupart de mes antécédents se trouvent dans un environnement de développement en cascade, je me demande si cela est réellement considéré comme approprié dans le cadre du développement agile, ou si cela pourrait être le signe d'un problème sous-jacent, que ce soit avec l'architecture du programme ou avec leur suivi du processus agile.

Il devient de plus en plus évident pour moi chaque jour que «agile» devient un synonyme de mal pensé, chaotique, pressé et siège de votre pantalon. Et aucune de ces choses n'est compatible avec une approche Agile si je comprends bien.

Avoir un processus Agile efficace et reproductible n'est pas facile, et je ne pense pas qu'il réduise intrinsèquement la quantité totale de travail à faire même s'il peut très bien conduire à de meilleurs produits.

S'ils ont dit qu'ils n'avaient pas le temps de «refactoriser» la base de données, ils n'avaient probablement pas non plus le temps de configurer la gestion des versions et la migration de la base de données. Ils n'ont probablement pas pris le temps de créer une suite de tests fonctionnels pour cela. Toutes ces choses sont ce à quoi je pense quand je pense à un processus Agile solide qui se dirige vers le succès.

Au final, Agile n'est qu'un mot. Ce que vous faites au quotidien détermine si vous réussirez ou non.

Bien qu'il ne soit pas inhabituel de créer et de supprimer des tables au fur et à mesure de l'évolution d'une conception, un nettoyage peut être nécessaire pour s'assurer que votre base de données utilise réellement toutes ces tables.

Oui, Agile est une question de refactoring, mais s'ils disent maintenant que le système est trop gros pour être refactorisé, ils ont cessé de faire Agile et ne sont plus que de la programmation Cowboy. L'équipe de développement n'aimera pas être appelée ainsi, mais c'est ce qu'elle fait. Surfer sur le champ de tir tout ce qui bouge.

Un DBA vous aidera, assurez-vous simplement d'obtenir un DBA qui comprend le développement ainsi que le développement Agile. Votre équipe de développement doit être confinée et non jetée en prison.

En général, la création de nouvelles tables et l'ajout de nouvelles colonnes est très normal dans un processus où la programmation et l'administration de la base de données ne sont pas strictement séparées. Une nouvelle fonctionnalité peut créer de nouvelles données qui doivent aller quelque part. Essayez trop strictement d'éviter cela et vous vous retrouvez avec un modèle de plate-forme interne .

Un logiciel bien écrit remarque à peine ces nouveaux objets de base de données, donc rien ne casse juste à cause d'une nouvelle colonne dans une table.

En revanche, supprimer régulièrement des colonnes ou même des tables est suspect. Une nouvelle fonctionnalité n'a jamais besoin d'une table supprimée, donc cela pourrait être un signe de personnes travaillant complètement sans plan.

Si votre base de données peut être facilement versionnée et migrée et que vous avez les tests pour prouver que changer les choses n'a pas cassé les choses, alors vous avez probablement un processus assez agile.

À la lumière des commentaires - généralement à l'effet de ceux-ci, un groupe de cow-boys se justifiant comme agiles - courent en hurlant. Vite. Et postez tout ce que vous pouvez sur thedailywtf.com afin que nous puissions tous profiter de votre horreur.

Comme la plupart des réponses ici sur StackExchange, la réponse devrait être «cela dépend». Dans le développement agile, les exigences et les spécifications sont découvertes lors de la mise en œuvre.

Cependant, étant donné le développement agile, lorsqu'un modèle relationnel est correctement normalisé, l'ajout de nouveaux attributs aux relations devrait rarement être une nécessité, les nouvelles entités devraient généralement se référer aux plus anciennes, étant donné un modèle approprié.

La plupart des développeurs ne normalisent pas leurs bases de données en raison de contraintes de temps, de la paresse, de l'incompétence ou de la complexité des requêtes. La renormalisation nécessite le transfert de données existantes, la modification des DAO, etc. etc. qui génère un facteur de risque.

Pour répondre à votre question, non, ce n'est pas normal dans un processus Agile.

Là où cela peut sembler provenir d'une attitude Agile, c'est du cycle de conception / développement / test à courte itération d'Agile, et l'accent mis par Agile sur des solutions légères qui répondent aux exigences connues, mais sont bien structurées afin de pouvoir répondre à de nouvelles exigences avec changement minimal. Compte tenu de ces deux choses, vous pourriez dire qu'un développeur, ne sachant pas ce qui pourrait se produire mais connaissant sa modification ne devrait pas avoir d'incidence sur la base de données d'une manière qui ne peut pas être annulée, apporte simplement les modifications nécessaires au schéma dans le manière "la plus légère" possible, puis à intervalles réguliers plusieurs ensembles de changements "légers" seront refactorisés en quelque chose de plus permanent et stable.

Cela dit, je n'ai pas encore travaillé avec un développeur qui s'est abonné à la théorie et à la méthodologie Agile, et j'ai également pensé que la création et la suppression de tables dans le schéma étaient nécessaires pour une raison quelconque. Agile ne signifie pas slap-dash ou bolt-on. Si vous recevez une histoire qui nécessite l'ajout d'un nouveau champ de données appartenant à un enregistrement particulier, vous ajoutez le champ à la table. Si ce changement casse quelque chose, vous comprendrez pourquoi et apportez d'autres modifications si nécessaire (je peux penser à très peu de choses qui se briseraient en ajoutant une colonne à une base de données interrogée; si cela rompt avec ce type de changement, vous ont de plus gros problèmes). Le refactoring est normalement limité au code; la modification du schéma est généralement un processus plus complexe que la modification du code. Par conséquent, lorsque des modifications de schéma doivent se produire, elles sont généralement effectuées avec plus de soin, et au moins une certaine attention accordée à la connaissance de l'orientation future du projet. Le fait de devoir restructurer une partie ou la totalité de la base de données indique une défaillance fondamentale de la conception; Être Agile ne signifie pas qu'il n'y a pas de "plan directeur" d'architecture de base et de règles de conception à suivre lors de la construction organique du programme et de la structure des données.

Maintenant, il y a des cas dans Agile où ce que vous "savez" maintenant sera contredit par ce que vous apprendrez plus tard. Supposons que vous ayez besoin que votre système ait une adresse pour chaque personne. Comme il s'agit d'une relation 1: 1 et que les données seront nécessaires dans la majorité des cas, il vous suffit d'ajouter les champs Adresse à la table Personne. Une semaine plus tard, vous recevez une exigence selon laquelle une personne peut avoir plusieurs adresses. Il s'agit maintenant d'une relation 1: N, et pour la modéliser correctement, vous devez annuler vos modifications précédentes, en divisant les champs dans une nouvelle table d'adresses. Ce n'est pas une routine, surtout chez les développeurs seniors. Un développeur expérimenté verra qu'une personne a une adresse, les considérera comme conceptuellement distinctes et créera une table de personne et une table d'adresse, reliant la personne à l'adresse avec une référence FK à un ID d'adresse. Un schéma comme celui-ci est plus facile à modifier si la nature de la relation change; sans créer ou supprimer des tables de données "larges" entières, la relation entre la personne et l'adresse peut être assez facilement modifiée de 1: 1 à 1: N à N: N.

Il n'y a pas autant d'attention à la conception à l'avance lorsque vous travaillez sous Agile, donc je ne vois pas cela comme un énorme problème, certainement pour la première version.

Il est difficile de commenter un système qui contient 700 tables que je n'ai pas vues, il pourrait bien en avoir besoin de toutes, mais il se pourrait aussi que la base de données ne soit pas assez bien gérée.

Même sous agile, pour un gros système, il est assez courant d'avoir toujours quelqu'un / équipe en charge du schéma.

S'ils effectuent de tels changements fréquemment - en particulier en supprimant des tables et des colonnes dans des applications actives - cela semble être un signe d'inexpérience. Cela n'a rien à voir avec le processus qu'ils prétendent suivre. `` Agile '' n'est pas une excuse pour ne pas s'asseoir et réfléchir aux données que vous devez stocker et comment elles sont liées avant de commencer à marteler le code. S'ils constatent qu'ils modifient plus de 10 à 20% de la structure initiale, c'est pour moi un indicateur qu'ils ne réfléchissent pas ou qu'ils n'ont pas beaucoup d'expérience dans l'analyse des exigences et la conception de bases de données, et donc ils obtiennent tout simplement trop beaucoup de mal au début.

Bien qu'il semble que votre équipe ne soit en fait que du codage cowboy, il ne devrait vraiment y avoir rien de mal à refactoriser le code OU les bases de données. Ce n'est pas du travail perdu - c'est l'adaptation à une réalité nouvellement apprise.

Je dirais que l'équipe a besoin d'un bac à sable pour tester les changements, faire des tests, les renvoyer des utilisateurs et décider s'ils ont du sens. À ce stade, l'intégration des changements qui ont du sens - avec des tests de régression adéquats - dans votre schéma devrait être correcte.

Agile concerne le codage, les bases de données ne sont pas du code. La modification d'une base de données doit être traitée comme le remodelage d'une maison. Les gens ont en quelque sorte la conviction que l'agilité signifie agir maintenant plus tard, ce qui est complètement faux. Même avec des méthodes agiles, il faut donner du temps pour la planification, en particulier pour quelque chose d'aussi important que la conception d'une base de données.

Mon dernier emploi était dans une équipe comme celle-ci. Lors de l'utilisation d'un processus agile, les exigences changent. Parfois, les modifications signifient qu'une entité existante a besoin d'un nouvel attribut résultant en une nouvelle colonne dans une table existante ou qu'une toute nouvelle entité est requise, résultant en une nouvelle table avec des relations avec les tables existantes. Ces types de changements viennent avec le territoire et ne peuvent pas être ignorés simplement parce que vous ne voulez pas toucher au schéma. Le succès est déterminé par le maintien de l'intégrité de vos données lors de la migration d'une version de base de données vers la prochaine et un test unitaire approprié.

Essayez simplement de ne pas apporter de modifications inutiles à votre schéma. Par exemple, si une fonction nécessite la création d'une nouvelle table, assurez-vous que vous êtes satisfait de la définition de cette table avant de l'archiver et de la déployer dans votre environnement de test. Devoir annuler une modification de votre schéma de base de données après la migration de vos données peut être pénible.