Articles « Info » : Développeur

Entomologie (étude des insectes)
    Certains mots nous alarment dès que nous les entendons, car nous les avons souvent trouvés par le passé au cœur de certains problèmes ou situations obscures. Un de ces signaux d'alarme est le mot "bug", c'est-à-dire non un représentant de l'espèce des Hémiptères, mais bien un de ceux que l'on trouve dans les programmes informatiques.
[Et pourtant, il n'est pas inutile de rappeler l'origine bien animale de ce terme "bug" - insecte en anglais - et qui fut, à l'origine, une mite - "moth" - : cf. illustrations]
    Cela ne me dérange pas d'entendre les gens parler de "bug" - vous m'entendrez souvent parler moi-même de "bug", lors de situation où je n'ai pas à être précis. C'est une toute autre histoire lorsque des décisions découlent de ce dont je parle, car une large part de ce qui importe à un professionnel du logiciel est lié d'une façon ou d'une autre aux "bugs". En tant que développeur de programmes, j'ai de profonds soupçons quant au mot "bug" dans des contextes professionnels. Je trouve le terme vague et presque sans intérêt dans la résolution de problème. Pire, j'ai souvent entendu des personnes employer le mot "bug" dans le seul but de blâmer ou d'éviter une responsabilité.
 
Comptes d'une équipe incertaine

    J'ai travaillé une fois pour un famille de programmes que mon employeur avait acquis d'une compagnie qui se retirait du marché. Je fus consulté rapidement à l'ouverture des négociations et une des choses que mon patron mentionna fut la "liste des bugs" du produit, liste qui en comprenait, appris-je, 200.
    Quelques temps passa; les négociations se conclurent, assistées par une petite équipe de 1 technicien et 1 expert du domaine; l'acquisition se réalisa. Un peu plus tard, mon patron me demanda de prendre la direction de la partie technique du projet, afin de "stabiliser" le produit le préparant à un sérieux effort de vente. Lorsque je m'enquis de la "liste des bugs", j'entendis qu'elle avait été réduite à 5.
    Je ne croyais pas qu'une petite équipe travaillant sur un produit peu familier pouvait corriger 200 bugs en 3 semaines. J'étais intrigué et j'ai investigué un peu plus en profondeur. Il s'avéra que l'équipe d'acquisition avait passé en revue la liste et en avait ôté tous les bugs qui ne posait pas un soucis concret pour un client actuel. Cela explicita un peu les choses : une définition du terme "bug" qui m'est familière est "un souci concernant la qualité du produit", ou encore "un décalage entre les attentes de l'utilisateur et le comportement réel du programme". Si personne ne s'en inquiète, ce n'est pas un bug.
[Laurent Bossavit revient sur la définition de la qualité dans son interview]
    Peu de temps après, au cours d'une conversation avec mon patron, je fus à nouveau troublé. J'avais erré au travers du quart de millions de ligne de code C++ que le produit comprenait, afin de déterminer l'effort requis pour le "stabiliser". Je n'avais pas aimé de que j'y avais vu : du code-spaghetti, de la programmation pseudo-orientée-objet, d'immenses redondances entre modules, et tout un tas de mauvaises choses ["all manners of Bad Things"]. J'exprimais ces inquiétudes à mon responsable.
    « Ne vous inquiétez pas », me dit-il, « nous savons que la qualité du code est correcte. Après tout, nous n'avons seulement que 5 bugs connus ». Or, mon responsable était un ancien programmeur. Pour beaucoup de programmeurs, et le dictionnaire leur donnent raison, le terme "bug" signifie plus précisément un défaut ou une erreur dans un programme. Dans beaucoup de cas, cela signifie un défaut dans leur travail. Bien entendu, d'après cette définition, "pas de bugs" signifierait "pas de défauts".
   Je pensais, bien sûr, que mes inquiétudes devraient compter pour quelque chose. D'après la première définition de "bug" comme étant "un soucis concernant la qualité du logiciel", tout mes soucis auraient du être un "bug". Mes objections furent balayées en grande partie sous le prétexte que « dans la mesure où des utilisateurs emploient effectivement le produit et qu'ils ne se plaignent pas, on peut assumer que sa qualité est correcte ».
[on rejoint là la problématique de la qualité évoquée par Laurent Bossavit dans son interview: la qualité est aussi "ce qui est apprécié par une personne"...]
   Ce n'était pas entièrement exact : à une occasion nous avons été appelé pour résoudre un problème urgent à un site d'un de nos clients. « Y avait-il un bug ? », demanda mon collègue qui prit l'appel. L'utilisateur ne le savait pas. Tout ce qu'il savait, c'est que au démarrage de l'application, cela arrivait à la moitié de la phase d'initialisation avant de se planter. Nous vînmes sur site pour enquêter. Il s'avéra que le "bug" était une version corrompue du fichier dans lequel l'application sauvegardait la position des fenêtres ouvertes. Une fois restaurée une version correcte de ce fichier, tout revint à la normal. Nous n'avons pu faire planter de nouveau l'application.
    Une inspection du code concerné ne nous montra pas de problème évident. En tout cas, aucun problème évident pour nous. Mes collègues prétendirent qu'il s'agissait d'un "bug intermittent", plus dur à corriger puisqu'il ne pouvait être reproduit avec fiabilité. J'étais inquiet du coût potentiellement élevé en support si jamais un tel incident devait se reproduire régulièrement, mais en fin de compte, la décision fut de reporter ce problème à une date indéterminée.
    Personne ne semblait se sentir vraiment responsable - sans doutes avec raison. L'image du terme "bug" évoques celui de petites créatures rampantes incognito dans les programmes, au travers des interstices de notre compréhension, une image qui tend à absoudre le programmeur de la responsabilité des conséquences d'une programme "buggué". Tant qu'il ou elle a sincèrement fait l'effort d'ôter tous les "bugs" qu'il ou elle pouvait trouver, qui peut le ou la blâmer si certains demeurent dans le produit qui est finalement livré aux utilisateurs ?
    Ce qui me fit vraiment réagir, cependant, fut l'annonce d'un de mes collègue dans un rapport de situation comme quoi elle avait corrigé un "bug" dont j'étais responsable. Dans la mesure où ce rapport avait été transmis en copie à mon patron, l'enquêtais bien entendu plus avant.
   Voici ce que je trouva : dans la version originale de l'application, du code accédait illégalement à un bloc mémoire qui était libéré par une précédente application. Toutefois, puisque aucun appel lé à la mémoire n'était fait entre ces 2 appels, l'accès illégal était passé inaperçu. J'ai récemment modifié des parties de l'application non liées entre, ce qui a entraîné comme résultat une opération mémoire faîtes au point crucial. L'application se plantait maintenant, et n'avait pas planté avant : cela ne pouvait qu'être que de ma faute.

Qu'y a-t-il dans un mot ?
    Dans le contexte d'un projet, beaucoup de définitions et d'usages différents de "bug" ont fait surface : soucis concernant la qualité; décalage entre comportement et spécifications; ou entre comportement et attentes; plantage du produit pendant l'utilisation; erreurs de programmation; comportement répréhensible de la part d'un programmeur (moi).
[Rappelons que ce phénomène n'est pas isolé : cf. illustrations]
    Nous avons accepté tacitement ces différentes interprétations, sans vraiment réaliser à quel point elles avaient évoluées sur la durée du projet, comment différentes personnes soutenaient différentes interprétations en même temps, ou dans quelle mesure ces interprétations s'opposaient l'une à l'autre de différentes manières.
    Je suis complètement en accord avec Von Neumann : « Cela n'a aucun sens d'être précis lorsque vous ne savez même pas de quoi vous parlez ». Mais cela comporte un corollaire : Si vous savez de quoi vous parlez, être précis peut rapporter gros.
    Comme en toutes choses, cela comporte des compromis: une précision excessive peut impliquer ses propres risques, comme la perte de l'attention des gens. Une façon d'envisager les compromis est de penser en terme de courbe de compromis, comme illustré ci-dessous : vous devez faire attention aux compromis si vous êtes proche de la courbe des compromis, et si découvrez que tout gain résultant d'une augmentation de la précision (moins d'erreurs, moins de conflits évitables) doit être comparé à une augmentation des coûts (plus de formations pour les nouveaux embauchés, par exemple).

    D'un autre côté, d'après ma propre expérience; la plupart des équipes ne sont même pas sur la courbe des compromis. Elles sont dans la zone inférieure, celle où il est possible d'améliorer la qualité de la communication sans autres efforts importants supplémentaires.
    Une bonne façon d'améliorer la qualité est de passer un peu de temps au sein de l'équipe à discuter de l'emploi d'autres termes au sens plus explicite que celui de "bug". La littérature sur les logiciels en suggère plusieurs, tels que "faute" ["fault"], "échec" ["failure"], "défaut" ["defect"], "erreur" ["error"], "problème" ["issue"]. (Évidemment - et c'est un autre aspect du compromis -, la définition "exacte" de ces termes est sujet à débat parmi la communauté informatique. Je ne veux pas apparaître en faveur d'un ensemble de définition plutôt qu'un autre car cela nécessiterait un tout autre article.[... et pourtant, vous pouvez lire un exemple de définition de ces termes ici : Questionnaire Programmation : Bug (Réponses)]) Avec la terminologie vient des modèles et des techniques utiles, comme des diagrammes d'effets ["diagrams of effects"] pour tracer les causes des défauts, or une "triage des problèmes" ["issue triage"] afin d'éviter de perdre du temps sur des problèmes mineurs lorsque plusieurs requièrent notre attention.
    Si vous examinez un pile d'appels ["stack trace"] et pensez vous souvenir d'un endroit dans le code où vous craignez avoir passé un paramètre nul, vous ne corrigez pas un "bug". Vous essayez de localiser un défaut ["defect"], et vous avez un idée quant à son origine. Lorsque je travaille selon ce mode, les types de phrase que je veux entendre de mes collègues sont « mon hypothèse est que », « voyons si l'on peut reproduire cet état », « ceci élimine cela, donc... », etc. Si l'on trouve que les interactions avec les collègues programmeurs sont bien plus lentes car gênées par des phrases vagues ou des raisonnements imprécis, elles sont bien plus rapides lorsqu'elles sont supportées par un vocabulaire au champs plus large que le simple terme "bug", et par des raisonnements basés sur des cas de tests et des expériences contrôlées.
    Même si vous utilisez un terme vague comme "bug" de façon intentionnelle, par exemple pour désigner un "soucis concernant la qualité" dans le sens le plus général du terme, afin de provoquer l'examen approfondi de ces soucis, vous devriez être vague de façon précise : c'est-à-dire, soyez sûr que votre définition de "bug" soit connue explicitement par les participants de votre conversation. Assurez-vous qu'il est bien entendu qu'aucun blâme ou d'exclusion n'est attaché à ce terme.
    Au minimum, accordez-vous quelques secondes de réflexion à chaque fois que vous apprêtez à employer le mot "bug" au boulot, lorsque vous en corrigez un, si vous écrivez un rapport à propos d'un bug, ou pensez que vous en avez remarqué dans le code de quelqu'un d'autre. Examinez les possibles mauvaises interprétations entre vous et vos collègues. Prenez notes à chaque fois que quelque chose semble clocher, et vous mettrez bientôt en évidence des façons d'améliorer votre communication.
    Dans le projet que j'ai mentionné ci-dessus, beaucoup d'incompréhensions auraient pu être évitées. Par exemple, appeler la première "liste de bugs" une liste de problèmes aurait attiré l'attention sur le fait que tous les items de la listes étaient là parce que, à un moment donné, un client a rapporté ce problème à l'équipe de développement. Avec cela à l'esprit, je n'aurais pas été surpris d'apprendre que certains problèmes étaient devenus "obsolètes" et qu'il n'y avait plus aucun intérêt à en conserver la trace.
    Si nous avions connus la notion de "module sans défaut" ["defect-prone modules"] (et, en conséquence, si nous nous étions d'accord au préalable sur une définition du mot "défaut"), mes inquiétudes sur la qualité interne du code n'auraient pas été ignorées. Les termes "faute" ["fault"], "échec" ["failure"], "condition d'échec" ["failure condition"] auraient pu être de bon outils pour analyser ce qui se passait concernant les échecs de nos clients. Un modèle moins simpliste de relation entre modification du code - y compris des modifications légitimes - et défauts qui en résultent aurait évité beaucoup de reproches.

Les mots révèlent les cultures
    Mon collègue Phlip, un développeur comme moi, remarque au passage: « Nous savons tous que les bugs sont inhérents à la vie du développement. Notre boulot est d'écrire du code, trouver les bugs qui s'y trouvent, en faire une liste et les ôter un par un ». Cela est bien sûr ironique. Cela ne devient vrai que si nous croyons en "la mort, les impôts et les bugs" ["death, taxes and bugs"]. (On ne peut pas faire grand-chose concernant la mort et les impôts, mais nous savons que les "bugs" sont dans notre sphère de contrôle)
[Voici quelques compléments sur cette "culture" cf. illustrations]
    Toutes les cultures ont leurs zones d'ombres et leurs faiblesses, et les plus sérieuses erreurs résultent de telles zones d'ombres. La seule solution que je connaisse est d'aborder les cultures en elles-mêmes, avec lucidité, comme des conventions faîtes par des hommes et que nous avons le pouvoir de changer. [Cela rejoint l'illustration sur les conventions déjà mentionnées plus haut]. Si l'on remarque qu'une partie de notre culture, comme un terme populaire, nous conduit à des erreurs, nous pouvons prendre des mesures pour effectuer un changement volontaire.
    Réfléchissez comment vous et d'autres dans votre équipe utilisez le mot "bug". Discutez-en. Vous vous épargnerez beaucoup d'ennuis.

• volume 2, p. 237, pour une discussion concernant la terminologie des erreurs et défauts des logiciels;
• volume 4, p. 177, pour un exemple de courbe des compromis.

    La communauté Shape se trouve ici : http://www.geraldmweinberg.com/shape.html.

"Computer bug" cartoon courtesy of C. Ware, copyright 1997