Frederic de Villamil


,


Partagez sur Twitter Partagez sur Facebook Partagez sur Google Plus Partagez sur Linkedin Plus

Bugs : ces obstacles hypocrites qui façonnent nos habitudes

Deux bugs en phase de reproduction

Aucun logiciel ne peut être garanti 100% bug free. Même un “hello world” peut planter dans des cas extrêmes malgré son apparente simplicité. Même avec les meilleures batteries de tests au monde, un cas particulier non prévu peut toujours survenir.

Certains bugs peuvent être franchement bloquants, d’autres, simplement gênants parce qu’un contournement permet de continuer à utiliser l’application dans des conditions suffisamment satisfaisantes.

Que l’on se place du point de vue de l’utilisateur ou du fournisseur d’application, les bugs avec contournement sont parmi les pires qui soient.

S’il s’agit de bugs fonctionnels, et que votre application propose un contournement acceptable, c’est sans doutes parce qu’elle est trop complexe. Je ne sais plus qui disait à propos de Perl – peut-être moi – s’il existe plusieurs manières de le faire, il y en a au moins une de trop.

Dans tous les cas, ces bugs sont une réelle plaie, car l’existence d’une solution de contournement fait qu’ils ne sont pratiquement jamais corrigés, et souvent jamais remontés.

C’est une question de paresse intellectuelle. Nous sommes tous paresseux, et de deux efforts choisissons toujours le moindre.

Personne n’aime remplir un formulaire, qui pis est pour remonter un problème. Malgré une avancée certaine dans ce domaine, les outils de remonté de bugs ont encore beaucoup de chemin à faire. Remplir une déclaration, chercher un email de contact, tout cela demande un effort supplémentaire. Si l’effort supplémentaire à fournir est supérieur à celui nécessaire pour contourner le bug, celui-ci ne sera jamais remonté.

Il y a encore peu de temps, j’utilisais quotidiennement une application qui n’avait pas mis en place de redirection POST vers GET au login. Cela n’aurait pas été réellement gênant si la majorité de son utilisation ne s’était faite sur la page d’accueil : à chaque fois que je rechargeais la page pour afficher les nouveautés – ou pour voir s’il y en avait malgré l’absence de notification – une alerte du navigateur me demandait ad nauseam si je souhaitais à nouveau valider le formulaire de login, même après plusieurs heures d’utilisation.

Au regard du fonctionnement normal d’une application Web, il s’agit d’un bug. Il n’est pas bloquant, puisqu’il n’empêche pas son utilisation : il suffit d’accepter de renvoyer les données, ou de cliquer une fois dans la barre d’URL et d’appuyer sur entrée pour ne plus rencontrer le problème jusqu’à la fermeture du navigateur.

Et là… c’est le drame !

Même si elle peut parfois sembler évidente, la mise en oeuvre de la solution de contournement nécessite un apprentissage. Il peut être le fruit d’une découverte, ou enseigné par un autre utilisateur, une recherche sur le Web, ou un service d’assistance à l’utilisateur. Dans tous les cas, pour tous ceux qui y sont confrontés, l’apprentissage fait de la rustine la manière “normale” d’utiliser l’application.

Une fois le bug corrigé, un nouvel apprentissage est nécessaire afin de passer par le chemin initialement prévu. La solution de contournement devient ainsi le parcours fonctionnel de fait pour tous les utilisateurs exposés au bug. Toute suppression de la solution de contournement entraine donc une frustration chez ces utilisateurs qui doivent réapprendre à utiliser leur application et peuvent y voir une régression fonctionnelle.

En tant que développeur sur des projets open source, j’ai toujours un sentiment mitigé face à la correction de bugs.

D’un côté – je l’avoue volontiers – ça me fait franchement chier de reprendre du code foireux pour aller corriger un truc que j’ai mal pensé si ce n’est pas bloquant, encore plus si personne n’a ouvert de ticket. Je préfère laisser ça à Yannick, Matijs ou Thomas, il en profite pour refactoriser la moitié du code et rajouter une bonne couche de tests. Je préfère amplement améliorer l’existant ou ajouter de nouvelles fonctionnalités. C’est humain, et je suis certain de ne pas le seul à le ressentir.

D’un autre côté, je suis toujours fier de pouvoir fermer un ticket ouvert, parce que cela signifie que, quelque part dans le monde, un utilisateur est satisfait. Et transformer un bug report en un utilisateur satisfait, ça n’a pas de prix.