Débogage: comprendre les détails expliquant pourquoi certains correctifs ont fonctionné? [fermé]

Lors du débogage, je trouve parfois que j'apporte des modifications et je ne suis pas sûr à 100% pourquoi ces modifications corrigent un bogue dans le programme. Est-il essentiel de comprendre chaque détail sur la raison pour laquelle certains bogues se sont produits et pourquoi certaines modifications ont éliminé ces bogues? Ou est-il courant chez les développeurs de faire parfois fonctionner le programme sans vraiment connaître les détails de la raison pour laquelle le correctif a fonctionné?

Je dirais qu'il est essentiel de comprendre chaque détail sur la raison pour laquelle certains bogues se sont produits et pourquoi certaines modifications ont éliminé ces bogues, et il est également courant chez les développeurs de faire parfois fonctionner le programme sans vraiment connaître les détails de la raison pour laquelle le correctif a fonctionné!

L'art de changer les choses jusqu'à ce qu'un bogue disparaisse, sans comprendre ce qui l'a causé ou pourquoi le changement l'a corrigé, est souvent appelé «programmation vaudou», et ce n'est pas un compliment. Il n'y a vraiment aucun moyen de vous assurer que vous avez vraiment corrigé un bogue, au lieu de le corriger partiellement pour le cas particulier que vous enquêtiez, si vous ne comprenez pas ce qui l'a causé.

Dans le pire des cas, vous n'avez rien fait du tout, sauf déplacer le bug: Je me souviens de la première année d'informatique à l'université, lorsque de nombreux étudiants apprenaient le C et les pointeurs pour la première fois, les bugs de pointeur cessaient souvent de se manifester lorsqu'ils changeaient les choses. au hasard, car les modifications réorganiseraient les structures de données en mémoire suffisamment pour que le bug du pointeur écrase un bit de mémoire différent. Évidemment, cela n'a pas aidé du tout .

Mais cela dit, les réalités commerciales de la programmation sont souvent telles qu'il est plus important de satisfaire le client qu'un bug est corrigé que de se satisfaire. Je ne vous recommanderais jamais de déclarer quelque chose de fixe si vous n'aviez aucune idée de la cause, mais si vous pouvez voir qu'un code était problématique, et que vous l'avez retravaillé, même si vous n'êtes "pas sûr à 100%" de la façon dont cela a causé le problème spécifique. bogue à manifester, il suffit parfois de passer au bogue suivant avant que le client ne crie trop fort au sujet de votre lente progression.

Si vous pensez qu'un client est fou qu'il prenne trop de temps pour corriger un bogue, imaginez à quel point il sera fou d'un bogue récurrent qui, selon vous, a été corrigé, ou d'un correctif pour une chose qui aggrave quelque chose d'autre. Si votre correctif n'est qu'une solution de contournement ou d'atténuation, les clients l'accueilleront généralement toujours, mais vous devez être honnête à propos de ce qu'il est, et vous mettez autant de journalisation que nécessaire pour le corriger pour de vrai.

Si vous êtes sûr de l'avoir corrigé, mais que vous ne savez pas pourquoi le correctif fonctionne, demandez à quelqu'un. La plupart des ingénieurs que je connais aiment recevoir des questions comme ça à cause du mystère qui se cache derrière.

Changer des choses jusqu'à ce que le bug ne soit plus là est généralement une mauvaise pratique, mais malheureusement une réalité pour certaines personnes.

Je suis d'avis que vous ne devez jamais écrire de code si vous ne comprenez pas ce qu'il fait ou pourquoi il le fait. Comment pouvez-vous être sûr que même si vous avez corrigé le bogue que vous vous êtes fixé pour corriger - vous n'avez rien cassé d'autre?

Généralement, avant de résoudre un problème / bogue, vous devez effectuer une évaluation / analyse de la cause sous-jacente pour déterminer pourquoi le problème se produit et s'il peut être répliqué. Ensuite, vous devriez lire le code et comprendre pourquoi le code provoque le bug. Une fois que vous avez compris: alors vous pouvez commencer à voir comment résoudre le problème et déterminer d'autres domaines sur lesquels vos changements auront un impact. Les tests unitaires peuvent vraiment aider ici!

J'ai vu un certain nombre de modifications de code que les gens ont apportées pour résoudre un problème (ce qui est génial), mais cela a malheureusement introduit d'autres problèmes parce que le développeur n'était pas au courant de l'impact total de ce qu'ils avaient changé. Beaucoup de ces "correctifs" obscurcissent simplement la cause sous-jacente du problème d'origine ainsi que la complexité et d'autres bogues.

Cela dit, j'ai résolu un certain nombre de problèmes dans le code uniquement par association. Où j'ai changé / retravaillé / refactorisé quelque chose et corrigé d'autres bugs en suspens. Donc, bien que je ne sache pas ce qui les a causés à l'origine, j'ai trouvé du code douteux et je l'ai "corrigé" - ce qui a également corrigé ces bogues. Je couvre les changements comme celui-ci avec des tests unitaires et d'intégration pour garantir l'intégrité des exigences commerciales et techniques de la fonction.

Ou est-il courant chez les développeurs de faire parfois fonctionner le programme sans vraiment connaître les détails de la raison pour laquelle le correctif a fonctionné?

Il y a au moins trois gros problèmes avec cela:

1. Cela conduit à un état d'esprit de magie noire où vous abandonnez l'idée que vous pouvez comprendre le code et au lieu de cela commencez simplement à déplacer les pièces en espérant que les problèmes disparaîtront. C'est l'équivalent de la programmation de mettre de la nourriture dans votre assiette, en espérant donner à votre dîner un aspect suffisamment mangé pour que vos parents ne vous fassent pas manger plus de vos légumes.

2. Vous ne pouvez pas savoir que le bogue est réellement corrigé ou simplement masqué par votre modification à moins que vous ne compreniez a) quel était le problème et b) comment votre changement résout le problème.

3. Le bug n'est probablement pas corrigé , et il va vous mordre à nouveau dans un proche avenir.

Je vois deux scénarios: vous avez travaillé sur autre chose et le bug a cessé de se produire, tant que quelque chose d'autre n'a rien cassé d'autre, vous devez à peu près laisser cela entrer - vous avez fait ce qui était nécessaire / voulu et il avait un effet secondaire positif imprévu et inexplicable.

L'autre est que vous travaillez sur ce bogue et qu'un changement aléatoire a fait fonctionner les choses, c'est inacceptable. Si vous n'avez aucune idée de ce que l'ancien code faisait mal, vous n'avez probablement aucune idée de ce que le nouveau code fait mal.

Je ne peux pas vraiment penser à une bonne raison de vérifier le deuxième cas - s'il s'agit d'un bogue critique, il est essentiel de le corriger. S'il s'agit d'un bogue non critique, vous pouvez au moins être sûr que vous n'introduisez pas de bogue critique avec votre "correction".

Ou est-il courant chez les développeurs de faire parfois fonctionner le programme sans vraiment connaître les détails de la raison pour laquelle le correctif a fonctionné?

Pour ma part, je pense que c'est très très courant de nos jours. C'est à cause de Google et de Stackoverflow. Vous avez un problème avec votre code, il suffit de le rechercher sur Google, de trouver une solution, de le corriger, de passer au problème suivant.