Existe-t-il un modèle anti nommé pour les logiciels développés historiquement? [fermé]

Existe-t-il un anti-modèle qui décrit un système logiciel développé historiquement où plusieurs développeurs ont simplement ajouté de nouvelles fonctionnalités au système mais personne n'a vraiment gardé un œil sur l'architecture globale et aucune refactorisation n'a jamais été effectuée?

Je pense que cela se produit lorsque la direction / le client demande constamment de nouvelles fonctionnalités et que personne ne refacture quoi que ce soit, mais ajoute simplement à ce que les autres développeurs n'ont pas fait auparavant.

Une raison pourrait également être que le développeur est juste submergé par le système logiciel et ne comprend pas vraiment comment il fonctionne actuellement, puis ajoute / colle son code à la toute fin (au lieu de refactoriser le code et de le modifier.)

Au fil du temps, il devient de plus en plus difficile de maintenir le système.

(Je me demande s'il y a des images pour ce type de motif anti pour rendre cela plus clair pour personne de la programmation - comme une voiture qui a été construite en ajoutant simplement de plus en plus de fonctionnalités sans penser à la conception globale. Comme quelqu'un a besoin de remorquer remorques en roulant vers l'arrière, puis un ingénieur soude simplement une barre de remorquage à l'avant de la voiture. Travail accompli. Mais maintenant le capot ne s'ouvre plus.)

Vous parlez de dette technique .

Nous accumulons tous une dette technique dans les produits que nous développons au fil du temps; le refactoring est l'un des moyens très courants et efficaces de réduire cette dette technique, bien que de nombreuses entreprises ne remboursent jamais leur dette technique. Ces entreprises ont tendance à trouver leurs logiciels extrêmement instables sur la route, et la dette technique devient si horrible que vous ne pouvez pas le payer progressivement, car il faudrait trop de temps pour le payer de cette façon.

La dette technique a le terme, car elle suit les mêmes comportements de dette. Vous obtenez la dette, et tant que vous continuez à dépenser (créer des fonctionnalités) et à ne pas rembourser cette dette, elle ne fera qu'augmenter. Tout comme la dette, quand elle devient trop importante, vous arrivez à des points où vous souhaiterez peut-être la supprimer entièrement avec des tâches dangereuses comme des réécritures complètes. Tout comme la dette réelle, car elle s'accumule jusqu'à un certain point, elle entrave complètement votre capacité à dépenser (créer des fonctionnalités).

Juste pour jeter un autre terme dans le mélange, la cohésion se réfère à la façon dont un système, micro au niveau ligne, ou macro au niveau système, s'assemble. Un système hautement cohésif aura toutes ses pièces très bien assemblées et ressemblera à un ingénieur qui a tout écrit. Votre référence ci-dessus à quelqu'un qui vient de coller son code à la fin violerait la cohésion de ce système.

Gérer la dette technique

Il existe de nombreuses façons de gérer la dette technique, mais comme pour la dette réelle, la meilleure approche consiste à la rembourser fréquemment. Malheureusement, comme la dette réelle, il est parfois préférable de cumuler davantage pour une courte période, par exemple, le temps de commercialisation d'une fonctionnalité peut doubler ou tripler vos revenus. La partie délicate consiste à évaluer ces priorités concurrentes ainsi qu'à identifier le moment où le retour sur investissement des dettes n'en vaut pas la peine pour la fonctionnalité donnée par rapport à la date à laquelle elle l'est.

Parfois, cela vaut donc la peine d'accumuler la dette pour une courte période, mais c'est rarement le cas, et comme pour toute dette, plus la période est courte, mieux c'est. Donc, finalement (de préférence rapidement ) après avoir accumulé une dette technique, vous devez la rembourser, ce sont des approches courantes:

• Refactoring
  • Cela vous permet de prendre des morceaux de code qui n'ont été réalisés que partiellement à travers ou après la fin de l'implémentation, et de les mettre à leur place correcte (ou plus correcte de toute façon).
• Récrire
  • C'est comme une faillite. Cela efface l'ardoise, mais vous commencez avec rien et avez toutes les chances de faire les mêmes erreurs, voire des plus grosses. Approche à haut risque et à récompense élevée de la dette technique, mais c'est parfois votre seule option. Bien que ce soit plus rarement le cas que beaucoup vous le diront.
• Présentation de l'architecture
  • Il s'agit plus d'une approche active de remboursement de la dette technique. Cela se fait en ayant une personne ayant autorité sur les détails techniques pour arrêter une mise en œuvre quels que soient les plans et les calendriers du projet afin de s'assurer qu'elle accumule moins de dette technique.
• Gel de code
  • Geler le code des changements peut vous permettre de respirer là où votre dette n'augmente pas ou ne diminue pas. Cela vous donne le temps de planifier votre approche de réduction de la dette technique dans l'espoir d'avoir le ROI le plus élevé de votre approche.
• Modularisation
  • Cela ressemble à une approche de niveau 2 uniquement disponible lorsque vous utilisez soit Présentation de l'architecture pour avoir déjà un système modulaire, soit Refactorisation pour en adopter un. Lorsque vous avez un système modulaire, vous pouvez alors rembourser la dette en morceaux entiers du système de manière isolée. Cela vous permet de faire des réécritures partielles , une refactorisation partielle , ainsi que de minimiser le taux d'accumulation de la dette technique, car l'isolement ne maintient la dette que dans les zones où les fonctionnalités sont entrées, par opposition à la répartition dans le système.
• Tests automatisés
  • Les tests automatisés peuvent vous aider à gérer votre dette technique, car ils peuvent vous aider à identifier les points chauds du système, espérons-le avant que la dette dans ces domaines ne soit devenue très importante, mais même après le fait, ils peuvent toujours informer les ingénieurs des zones dangereuses qu'ils peut ne pas avoir déjà réalisé. De plus, une fois que vous avez des tests automatisés, vous pouvez refaçonner plus librement les choses sans craindre d'en casser trop. Non pas parce que les développeurs ne casseront pas les choses, mais parce qu'ils découvriront quand ils cassent les choses , s'appuyer sur des testeurs manuels dans des systèmes très endettés a tendance à avoir un mauvais bilan pour trouver des problèmes.

Votre description correspond à Foote et à la grosse boule de boue de Yoder :

Au cours des dernières années, un certain nombre d'auteurs ... ont présenté des modèles qui caractérisent les architectures logicielles de haut niveau ... Dans un monde idéal, chaque système serait un exemple d'un ou plusieurs de ces modèles de haut niveau. Pourtant, ce n'est pas le cas. L'architecture qui prédomine dans la pratique reste à discuter: la GRANDE BOULE DE BOUE .

UNE GRANDE BOULE DE BOUE est structurée au hasard, tentaculaire, bâclée, du ruban adhésif et du fil à écoper, la jungle du code des spaghettis. Nous les avons tous vus. Ces systèmes montrent des signes indubitables de croissance non régulée et de réparation répétée et rapide. Les informations sont partagées de manière promiscuité entre les éléments distants du système, souvent au point où presque toutes les informations importantes deviennent globales ou dupliquées. La structure globale du système n'a peut-être jamais été bien définie. Si tel était le cas, il aurait pu s'éroder au-delà de la reconnaissance. Les programmeurs avec un brin de sensibilité architecturale évitent ces bourbiers. Seuls ceux qui ne se soucient pas de l'architecture, et, peut-être, sont à l'aise avec l'inertie de la corvée quotidienne de colmater les trous dans ces digues défaillantes, se contentent de travailler sur de tels systèmes ...

Pourquoi un système devient-il une GRANDE BOULE DE BOUE? Parfois, de gros systèmes laids émergent du THROWAWAY CODE . THROWAWAY CODE est un code rapide et sale qui était destiné à être utilisé une seule fois, puis jeté. Cependant, un tel code prend souvent une vie propre, malgré une structure occasionnelle et une documentation pauvre ou inexistante. Cela fonctionne, alors pourquoi le réparer? Lorsqu'un problème connexe survient, le moyen le plus rapide de le résoudre pourrait être de modifier rapidement ce code de travail, plutôt que de concevoir un programme général approprié à partir de zéro. Au fil du temps, un simple programme jetable engendre une GRANDE BOULE DE BOUE.

Même les systèmes avec des architectures bien définies sont sujets à l'érosion structurelle. L'assaut incessant de l'évolution des exigences que tout système efficace attire peut saper progressivement sa structure. Les systèmes qui étaient jadis bien rangés deviennent envahis par la croissance PIECEMEAL qui permet progressivement aux éléments du système de s'étendre de manière incontrôlée.

Si un tel étalement se poursuit sans relâche, la structure du système peut devenir si gravement compromise qu'il doit être abandonné. Comme pour un quartier en décomposition, une spirale descendante s'ensuit. Comme le système devient de plus en plus difficile à comprendre, la maintenance devient plus coûteuse et plus difficile. Les bons programmeurs refusent de travailler là-bas. Les investisseurs retirent leur capital. Et pourtant, comme dans les quartiers, il existe des moyens d'éviter, voire d'inverser, ce type de déclin. Comme pour toute autre chose dans l'univers, la lutte contre les forces entropiques nécessite un investissement énergétique. La gentrification des logiciels ne fait pas exception. Le moyen d'arrêter l'entropie dans un logiciel est de le refactoriser. Un engagement soutenu à la refactorisation peut empêcher un système de se fondre dans une GRANDE BOULE DE MUD ...

• ... L'un des ennemis les plus efficaces de la boue est le soleil. Soumettre un code alambiqué à une flèche d'examen peut préparer le terrain pour sa refactorisation, sa réparation et sa réhabilitation. Les révisions de code sont un mécanisme que l'on peut utiliser pour exposer le code à la lumière du jour.