Joel on Software   Joël à propos de logiciel

D'autres articles de "Joel on Software" en Français

D'autres articles de "Joel on Software" en Anglais

Contacter l'auteur (En Anglais uniquement)

Le basic TRS-80 Niveau-I ne pouvait stocker que deux variables, A$ et B$. De même, je suis né avec deux emplacements-de-stockage-pour-bug dans mon cerveau. A un moment donné, je ne peux me souvenir que de deux anomalies. Si vous me demandez d'en mémoriser trois, l'une d'entre elles va tomber sur le sol et sera repoussée sous le lit avec les peluches poussiéreuses, qui vont la manger.

Maintenir une base de données des anomalies est un des signes permettant de reconnaître une bonne équipe de développement. Je ne cesse d'être étonné par le petit nombre d'équipes qui font effectivement ça. L'un des plus graves faits incorrects auxquels les programmeurs semblent toujours croire est qu'ils peuvent se souvenir de tous leurs bugs ou les conserver sur des post-it.

Si je peux mobiliser votre attention un moment, j'aimerais expliquer une méthode plutôt facile de faire un suivi des anomalies, dans l'esprit de mes articles précédents sur les plannings sans effort et les spécifications sans effort.

Premièrement, vous avez besoin d'une vraie base de données. Pour des équipes de deux personnes qui écrivent un petit peu de code au cours d'un long week-end, il est certainement possible d'utiliser un fichier texte comme base de données. Pour quoique ce soit de plus gros, vous allez avoir besoin d'une vraie base de données pour gérer les anomalies. Il existe plusieurs millions d'outils commerciaux de suivi des anomalies. (Auto-promotion non dissimulée : celui que nous avons écrit à Fog Creek Software, appelé FogBUGZ, possède une interface web, est simple d'utilisation, et assez puissant, si je peux me permettre d'en juger.)

Suivons le cycle de vie d'une anomalie à titre d'illustration, depuis sa naissance jusqu'au moment où elle sort de sa misère. Nous allons suivre le fameux bug 1203. Voici ce que la base d'anomalies montre pour ce bug :

Voici ce qui s'est passé.

Mikey le programmeur est en train de bricoler la nouvelle fonctionnalité de client FTP de son super logiciel Macintosh. A un certain moment, parce qu'il n'a pas froid aux yeux, il écrit sa propre fonction de copie de chaîne de caractères. Ca leur fera les pieds avec leur politique pourrie de réutilisation ! Bouah ah ah !

De mauvaises choses arrivent lorsqu'on ne réutilise pas le code, Mikey. Et aujourd'hui, la mauvaise chose qui s'est produite était que Mikey a oublié d'ajouter un zéro à la fin de la chaîne de caractères copiée. Mais il n'a jamais remarqué le problème parce que la plupart du temps il se trouvait qu'il copiait des strings dans des zones de mémoire pré-initialisées à zéro.

Plus tard cette semaine là, Jill la Très Très Bonne Testeuse maltraite le code en roulant son front de gauche à droite sur le clavier ou avec un autre test, d'égale cruauté. (Etrangement, la plupart des bons testeurs s'appellent Jill, ou un dérivé comme Gillian.) Soudain, quelque chose de très étrange se produit : le serveur FTP qu'elle utilisait pour tester a planté. Oui, je sais qu'il s'agit d'une machine Linux et je sais que les machines Linux ne plantent jamais (pas de grognements de la foule de Slashdot, svp), mais cette sacrée chose a planté. Et elle n'était même pas en train de toucher le serveur, elle transférait simplement des fichiers par FTP en utilisant le code Mac de Mikey.

Attention, Jill est une très très bonne testeuse, donc elle a soigneusement gardé une trace de ce qu'elle était en train de faire (l'inclinaison et le positionnement exact de sa tête lorsqu'elle l'a roulée sur le clavier sont notés dans son cahier de laboratoire, par exemple). Elle reboote tout, démarre avec une machine propre, répète les étapes et - - enfer et damnation - - cela se produit à nouveau ! Le serveur FTP Linux a encore planté ! Ca fait maintenant deux fois dans la même journée ! Prend ça, Linus.

Jill examine la liste des étapes à reproduire. Il y a à peu près vingt étapes, certaines d'entre elles ne semblent pas liées au problème. Après quelques expérimentations, Jill est capable de réduire le problème à quatre étapes qui provoquent toujours le même comportement. Maintenant elle est prête pour enregistrer une anomalie.

Jill entre le nouveau bug dans la base de suivi des anomalies. Attention, le simple fait de saisir une anomalie demande de la discipline : il y a des bonnes signalisations d'anomalie et des mauvaises signalisations d'anomalie.

Trois parties pour tout bon signalement d'anomalie

Et le seigneur a prononcé ces mots : "D'abord vous devrez prendre la Sainte Goupille. Ensuite vous devrez compter jusqu'à trois, ni plus, ni moins. Trois devra être le nombre jusqu'auquel vous devrez compter, et le nombre du comptage devra être trois. Jusqu'à quatre vous ne devrez pas compter, ni ne devrez compter jusqu'à 2, sauf si vous continuez ensuite jusqu'à 3. Cinq est complètement hors de propos. Une fois que le nombre 3, étant le troisième nombre, sera atteint, alors vous jetterez la Sainte Grenade à Main d'Antioche sur votre ennemi, qui, étant désagréable à ma vue, devra se la respirer."

-- Monty Python, Sacré Graal

Il est assez facile de retenir la règle pour une bonne signalisation d'anomalie. Toute bonne signalisation d'anomalie nécessite exactement trois sections.

Ça semble facile, non ? Peut-être pas. En tant que programmeur, des gens m'assignent régulièrement des bugs dans lesquels ils ont oublié une partie ou une autre.

Si vous ne me dites pas comment reproduire le bug, je n'aurai probablement aucune idée de ce dont vous parlez. "Le programme a planté et a laissé un objet malodorant sur mon bureau." C'est chouette, mon chéri. Je ne peux rien faire tant que tu ne me dis pas que ce que tu étais en train de faire. Certes, j'admets qu'il y a un ou deux cas pour lesquels il est difficile de trouver les étapes exactes pour produire. Parfois, vous avez simplement oublié, ou vous ne faites que transcrire une anomalie depuis "le terrain". (Au fait, pourquoi l'appelle-t-on "le terrain" ? Est-ce que ça ressemble à un terrain de tennis ou quelque chose dans le genre ? Enfin...) Un autre cas où il est normal de ne pas avoir d'étapes pour reproduire le bug est celui où une anomalie se produit de temps en temps mais pas toujours, mais vous devriez quant même fournir les étapes pour reproduire, avec une petite annotation qui dit que ça ne se produit pas si souvent. Dans ces circonstances, il va être difficile de trouver le bug, mais on peut essayer.

Si vous ne spécifiez pas ce que vous attendiez à voir, je risque de ne pas comprendre pourquoi il s'agit d'une anomalie. L'écran d'accueil est maculé de sang. Et alors ? Je me suis coupé les doigts pendant que je codais. Tu espérais quoi ? Ah, tu dis que la spec n'exigeait pas de sang ! Maintenant je comprends pourquoi tu considères ça comme une anomalie.

Partie trois. Ce que vous avez vu à la place. Si tu ne me dis pas cela, je ne sais pas en quoi consiste le bug. Celle-là est à peu près évidente.

Retour à notre histoire

Jill saisit l'anomalie. Dans un bon système de suivi des anomalies, elle est automatiquement assignée au chef développeur du projet. Et c'est là que réside le second concept : chaque bug doit être assigné à exactement une personne tout au long de sa vie, jusqu'à ce qu'il soit clos. Un bug est comme une pommes de terre chaude : lorsqu'il vous est assigné, vous êtes responsable de le résoudre, d'une manière ou d'une autre, ou de l'assigner à quelqu'un d'autre.

Willy, le chef développeur, examine l'anomalie, décide qu'elle concerne probablement le serveur FTP, et la résout par "ne sera pas corrigée". Après tout, ils n'ont pas écrit le serveur FTP.

Lorsqu'un bug est résolu, il est réassigné à la personne qui l'a ouvert. C'est un point crucial. Il ne disparaît pas simplement parce qu'un programmeur pense qu'il le devrait. La règle d'or est que seule la personne qui a ouvert le bug peut le fermer. Le programmeur peut résoudre le bug en pensant, "ah, je pense que c'est fait." Mais pour effectivement clore le bug et le sortir des livres, la personne qui l'a ouvert à l'origine doit confirmer qu'il a bien été corrigé ou être d'accord sur le fait qu'il ne devrait pas être corrigé pour une raison quelconque.

Jill reçoit un email lui indiquant que son anomalie est revenue dans sa cour. Elle l'examine et lit les commentaires de Willy le chef développeur. Quelque chose ne tourne pas rond. Les gens utilisent ce serveur FTP depuis des années et il ne plante pas. Il plante seulement quand on utilise le code de Mikey. Alors Jill réactive le bug, en expliquant son point de vue, et le bug retourne chez Willy. Cette fois, Willy affecte le bug à Mikey pour correction.

Mikey étudie l'anomalie, réfléchit longtemps et intensément, et en fait un diagnostic complètement erroné. Il corrige une anomalie totalement différente, puis résout celle que Jill avait ouverte.

L'anomalie revient chez Jill, marquée "résolu-corrigé" cette fois. Jill teste ses étapes pour reproduire avec la dernière version, et, enfer et damnation, le serveur Linux plante. Elle réactive à nouveau l'anomalie et l'affecte directement à Mikey.

Mikey est perplexe mais il localise finalement la source du bug. (Tu vois de quoi il s'agit maintenant ? Je le laisse en exercice au lecteur. J'ai donné suffisamment d'indices!) Il le corrige, le teste, et - - Eurêka ! Le scénario de reproduction ne plante plus le serveur FTP. Une fois de plus, il résout le bug comme corrigé. Jill essaie également les étapes pour reproduire, découvre que le bug est bon et corrigé, et le clôt.

Les dix meilleures astuces pour le suivi des anomalies

1. Un bon testeur essaiera toujours de réduire au minimum le nombre d'étapes pour reproduire l'anomalie : cela aide grandement le programmeur qui doit trouver le bug.
2. Souvenez-vous que la seule personne qui peut clore l'anomalie est la personne qui l'a initialement ouverte. Tout le monde peut la résoudre, mais seule la personne qui a détecté le bug peut être vraiment sûre que ce qu'elle a vu est corrigé.
3. Il y a de nombreuses manières de résoudre une anomalie. FogBUGZ vous permet de résoudre un bug comme corrigé, ne sera pas corrigé, en attente, non reproduit, doublon, ou par conception.
4. Non reproduit signifie que personne n'a jamais réussi à reproduire l'anomalie. Les programmeurs utilisent souvent cela lorsqu'il manque des étapes pour reproduire la signalisation de l'anomalie.
5. Vous prendrez soin de garder trace des versions. Chaque version de logiciel que vous donnez au testeur devrait avoir un numéro identifiant unique de sorte que le pauvre testeur n'ait pas à tester une anomalie sur une version du logiciel dans laquelle il n'était même pas censé être corrigé.
6. Si vous êtes un programmeur, et si vous avez du mal à amener les testeurs se servir de la base de suivi des anomalies, n'acceptez pas de signalisation d'anomalie par une quelconque autre méthode. Si vos testeurs sont habitués à vous envoyer des emails avec des signalisations d'anomalie, renvoyez-les simplement avec un bref message : "Saisissez cette anomalie dans la base de données SVP. Je ne peux pas garder trace des emails."
7. Si vous êtes un testeur, et si vous avez du mal à amener les programmeurs à utiliser la base de données des anomalies, ne leur parlez pas des anomalies - saisissez-les directement dans la base et laissez la base leur envoyer un mail.
8. Si vous êtes programmeur, et que seuls quelques-uns de vos collègues utilisent la base de suivi des anomalies, commencez simplement par leur affecter des bugs dans la base. Finalement, il vont comprendre le truc.
9. Si vous êtes un manager, et si personne ne semble utiliser la coûteuse base de suivi des anomalies que vous avez installée, commencez par affecter de nouvelles fonctionnalités aux gens en utilisant des anomalies. Une base de suivi des anomalies est aussi un excellent outil pour stocker les "fonctionnalités non implémentées".
10. Résistez à la tentation d'affecter de nouveaux champs à la base de suivi des anomalies. Presque chaque mois, quelqu'un va arriver avec une très bonne idée pour un nouveau champ à ajouter dans la base. Vous avez toutes sortes d'idées intelligentes, par exemple garder trace du fichier dans lequel le bug a été trouvé, garder trace du pourcentage du temps où le bug est reproductible, garder trace du nombre de fois où le bug s'est produit, garder trace des versions exactes des DLLs installées sur la machine ou le bug est apparu. Il est très important de ne pas suivre ces idées. Si vous le faites, votre nouvel écran de saisie d'anomalies finira avec un bon millier de champs, et personne ne voudra plus saisir de signalisations d'anomalies. Pour que la base de suivi fonctionne, tout le monde doit l'utiliser, et si saisir des anomalies "formellement" représente trop de travail, les gens vont contourner la base.

Si vous développez du code, même dans une équipe d'une personne, sans une base de données organisée listant tous les bugs connus dans le code, vous allez inévitablement livrer du code de piètre qualité. Pour les bonnes équipes de développement, non seulement la base de suivi des anomalies est utilisée par tout le monde, mais les gens prennent l'habitude de l'utiliser pour leur propre liste d'actions "à faire", il font pointer la page d'accueil de leur browser sur la liste des anomalies qui leur sont affectées, et ils commencent à rêver de pouvoir affecter des anomalies au responsable du bureau pour engranger plus de Mountain Dew.