Bienvenue dans l’épisode 15, sur le debugging.
On ne va pas parler des méthodes de résolution de bugs,
qui vont dépendre de chaque langage, plateforme, et bug bien sûr.
Ce qui va m’intéresser ici c’est de voir comment un bug peut arriver,
comment le résoudre, et comment gérer ce qui se passe humainement
durant les étapes de résolution du bug.
Là encore j’ai de quoi faire une petite série, pour l’instant en
deux épisodes : aujourd’hui sur la détection et la réaction au bug,
et la semaine prochaine sur la résolution du bug. Il n’est pas
impossible que d’ici quelque temps on reprenne le sujet si ça vous
intéresse et si je trouve encore d’autres choses à dire.
Quoi de neuf, docteur ?
Pour ne pas épuiser la métaphore sur la voiture, et parce que bien
souvent on rabaisse les développeurs à des exécutants techniques,
je vais plutôt choisir une métaphore filée sur la médecine.
On parle parfois d’un développeur sur un bug comme d’un pompier,
un démineur, mais je n’aime pas le côté urgence forcée, et l’absence
de responsabilité que cela sous-entend.
Pour moi, intervenir sur un bug, c’est comme être le médecin traitant
face à quelques symptômes. On pourrait dire chirurgienne, mais j’aime
moins l’aspect d’intervention certes d’une haute technicité,
mais ponctuelle et qui ignore la santé globale : à résoudre les soucis
un par un, on peut facilement oublier d’avoir une vision générale.
Les causes
Je suis obligé de commencer par la définition du mot “bug”
la plus générale qui soit : quelque chose d’inattendu ou de néfaste
que l’on attribue (à tort ou à raison) à votre système.
Et donc la cause la plus générale qui soit, c’est qu’un postulat
sur lequel vous vous basiez… n’est plus valide en ce moment.
Ça peut être dans votre infra, vos données, votre code,
votre documentation ou vos spécifications.
Pour être clair, il y a quelque chose de :
Ou enfin, tout simplement, c’est que votre code est en défaut.
Le corps médical a le même problème : outils cassés, prescriptions mal
suivies parce que pas claires ou trop contraignantes, situation imprévue,
combinaison de médicaments ou de maladies aux effets combinés désastreux…
Sans parler de l’environnement global du patient qui serait toxique ou
délétères (mauvaises habitudes…) et ça finit toujours pareil :
quelqu’un va voir son ou sa médecin (qui est rarement la cause du souci),
exige une solution (rapide si possible), et le tout sous peine de
conséquences (parfois dramatiques).
Le message n’est pas clair
De même, un diagnostic est parfois difficile quand il y a une ou
plusieurs causes de départ, mais qu’on ne les voit pas parce que
les informations sont cachées, conflictuelles, similaires à un
autre cas… pensez à la série Dr House si vous voulez un exemple.
Mais, c’est pas mon problème ?
Pourquoi ai-je tenu à faire cette liste si longue et qui parle si peu de code ?
Tout d’abord parce que les cas de la vraie vie sont au moins aussi nombreux.
Mais aussi parce qu’on tentera d’attribuer des erreurs de ces huit catégories-là à votre code, faute de mieux comprendre ou par calcul
politique. Pour être clair, parce qu’il y a quelqu’un qui pense
“ce bug, c’est pas mon problème”.
Enfin, pour ne pas vous entendre, en tant que développeurs et développeuses, dire ce genre de phrase.
Parce que toutes ces catégories sont ou devraient être de votre ressort :
comprendre les implications des choix en amont, en aval, savoir dire non
et expliquer les options à ceux qui feront les choix.
Accepteriez-vous de voir un médecin qui se dédouane de vos problèmes ?
Un ou une médecin a une position de prestige, de pouvoir, et vous êtes
en position de dépendance. Les sujets abordés vous touchent directement.
Les décisions ont intérêt d’être claires et concises.
On n’accepte pas d’être cobaye, de jouer aux devinettes.
Toute action doit être motivée et expliquée, y compris quand il s’agit
de se dessaisir du sujet pour le confier à un confrère ou une consoeur.
Et pourtant, on serait tellement en colère de voir une décision
hâtive et fausse prise avec autorité et aplomb, se révéler fausse :
on se sentirait trompé, on perd confiance, on peut se mettre en colère !
Mais à l’inverse, ça donne davantage confiance de s’entendre dire
“je ne sais pas, on va chercher” ou
“j’ai une piste, on va faire des examens pour confirmer”,
ou encore “j’ai plusieurs pistes, on va tester pour voir”.
Avant le bug : monitoring
Je n’ai pas retrouvé de source mais Toyota avait une manière de
décrire les problèmes, non par leurs conséquences comme souvent,
mais comme étant une déviation de la norme.
Les tests médicaux, analyse ou monitorings sont chers ou pas pratiques.
On aura tendance à ne les faire que quand tout va mal. C’est un peu
dommage, et c’est pourquoi on encourage non seulement à un suivi de
ce qui a été mal un jour, mais aussi parfois à un checkup régulier.
Avant de se dire ce qui est normal, il faut pouvoir le suivre,
savoir ce qui est dans la norme ou pas. Et encore, pensez à la
météo, aux pollens ou aux grippes : il y a la norme saisonnière.
Pour un site web de commerce, par exemple, quelles sont les heures,
les jours de la semaine, les périodes de l’année les plus importantes ?
Après le décès de Michael Jackson, Google a reçu tellement de requêtes
qu’ils ont cru à une attaque. Après chaque événement marquant, Wikipedia
reçoit un flot de modifications plus ou moins légitimes : il est important
d’avoir un plan d’action, même s’il dit juste “attention, il se passe
davantage de choses que la normale”.
Identification du bug
L’identification d’un problème est facilitée si vous avez un monitoring
en place. Sinon, c’est souvent par hasard, par chance (en anticipation),
ou parce que les conséquences de votre bug vont remonter avec bruit.
Je pense qu’il y aurait beaucoup à dire, et chaque métier a probablement
ses moyens d’améliorer et d’anticiper l’identification de problèmes,
mais ça dépend tellement de chaque cas que je vais arrêter là.
À la semaine prochaine !
Et voilà, on a vu ce qu’on peut faire avant et au moment où l’on
détecte un problème, à la semaine prochaine pour voir comment on
peut réagir et corriger ce bug !
