L’histoire du mot « bug » fascinera tous nos lecteurs geeks et les autres… Le mot provient-il de ce papillon de nuit conservé par l’informaticienne Grace Hopper parce qu’il avait fait buguer le calculateur de l’université Harvard aux Etats-Unis ou le « bug » préexistait-il à cette anecdote ? Sa version française, bogue, est-elle réellement utilisée ou la métaphore avec la bogue de châtaigne ne pique pas l’intérêt des développeurs français ? Quels bugs historiques, bug de l’an 2000, vol inaugural d’Ariane 5, sont sources d’angoisse pour les développeurs du monde entier ? Notre article ne prétend pas répondre à ces questions essentielles et préfère se concentrer sur la définition maison du bug avec Nicolas et Marc, développeurs de talent chez Oniti.
Un problème de connexion ponctuel ? C’est un bug. Le navigateur qui refuse de répondre ? C’est un bug… Un clic sans réponse ? C’est aussi un bug !
Côté développeur, le bug fait partie du process : on code, on teste, on recette, on passe en prod’. A chaque étape, les différents cas de figure sont envisagés pour réduire le nombre de bugs. Pour autant, comme le dit l’adage : « il n’existe pas d’application sans bug ».
Adage qui s’appuie sur la réputée loi de Murphy : « S’il existe au moins deux façons de faire quelque chose et qu’au moins l’une de ces façons peut entraîner une catastrophe, il se trouvera forcément quelqu’un quelque part pour emprunter cette voie. »
Alors, que fait-on quand ça bug ?
La première chose à faire, nous expliquent Nicolas et Marc, est de reproduire le cas de figure évoqué par l’utilisateur : les informations de contexte, les identifiants utilisés, les actions qui ont mené jusqu’au bug.
C’est l’étape clé, le graal du bug !
Mais ce n’est pas toujours si simple : l’utilisateur ne se souvient plus comment il a fait, cela fonctionne sur un navigateur mais pas sur un autre, cela dysfonctionne de façon aléatoire, etc. Reproduire le bug n’est pas si facile.
Une fois le problème identifié, le corriger peut se révéler simple, ou pas…
Pour Nicolas et Marc, les bugs les plus complexes sont ceux provenant d’outils extérieurs dont ils ne sont pas à l’origine. « Pour le développement, on utilise des librairies : des framework, des outils développés par la communauté de développeurs et maintenus à jour sur le net, souvent en open source. Quand ces outils ont des bugs, si le cas de figure n’a pas encore été signalé, soit on attend un correctif, soit on le crée nous-même. Dans tous les cas, cela peut être très chronophage. Pour éviter cette gestion, chez Oniti🌿, nous optons pour des technos éprouvées et suivies par une communauté de développeurs nombreux et actifs. »
Nous espérons, que ce tour d’horizon du bug aura changé votre regard sur les plantages, bogues, et autres papillons de nuit. Mais nous tenons à vous rassurer cependant : les petits insectes ne viennent plus se cacher dans les ordinateurs. Les erreurs de programme sont dans le code ; charge à nous de les y débusquer…
