Y a-t-il un espoir d'écrire du bon code sur une base de données horriblement conçue?

Voici ma situation difficile. L'un des nombreux programmes dont j'ai récemment hérité est construit avec une horrible base de données sur le backend. Les estimés créateurs de celui-ci n'ont apparemment pas apprécié les concepts relationnels. Une table pour chaque client, nommée comme un ID client unique. Quatre-vingt-trois champs nommés de façon cryptique. Le code est entièrement procédural avec des dizaines d'instructions SQL en ligne concaténées.

Comme nous ne disposions pas d'une application auxiliaire importante qui fonctionne avec la même base de données, j'ai été chargé de la recréer à partir de zéro. Je suis un développeur unique, ce qui n'est même pas ma responsabilité principale car au moins la moitié de mon temps est occupé par des opérations. Un délai inévitable est fixé à 30 jours.

Malgré mon inexpérience, je suis certain que j'aurais pu concevoir cette base de données et l'application existante bien mieux qu'avant, mais je ne pense pas vraiment qu'il soit réaliste pour moi de modifier la base de données, d'ajuster l'application existante et de m'assurer que je ne l'ai pas fait. t casser quoi que ce soit tout en ayant besoin de créer l'application supplémentaire aussi rapidement.

Supposons donc que je suis coincé avec la terrible base de données. Ayant besoin de travailler avec une structure aussi mauvaise, est-ce que tout ce que j'écrirai qui y serait conforme ne ferait qu'ajouter au tas de dettes techniques à mettre de côté jusqu'à ce que quelque chose se casse complètement ou que de nouvelles fonctionnalités soient nécessaires? Comment pourrais-je aborder cette situation et en tirer quelque chose de bien en plus d'une application, espérons-le, fonctionnelle?

edit: Au cas où quelqu'un serait intéressé, nous avons fini par supprimer cette horrible base de données et l'application qui y tournait. Nous avons externalisé la création de l'application auxiliaire (je n'ai pas été impliqué dans la mise en place) à deux contractants différents qui ont fini par nous tomber dessus, sans rien faire. J'ai fini par devoir précipiter un horrible hack partiellement fonctionnel d'un correctif en trois jours qui est toujours utilisé aujourd'hui.

Il y a de l'espoir, mais c'est une bataille difficile, surtout si personne ne se rend compte que la conception de la base de données est horrible. Vous pouvez essayer d'abstraire la méchanceté avec des couches d'abstraction, mais il est probable que cela ne vaudra pas la bataille.

Mon conseil serait de créer suffisamment d'abstractions sur la base de données pour que l'application elle-même soit propre et correctement conçue; De cette façon, si vous pouvez réparer la base de données, l'application ne sera pas affectée car elle ne se soucie pas de la façon dont la base de données a été conçue.

C'est l'approche que j'utilise normalement lorsque je traite avec une base de données qui est en place et, le plus souvent, conçue avec une pensée zéro. Quelques applications de choix des modèles de référentiel ou de passerelle, avec certaines couches de service pour parler à la passerelle / référentiel, devraient aider à mettre en quarantaine la mauvaise conception.

Créez une couche d'interface qui gère tous les éléments de la base de données, puis écrivez votre application pour interfacer avec cela. Dans le cas où la base de données est "corrigée", il vous suffit de remplacer / mettre à jour votre "interface". Cette approche m'a fait gagner une tonne de temps face à une mauvaise base de données ou une base de données qui alimentait d'autres applications et ne pouvait pas être gâchée.

Aïe ... Vous avez hérité d'un gâchis de cauchemar, vous avez 30 jours pour le rendre utilisable pour votre organisation, et la moitié de votre journée est consacrée à des tâches opérationnelles?

Je suis sûr que vous pourriez refactoriser mais certainement pas dans ce laps de temps.

Pour répondre à votre question, je ne pense pas que vous puissiez réellement écrire du bon code sur une telle conception. La dette technique est déjà trop. Si j'étais vous, je piraterais les fonctionnalités que je pourrais, et ferais pression pour une refactorisation complète à une date ultérieure lorsque vous aurez plus de temps et de personnes dans votre équipe pour mieux y faire face.

Soyez juste prudent en poussant pour le refactoring. Parfois, un supérieur décidera d'acheter un code source de produit et des droits de propriété et il ne veut pas penser qu'il a complètement gaspillé son argent en ordures. Ce fut le cas pour moi à un emploi que j'avais. Malheureusement, les gestionnaires prennent des décisions sur l'achat de logiciels comme celui-ci et ils n'obtiennent jamais d'implication technique pour évaluer ce qu'ils achètent et voir s'il est maintenable et a une grande dette technique. Dans ce cas, la mauvaise décision est politique et pousser à la refactorisation peut mettre votre travail en danger.

Les bases de données peuvent être refactorisées comme tout autre code. Corrigez la partie affectée par le code dont vous avez besoin pour écrire et écrire des tests pour vous assurer que rien d'autre ne casse. Faites un petit peu à la fois comme tout autre refactoring. Il existe un bon livre sur la refactorisation de la base de données qui pourrait vous aider à commencer à nettoyer le gâchis. http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

Il y en a d'autres aussi, mais j'ai personnellement lu et travaillé avec les techniques de celui-ci.

Et n'oubliez pas que vous pouvez restructurer la façon dont vous devez interroger la base de données en créant des vues pour effectuer le travail de transformation désagréable pour vous en une structure plus facile à interroger.

Pour obtenir le meilleur rapport qualité-prix, créez des vues pouvant être mises à jour pour restaurer une partie de la "relationnalité" et pour fournir des noms de colonne plus significatifs.

Une possibilité serait de configurer une deuxième base de données structurée (au moins plus proche) de la façon dont vous l'aimeriez, et de configurer la réplication entre les deux bases de données. Ensuite, vous pouvez écrire votre code sur la nouvelle base de données et laisser la base de données existante (et l'application) intacte, pour être traitée lorsque vous aurez plus de temps.

À vrai dire, il est encore ouvert à beaucoup de questions que vous pouvez le faire dans ~ 15 jours de travail. En particulier, cela dépendra probablement de la nécessité d'une réplication bidirectionnelle (c'est-à-dire que votre nouvelle application mettra réellement à jour les données) ou d'une seule façon (votre nouvelle application permet simplement aux gens de visualiser les données). Ce dernier cas est (bien sûr) beaucoup plus facile à traiter.

Si vous avez besoin d'une réplication bidirectionnelle, il est probable que ce ne soit tout simplement pas assez de temps pour faire le travail. En particulier, la réplication bidirectionnelle qui implique une transformation substantielle de la structure n'est jamais triviale, et les outils disponibles la prennent souvent assez mal en charge (par exemple, avoir à écrire manuellement tout le SQL pour toutes les transformations de données dans les deux sens).

Si vous n'avez besoin que d'un aller simple, c'est juste au point qu'il pourrait être possible. Cela dépendra également un peu de si vous êtes autorisé à dépenser de l'argent ou non - il existe un certain nombre d'applications d'entreposage de données qui sont destinées exactement à ce type de tâche qui le rendraient probablement un peu plus rapide et plus facile. à gérer - mais la plupart d'entre eux ne sont pas bon marché.