Est-il préférable d'utiliser des mauvaises pratiques préexistantes ou des bonnes pratiques qui ne correspondent pas bien à l'ancien code?

J'y pensais parce que j'essayais d'écrire une extension pour un logiciel tiers existant, et leur base de données est horriblement dénormalisée. J'avais besoin d'utiliser leurs tables existantes et d'ajouter un tas de nouveaux champs.

J'ai eu la possibilité de créer de nouvelles tables dans leur style de conception (qui consiste en presque toutes les propriétés se trouvant dans une seule grande table), ou de créer un nouvel ensemble de tables ensemble et d'utiliser quelque chose en plus comme des déclencheurs pour synchroniser les données entre les nouveaux et vieilles tables.

J'ai fini par choisir la première option d'utiliser le mauvais style de conception existant, mais je me suis retrouvé avec cette question: vaut-il mieux aller avec des mauvaises pratiques préexistantes, ou mettre en œuvre de bonnes pratiques qui ne fonctionnent pas bien avec le code existant? Y a-t-il des situations où je devrais choisir l'un plutôt que l'autre?

REMARQUE: jusqu'à présent, de nombreuses réponses ont à voir avec une refactorisation lente du mauvais code, mais je ne suis pas en mesure de le faire. Le code n'est pas le nôtre et il est fréquemment mis à jour par le fournisseur. Je ne peux que m'en inspirer.

Vous devriez choisir un meilleur design si:

1. Vous allez reprendre une grande partie du futur codage

2. Une meilleure conception n'est pas plus coûteuse pour le client à long terme. Par exemple, j'ai assisté à des «remaniements» de plusieurs mois pour des projets qui ont été interrompus à la fin de l'année.

Vous devez choisir "même mauvais style" si:

1. Vous aidez juste. Il n'est pas réaliste de penser que vous pouvez prendre un groupe existant et le mettre à des normes de conception plus élevées si vous êtes juste un remplaçant à temps partiel sur le projet. Un meilleur design est subjectif et a presque toujours une courbe d'apprentissage. Si ce nouveau design n'est pas appris par le reste de l'équipe, le projet se terminera avec un méli-mélo de styles, et votre code mieux conçu peut se retrouver dans la pile de choses que personne ne change parce qu'ils ne peuvent pas comprendre il. Dans votre exemple ci-dessus, que se passe-t-il en cas de mise à jour du logiciel tiers?

2. Sacrifier une «meilleure» conception vous procurera un avantage commercial tangible. Comme ajouter mal la fonctionnalité X, vous obtiendrez un gros contrat, mais le fait de ne pas respecter la date limite vous amène à rien. C'est là qu'intervient le conflit historique entre mgmt et l'équipe technique. Comme pour rénover une maison, quelqu'un doit décider quand payer. Vous pouvez d'abord rembourser la dette en vivant sans électricité ni plomberie pendant un an. Ou vous pouvez payer 3 fois plus avec l'avantage d'avoir ces utilitaires.

À long terme, il est préférable d'utiliser les bonnes pratiques. Cela permettra d'économiser du temps et des efforts car les modifications prendront moins de temps à mettre en œuvre.

Si possible, prenez de petites mesures pour refactoriser les bonnes pratiques (par exemple: en SQL, ce serait casser les tables dénoramlisées en une normalisée et utiliser des vues avec les anciens noms de table).

Vous remarquerez que j'ai dit à long terme - le triangle «qualité, temps, argent» s'applique également ici (c'est-à-dire - choisissez deux). Si vous n'avez pas le temps, vous devrez peut-être utiliser d'anciennes pratiques, mais cela signifiera que vous ajoutez au problème et que votre conception devra également être corrigée.

Si vous continuez à travailler et à ajouter du code de mauvaise conception, vous ne vous retrouverez jamais avec une base de code qui utilise une bonne conception. Autant que possible, essayez d'utiliser un bon design et de refactoriser un bon design.

Eh bien, je pense que cela dépend beaucoup de chaque cas. Si les performances et la conception le permettent, il est préférable d'utiliser les bonnes pratiques. Mais si, par exemple, si cette table est une table à accès élevé, la création d'un déclencheur pour la sincronisation peut avoir un impact négatif sur les performances.

Maintenant, votre client ne verra pas que vous avez utilisé une meilleure conception, il verra simplement que votre solution a ralenti son système. Ce type de décision doit être pris au cas par cas, et vous devez utiliser votre expérience et vos critères pour décider.

Je pense que vous avez probablement fait le bon choix.

Autant que possible, vous devez isoler votre code d'application de la mauvaise conception des données.

Mettez-vous à jour leurs tableaux? Sinon, créez des vues SQL pour présenter ces tables d'une manière pratique pour votre application. Les vues SQL sont relativement faciles à écrire et beaucoup plus faciles à tester que le code d'application.

Si vous devez mettre à jour les tables héritées, pensez à écrire des procédures stockées pour gérer les mises à jour. Ils sont un peu plus complexes à écrire, mais ils peuvent être testés instantanément.

Garder l'ancien code synchronisé lorsque vous normalisez une base de données avec des déclencheurs est une bonne solution si elle est temporaire. L'objectif devrait être de modifier l'ancien code, mais lorsque vous traitez avec un tiers, cela peut ne pas fonctionner. Vous devrez rester au courant de leurs modifications de schéma.

Empiler de plus en plus de fonctionnalités sur le mauvais code va créer des problèmes continus. Les solutions de rechange deviennent la norme. Les utilisateurs seront frustrés car les changements vont prendre trop de temps et entraîneront probablement d'autres bogues ou limitations. Qui veut être le programmeur pour dire que nous ne pouvons pas faire cela au lieu de ne pas le faire?

Certains codes peuvent être laissés seuls; nous n'avons pas toujours ce luxe.

Vous avez affaire à une dette technique ici. En bref, la dette technique implique des intérêts, que vous devez payer au fil du temps, et à un moment donné, vous devez les rembourser.

Le temps de Develloper coûte de l'argent, donc la dette technique peut être vue comme la vraie dette et coûte de l'argent réel.

Vous avez essentiellement deux solutions principales et de nombreuses solutions entre les deux. Vous pouvez décider de ne pas rembourser cette dette maintenant et continuer à payer des intérêts. Évidemment, cela coûtera plus cher à long terme, mais vous permettra d'avoir des résultats dès maintenant. Vous pouvez également choisir de rembourser cette dette afin de ne plus avancer tant que vous ne la remboursez pas, mais à la fin, vous êtes libre d'intérêts.

Habituellement, vous avez des délais de livraison, et le fait de manquer un délai entraînera la méfiance de votre client et vous finirez par le perdre. Cela pourrait être une raison valable de creuser la dette technique: vous considérez que ce que vous gagnez avec le client vaut la dépense supplémentaire de la dette technocale.

Vous savez qu'à la fin, vous devez adopter la nouvelle méthodologie, sinon, vous vous endetterez de plus en plus et vous finirez par faire faillite (vous maintenant, quand les gens décident de recommencer à zéro ou quand le projet échoue mal).

Vous devez planifier la façon dont vous allez modifier la base de code existante et la transition vers une nouvelle pratique au fil du temps, et distribuer le changement petit à petit quotidiennement. À un certain moment, lorsque la refactorisation entraînera d'autres pertes, considérez quelle perte est la pire et optez pour la meilleure.

Le coût de la non refactorisation augmentera avec le temps (ce sont les intérêts de la dette technocale). Cela deviendra donc à terme le choix le plus coûteux.

Assurez-vous que votre patron comprend le concept de dette technique. Même avec précaution, vous créerez une dette technique. À un moment donné, l'argent doit être utilisé pour le rembourser. Lorsque vous créez une dette technique à dessein, vous DEVEZ avoir une raison valable pour cela et voir la dette comme un investissement (tout comme la dette réelle). Dans tous les autres cas, NE FAITES PAS de dette technique exprès.

Vous pouvez être intéressé par les méthodologies pour faire évoluer la base de données et déployer ces évolutions: http://richarddingwall.name/2011/02/09/the-road-to-automated-database-deployment

Soit dit en passant, c'est une tâche difficile, alors bonne chance. Ça vaut le coup !

Il s'agit d'un problème typique de: "Dois-je profiter des avantages de mon travail maintenant ou plus tard?" et je ne pense pas qu'il puisse jamais y avoir une solution générique à cette réponse. Vous seul connaissez tous les facteurs (techniques et humains) impliqués dans une telle décision.

Cependant, votre problème soulève une question intéressante:

Le refactoring automatique de code fait-il suffisamment de progrès pour que l'uniformité du code soit davantage valorisée?

En fin de compte, une mauvaise conception devrait changer ou mourir. Ou bien, ce n'est pas une mauvaise conception. La vraie question ici concerne le coût du refactoring. Il semble clair d'après votre question que vous (ou votre employeur) n'êtes pas disposé à en payer le prix maintenant, et dans l'état actuel de la technologie, vous n'aurez probablement jamais envie de le faire.

Cependant, l'automatisation du refactoring de code fait quelques progrès. Si les compilateurs peuvent optimiser les binaires aujourd'hui, qui peut dire qu'ils n'optimiseront pas le code demain? À un moment donné, un outil va voir le jour, permettant aux développeurs et aux concepteurs de refactoriser leur code très facilement, afin de s'adapter aux nouvelles exigences. Après tout, le traitement du code hérité est l'un des plus grands défis d'aujourd'hui.

Si un tel outil existe (je ne serais pas surpris qu'il le soit déjà), il serait bon de le prendre en compte lors de la prise d'une telle décision.

Bonnes pratiques toujours emportent pauvres. Si votre base de code est jonchée de code dans le mauvais sens, vous ne devez pas simplement cultiver votre propre contenu de la même manière, vous devez écrire le code correctement, puis essayer d'éduquer tout le monde sur la bonne façon.