Imaginez le scénario suivant:

Vous avez détecté que votre programme (ou celui de quelqu'un d'autre) a un bogue - une fonction produit le mauvais résultat lorsqu'elle reçoit une entrée particulière. Vous examinez le code et vous ne trouvez rien de mal: il semble juste s'embourber quand on lui donne cette entrée.

Vous pouvez maintenant effectuer l'une des deux opérations suivantes: vous pouvez soit examiner le code plus en détail jusqu'à ce que vous ayez trouvé la cause réelle; ou vous frappez sur un bandage en ajoutant une ifinstruction vérifiant si l'entrée est cette entrée particulière - si c'est le cas, retournez la valeur attendue.

Pour moi, appliquer le bandage serait totalement inacceptable. Si le code se comporte de manière inattendue sur cette entrée, à quelle autre entrée que vous avez manquée réagira-t-il étrangement? Cela ne semble pas du tout être une solution - vous ne faites que pelleter le problème sous le tapis.

Comme je n'envisagerais même pas de le faire, je suis surpris de la fréquence à laquelle les professeurs et les livres nous rappellent sans cesse que l'application de correctifs "bandage" n'est pas une bonne idée. Cela me fait donc me demander: à quel point ces types de «correctifs» sont-ils courants?

Les contraintes de temps / délais sont une des raisons.

Si vous êtes confronté à un délai serré et que votre patron respire dans le cou (peut-être littéralement!), Faire cela et penser "je reviendrai et corrigerai cela plus tard" est très tentant et pourrait être la seule chose que vous peut faire.

Bien sûr, le nombre de fois où vous revenez en arrière et le corrigez correctement est très rare, car vous avez un nouveau problème qui doit être corrigé hier.

Autant nous que les programmeurs n'aimons pas l'admettre, un logiciel magnifiquement codé ne se traduira pas toujours par plus de valeur pour l'entreprise ou les clients. Cela est doublement vrai dans une situation de catastrophe, par exemple le logiciel charge deux fois les cartes de crédit des gens. Parfois, comme un pansement, il vous suffit d'arrêter le saignement par tous les moyens nécessaires et de promettre de revenir une fois le patient stabilisé et de résoudre le problème principal.

L'astuce est que, une fois l'urgence passée, il est vraiment difficile de convaincre quiconque de donner la priorité au remplacement du bandage par un vrai correctif. Surtout si l'on considère qu'il y a toujours un autre problème urgent en attente derrière le premier. Il vous suffit d'être vigilant pour rester avec le problème au-delà de la solution miracle.

Temps

Est la raison n ° 1 à mon avis. Bien que si le problème est lié à la base de code, je pourrais prendre plus de temps pour l'étudier. Souvent, mes corrections de «bandage» impliquent des ajustements CSS ou UI. J'ai écrit des CSS et JavaScript en ligne assez méchants pour les traiter rapidement. Revenir en arrière et le réparer est toujours une option si vous avez le temps.

Nous les faisons exceptionnellement.

Pour les correctifs en cours de développement, nous nous assurons qu'aucun correctif n'est effectué sans connaître la cause première. Pourtant:

• Exceptionnellement, la recherche de la cause première commencera à prendre trop de temps ou à décrocher ET il y a un délai difficile,
• Exceptionnellement, les modifications de code pour corriger la cause première ne sont pas tactiquement réalisables (le changement prendra trop de temps et la date limite approche)

Dans ces cas, nous optons pour des correctifs "bandage". Nous ouvrons ensuite des défauts internes pour résoudre la cause première. Oui, le plus souvent ces défauts internes sont traités avec une très faible priorité.

Pour les correctifs dans le flux de maintenance, nous nous assurons qu'aucun correctif n'est effectué sans connaître la cause première. Pourtant:

• Très exceptionnellement, la recherche de la cause première s'arrêtera,
• Exceptionnellement, il peut arriver que la résolution de la cause racine ne soit pas tactiquement réalisable (le changement n'est pas anodin et le client a eu besoin du correctif hier).

Dans ces cas, nous optons d'abord pour le correctif temporaire «bandage» et une fois que le client est satisfait, nous travaillons sur le correctif approprié et ce n'est qu'ensuite que le défaut est résolu.

Désambiguïsation.

• Étant donné un bug particulier, il est très difficile de définir objectivement si un correctif particulier est un «bandage» car: la «bonne solution» peut être le «bandage» d'une autre personne.
• Donc, j'utilise la définition suivante: réparer un défaut d'une manière moins élégante et moins bien étudiée que je l'aurais souhaité de manière professionnelle.

Tout d'abord, en ce qui concerne la fréquence des corrections de «bandage»:

• Nouveau code: presque aucun.
• Ancien code:
  • Vous en trouverez, bien qu'ils soient généralement écrits avec assez d'élégance (voir «Atténuation basée sur les données» ci-dessous) pour ne pas ressembler à des bandages et survivre à toutes les révisions de code.
  • Faites également attention au "bandage invisible": n'appelez tout simplement pas cette fonction. Avec le manque de code, il n'y a même pas la moindre trace d'indication qu'un bogue existe.
• Ancien code avec de nombreuses dépendances externes:
  • Presque plein de lui.
  • Il a été presque toujours écrit pour une version obsolète de la dépendance, et personne n'a vraiment lu les "notes de version" de la dépendance avant de mettre à jour la dépendance vers une nouvelle version.

Deuxièmement, mon conseil:

Si le bogue se produit dans le propre code source d'une équipe de développement:

• Réparez-le de manière professionnelle. (Si vous le corrigez, vous le possédez.)
• Sous la pression du temps, faites de votre mieux - ce qui vous oblige à:
  • Examinez l'impact potentiel sur l'utilisateur final: du bogue lui-même et du correctif proposé, afin de décider d'accepter ou non le correctif.
  • Étudiez les extraits de code associés (en utilisant les informations d'historique de votre outil de gestion de code source) et discutez avec vos collègues (mais n'occupez pas trop de temps) jusqu'à ce que vous ayez bien compris le problème et la solution.
• Suivez toujours le bug avec un système de suivi des défauts .

Si le bogue se produit dans le code source d'une autre équipe:

• Poussez cette équipe pour corriger son bug.
• Déposez toujours ce bogue avec le système de suivi des défauts de l'autre équipe .

Si le bogue se produit dans le produit d'une autre entreprise (ou d'aucune entreprise):

• Dans ce cas, les correctifs du ruban adhésif (ou les solutions de contournement basées sur les données ) peuvent être le seul moyen de corriger le bogue.
• S'il est open source, limitez ce bogue avec un système de suivi des défauts (éventuellement public) de toute façon, afin que quelqu'un puisse l'examiner.

Cela dépend beaucoup de l'âge de la base de code, je pense. Sur l'ancien code, je pense que c'est très courant, réécrire que la routine COBOL vieille de 20 ans n'est pas amusant. Même sur du code modérément nouveau qui est en production, il est encore assez courant.

Je dirais que c'est très courant.

Consultez le blog de Joel Spolsky: The Duct Tape Programmer

Je peux facilement dire qu'à peu près tous les projets auxquels j'ai participé, j'ai dû appliquer une sorte de pansement ou de ruban adhésif pour respecter les délais et terminer une tâche. Ce n'est pas joli, ce n'est pas propre, mais cela fait le travail pour qu'une entreprise puisse continuer à fonctionner et que le projet puisse avancer d'une manière ou d'une autre.

Il y a une différence entre le monde universitaire et le monde réel où les logiciels doivent être livrés dans des délais et des contraintes commerciales.

D'une certaine manière, il le met sous le tapis, pour différer une solution, jusqu'à ce que, espérons-le, plus tard. Malheureusement, trop souvent, le correctif différé ne se produit jamais et ce code se retrouve en production.

C'est difficile à dire sans plus de contexte - dans votre exemple, pourquoi l'ajout de l'instruction if n'est-il pas le correct correct? Est-ce parce qu'il y a censément un autre bloc de code quelque part qui est censé traiter cette entrée?

La fréquence à laquelle les correctifs de bandage sont utilisés dépend d'un certain nombre de facteurs tels que la complexité du code, la disponibilité de la personne la plus familière avec le code (la personne responsable de la routine COBOL de Craig, âgée de 20 ans, peut avoir quitté l'entreprise il y a des années ) et les délais concernés.

Avec une échéance qui vous regarde en face, vous serez parfois repulpé pour la solution la plus sûre, même s'il s'agit simplement de gifler un plâtre plutôt que de réparer la cause profonde. C'est ok tant que vous n'aggravez pas les choses, mais il est important de suivre le fait qu'il n'est toujours pas correct et doit encore être corrigé correctement.

Il y a des cas où ce type de correctif est vraiment OK et probablement l'idéal (en ce qui concerne le temps de débogage).

Imaginez un scénario dans lequel vous avez 20 DLL qui sont censées agir comme une sorte de modules pour votre exécutable principal, mais nécessitent également des informations de l'exécutable principal pour s'exécuter.

Si vous souhaitez utiliser ces DLL en dehors de l'exécutable principal, vous devrez supprimer certaines valeurs de retour de l'exécutable principal. A.) Il n'existe pas dans ce contexte et B.) Vous ne voulez pas qu'il existe dans ce contexte.

Cela étant dit, vous feriez mieux de mettre quelques directives de compilation dans votre code pour vous assurer que vous exécutez un code complètement différent lorsque vous truquez les résultats par rapport à lorsque vous obtenez les vrais résultats.

Au lieu de mettre un à l' ifintérieur de la fonction de quelqu'un d'autre, je mettrais un {$ifdef}autour de la fonction - de cette façon, personne ne le confond avec quelque chose qui devrait être là.