Définir le bon état d’esprit de débogage pour les défauts, les erreurs et les bogues

L’un des plus grands défis de développement auxquels sont confrontés les développeurs de logiciels embarqués est le temps qu’ils passent à déboguer leurs systèmes. En moyenne, les développeurs passent 40 % de leur temps à déboguer !

C’est maintenant une moyenne, lorsque je demande lors d’une conférence « Combien de temps passez-vous à déboguer ? », Je constate que 40 % semblent correspondre aux résultats d’une enquête, mais ce n’est qu’une moyenne. Il y a aussi des développeurs qui passent jusqu’à 80 % de leur temps à déboguer !

Pour un projet moyen de 12 mois, si vous êtes un développeur moyen qui passe 40 % de son temps à déboguer, vous passez près de 5 mois chaque année à déboguer ! C’est une folie absolue étant donné que le débogage est vraiment un travail d’échec, c’est-à-dire qu’il corrige quelque chose qui a été mal fait la première fois.

Nous allons explorer l’état d’esprit des bogues et commencer à définir comment les défauts, les erreurs et les bogues sont liés.

Les insectes sont le fruit de votre imagination

Quand il s’agit de définir ce qu’est un bogue, débarrassons-nous simplement des subtilités et arrachons le pansement tout de suite. Un bogue est une erreur ou une erreur qui est injectée dans un système par un développeur en raison d’une mauvaise compréhension d’une spécification, d’une mauvaise compréhension du matériel ou d’une négligence générale. Aie!

Cela fait vraiment mal, mais la vérité est que les bogues ne se contentent pas de ramper dans notre code et nos systèmes, ce sont des erreurs causées par un ingénieur qui transfère la responsabilité de lui-même à un bogue imaginaire qui s’est levé et a rampé dans le système et a causé un problème .

Les bogues logiciels sont inévitables, nous ne sommes que des humains et nous ne pouvons pas être parfaits. Les systèmes que nous construisons sont complexes et il n’y a aucun moyen de réussir à chaque fois du premier coup. Je serai le premier à dire que j’étais l’une de ces personnes qui ont levé la main en disant que je passais 80 % de mon temps à déboguer.

Aujourd’hui, je dépense bien moins de 20 pour cent et c’est parce que j’ai changé mon état d’esprit sur ce qu’est un bogue, j’en ai pris la responsabilité et j’ai changé ma façon de programmer pour minimiser les bogues. Le résultat a évidemment été une productivité accrue, moins de temps passé à refaire les choses et moins de délais manqués. Les bogues sont un terme assez large et générique, alors arrêtons de penser aux bogues et considérons plutôt les erreurs et les défauts.

Définir les erreurs et les défauts

Une erreur est une erreur commise par un programmeur lors de la mise en œuvre de la conception du logiciel. L’erreur peut provenir d’un malentendu dans une spécification ou une exigence. Les erreurs peuvent être évitées en effectuant des revues et en discutant avec les parties prenantes pour assurer une bonne compréhension de la conception.

Un défaut, en revanche, est une erreur qui résulte d’interactions ou de comportements imprévus qui se produisent lors de la mise en œuvre du logiciel. Les défauts peuvent être gérés de plusieurs manières, notamment en utilisant des harnais de test, un développement piloté par des tests, des tests d’intégration, etc. Parfois, vous ne savez tout simplement pas ce que vous ne savez pas jusqu’à ce que vous écriviez du code et découvriez que vos hypothèses étaient fausses.

Je pense qu’il est important que les développeurs reconnaissent que nous sommes responsables de la prévention des erreurs et des défauts et pas seulement de leur suppression. Nous pouvons nous épargner beaucoup de douleur et de stress et réduire les délais et les coûts de développement en évitant les défauts et les erreurs en premier lieu.

Si nous ne pouvons pas les empêcher, nous voulons au moins les trouver le plus rapidement possible. Plus un bogue reste longtemps dans le code, plus il faudra de temps pour le trouver, le comprendre et le résoudre.

La pyramide de gestion des défauts

Prévenir les erreurs et les défauts revient à aborder correctement la pyramide de gestion des défauts que vous pouvez voir ci-dessous :

La base de cette pyramide est constituée des processus de conception. Ce sont les techniques que nous utilisons pour nous assurer que notre conception est solide et que nous traduisons correctement les exigences en une conception qui peut être construite et répondre aux besoins des systèmes et des utilisateurs. Passer du temps ici pour nous assurer que nous faisons les choses correctement constitue notre base pour minimiser les défauts et les erreurs.

Ensuite, nous avons nos processus de développement. Ce sont les techniques que nous utilisons pour développer notre logiciel. Utilisons-nous des techniques telles que le développement piloté par les tests pour créer des tests qui pilotent notre implémentation logicielle et construisent des faisceaux de tests automatisés pour détecter les problèmes ? Écrivons-nous du code modulaire ? Commentons-nous notre code afin que nous puissions comprendre nos décisions de conception ?

Même le respect des meilleures pratiques et des normes de codage peut tous s’inscrire dans ce domaine et nous aider à minimiser les défauts et les erreurs.

Enfin, le sommet de la pyramide est les techniques de débogage. Les techniques de débogage sont des choses comme l’utilisation d’un analyseur de trace pour surveiller l’exécution du code. Utilisation d’assertions, de points d’arrêt, d’instructions printf, d’analyses statistiques, d’analyses de pile, etc.

Ce sont les techniques qui, une fois que nous avons un bogue, nous aident à le trouver. Ceux-ci sont très importants, mais si nous pouvons empêcher les défauts et les erreurs de se produire en premier lieu, alors nous n’avons pas à nous fier à ceux-ci pour nous amener à la production.

Le problème que je vois le plus souvent est que nous ne comptons pas sur la pyramide de gestion des défauts pour minimiser les bugs et les défauts. En fait, de nombreuses équipes ont cette pyramide, mais elle est complètement renversée ! Nous nous appuyons le plus sur les techniques de débogage pour gérer nos bogues, puis les processus de développement et enfin la conception.

C’est là que les développeurs perdent en moyenne 40 % de leur temps ! Nous devons retourner la pyramide pour qu’elle soit à l’endroit et commencer à nous concentrer sur les processus de conception et de développement qui empêchent les défauts et les erreurs en premier lieu.

Conclusion

Les développeurs sont devenus trop à l’aise pour blâmer les bogues tout le temps qu’ils passent à déboguer. Aujourd’hui, nous avons discuté du fait que nous devons changer notre état d’esprit et oublier les bugs et introduire des défauts et des erreurs dans notre langage afin que nous assumions la responsabilité de nos « bugs ».

Nous avons également vu que nous pouvons tirer parti de la pyramide de gestion des défauts pour nous guider vers où concentrer nos efforts si nous souhaitons passer moins de temps à résoudre les problèmes et plus de temps à innover.