veilletech.frLe point de départ
Les journaux d'un service en production se remplissent d'un message d'alerte signalant qu'une ressource n'a pas été libérée avant d'être ramassée par le garbage collector. Des milliers de fois.
Le réflexe immédiat est de conclure à une fuite mémoire. Voici comment l'auteur est passé de ce constat à un correctif livré par Microsoft en quelques semaines.
La première règle, et la plus difficile
Toujours supposer que vous avez tort.
Le raisonnement est solide : votre code change tous les jours, surtout sur une fonctionnalité en cours de développement. La bibliothèque incriminée — ici Netty, sur laquelle repose le SDK utilisé — tourne chez des milliers d'entreprises. La probabilité penche lourdement d'un côté.
C'est là que l'auteur a passé l'essentiel de son temps : à chercher si le problème venait de lui.
Et il souligne un point qu'on oublie : ce temps n'est jamais perdu. Si c'est votre erreur, vous la corrigez et vous passez à autre chose. Si ce n'en est pas une, vous participez alors à ce qu'il décrit comme la partie la plus saine du développement logiciel — le signalement de bug.
Ce qui distingue un bon rapport
Le récit détaille le cheminement plutôt que le résultat, et c'est là sa valeur. Un rapport qui montre :
- ce qui a été essayé et écarté
- les hypothèses testées, avec leur résultat
- une reproduction minimale
a infiniment plus de chances d'aboutir qu'un message décrivant un symptôme.
La raison est prosaïque : décrire ce qu'on a déjà vérifié épargne au mainteneur de refaire le chemin. Quelqu'un qui reçoit des dizaines de tickets doit trancher lesquels méritent son temps, et un rapport qui prouve le travail déjà fourni remonte immédiatement dans la pile.
À retenir
Savoir déboguer, reproduire et signaler est une compétence en soi. Elle commence par une posture — supposer qu'on a tort — et se termine par un document qui fait gagner du temps à quelqu'un d'autre.
Source : blog.tymscar.com