Base de données mal conçue

Question

Je ne sais pas si je peux faire ce genre de question ici, alors je m'excuse.

Je travaille avec un système qui a beaucoup de dépendances et une base de données mal conçue. Maintenant, je dois prendre une décision et j'aimerais entendre quelques cas de vous.

C'est le cas: une partie du logiciel a été faite sans réfléchir dans tous les cas d'utilisation. Aujourd'hui, j'ai besoin de faire de gros changements, comme créer de nouvelles relations sur la base de données, refactoriser toutes les classes et méthodes. C'est ce que dit la théorie, mais en pratique cela prendra beaucoup de jours, retardera la version et l'ensemble du programme. J'ai l'option de garder le gambiarra (mauvais code qui fonctionne) et de faire juste les petits changements qui répondent aux nouveaux besoins.

Je sais que chaque cas est différent, donc je veux savoir ce que vous feriez et si vous avez vécu quelque chose de similaire.

Answer 1

Il est difficile de donner quelques conseils avec si peu de détails, mais je pense que vous devez informer les parties prenantes que ce qu'ils demandent sera rapide et coûteux. Cela dit, essayez de décomposer tout ce travail en un ensemble de changements réalisables (je crois que vous avez déjà des user stories). Livrez-les progressivement et priorisez-les afin que vos parties prenantes commencent à recevoir de la valeur rapidement. Il est probable que diriger un atelier avec eux pour comprendre quels sont les plus importants pour eux et les peser contre les efforts et les risques de mise en œuvre est un bon moyen d'aligner tout le monde sur la même page.

Bonne chance, on dirait que vous en aurez besoin.

Answer 2

Ceci est une situation très courante. Vous ne fournissez aucun détail spécifique, il est donc difficile de répondre autrement qu'en termes généraux.

Il y a toujours un compromis entre faire le travail, s'inquiéter de l'avenir et dette technique.

S'inquiéter de l'avenir - les fonctionnalités dont vous pensez avoir besoin dans une future version - est une idée abjecte. "Je vais juste mettre ça en ce moment, et ça rendra la prochaine version un peu plus facile" - à chaque fois, ce "juste au cas où" le code a besoin d'amour et d'attention, et à chaque fois, ce n'est pas tout à fait juste quand le temps vient. Donc, je ne recommande pas de construire un support pour les futurs cas d'utilisation. Cela vous ralentit et vous avez tendance à vous tromper sur ce dont vous avez besoin plus tard. En Agile, ils utilisent l'acronyme YAGNI - "Vous n'en aurez pas besoin". Très spécifiquement en réponse à votre question - je ne pense pas que le code ou le design qui ne supporte pas les futurs cas d'utilisation est "mauvais".

Cependant, vous devriez vraiment, vraiment vous inquiéter de la dette technique. Votre code est-il modulaire, couvert par des cas de test décents, lisible, pas trop complexe? Un aspect de la qualité est la suivante: «Est-il facile d'étendre cela? C'est une question très différente - et le code qui est difficile à étendre est mauvais code. Si vous vous trouvez dans cette situation, vous pouvez présenter votre entreprise au concept technical debt. Parfois, c'est une bonne décision de contracter des dettes techniques - et je n'ai jamais travaillé sur un projet qui n'avait pas un certain degré de cela. Mais c'est une question commerciale, pas une question technique. Cela se résume à "combien d'argent futur voulez-vous dépenser pour maintenir ou étendre cette fonctionnalité en échange d'une sortie plus rapide?". Si c'est la toute dernière version, la réponse est probablement "beaucoup". Si c'est la toute première fois dans un plan à long terme, la réponse est probablement "pas très".