Antoine.Guiral.Info

Tout développeur qui se respecte a été au moins une fois confronté à un bug. Bon ok, peut être plus d’une fois Et il y a plusieurs façon de réagir, suivant l’importance du ug, les délais, la charge, etc etc…

Disclaimer

Histoire que l’on parle bien de la même chose. Ce que j’appellerai bug est bien un bug. C’est à dire que ce n’est pas une incompréhension entre MOA et MOE, ni un must have, ni un nice to have, ni une demande d’amélioration. Un bug est un dysfonctionnement, ou une anomalie directement liée au code en place.

Un bug (de l’anglais bug, « insecte ») ou bogue est, en informatique, un défaut de logique dans un programme informatique qui provoque un calcul ou un traitement incorrect à l’origine de dysfonctionnements et de pannes.

La gravité du dysfonctionnement peut aller de bénigne (défauts d’affichage mineurs) à majeure (explosion du vol 501 de la fusée Ariane 5). On ne qualifie de bug qu’un problème confirmé du logiciel lui-même, le fait technique ou anomalie logicielle désignant plus largement tout comportement inattendu, soupçonné d’être une déficience.

Les bugs résultent d’erreurs de programmation. L’erreur peut résider dans un logiciel applicatif, dans les logiciels tiers utilisés par ce logiciel applicatif, voire dans le micrologiciel d’un composant matériel comme ce fut le cas du bug de la division du Pentium. Un patch (francisé enrustine) est un morceau de logiciel destiné à corriger un ou plusieurs bugs.

Le terme bug est un terme familier et usuel. Dans le monde professionnel, avec des variantes selon la culture de l’entreprise, on préfère utiliser des termes comme fait technique, défaut (software defect), non-conformité, etc. http://fr.wikipedia.org/wiki/Bug_informatique

Quelle importance accorder à un bug?

En fonction de l’état d’avancement du projet et suivant les méthodes de développement (waterfall, V, agile, etc) on est régulièrement confronté à des remontés de bugs. soit pendant la période de recette, soit les bugs relevés par l’équipe de testeur sur le sprint précédent, voir encore si l’application ou le site est en production, une remonté de bug par un utilisateur ou un client.

Ces flux de bugs sont assez perturbants puisqu’on ne sait pas quand est ce qu’ils vont arriver! Et le plus souvent on est en train de travailler sur autre chose…La première chose à ne pas faire est de vouloir le traiter immédiatement. Il faut au moins finir la tache sur laquelle nous étions en train de travailler. Imaginez le temps nécessaire au double switch tache -> bug, bug -> tache…

Une fois que la tâche en cours a été fini, on peut enfin se plonger à fond dans ce putain de bug :p Et la première chose à faire est d’évaluer le temps qu’il vous faudra pour le fixer.  Si vous jugez que c’est un bug majeur il vaut mieux ne pas le résoudre dans l’immediat et le planifier. Peut être qu’en terme de priorité il passera devant tout le reste mais la question mérite d’être posée. Ensuite, le bug peut être long à corriger. Un bug important mais long, ca arrive…Là aussi, on va le planifier. Autrement dit, seuls les bugs dont le temps de corrections est relativement court (disons de l’ordre de l’heure) devraient être fixés immédiatement.

Pour gagner un peu plus en productivité et ne pas en oublier je vous conseille de vous réunir avec votre équipe pour définir un process (bouh c’est maaal) pour la gestion des bugs. Où sont -ils collectés, utilise t-on un outils de bug tracking pour suivre l’état des bugs, une personne est elle chargé de les collecter, bref autant de questions qu’il vaut mieux se poser avant pour ne pas qu’elle viennent vous polluer l’esprit au moment où les bugs surgiront…

Un jour mon père m’a dit : « la NASA envoi ses navettes dans l’espace avec un dictionnaire de correctifs de bugs (comment réagir face à tel ou tel bug), et quand on connait le prix du kilo envoyé dans l’espace… ». A méditer.

Comment traiter le bug?

Maintenant qu’on sait quoi faire face à ce bug (à traiter immédiatement, ou plannifier), les ennuis commencent! Là aussi on peut être confronté à plusieurs ca…ou plutôt devrais je dire plusieurs « cas de conscience ». Parce qu’on est bien d’accord, dans l’idéal, ou l’absolu, un bug : ca se fix! Mais parfois, suivant le projet, le client, les coûts de corrections , les délais, on peut être amener à emprunter un autre chemin…Au lieu de fixer ce vilain truc, on va le cacher. Plutôt que d’apporter des modifications importantes au code, on va faire en sorte que ce bug ne soit pas produisible. Un auto haking en règle.

Je n’ai pas de réponse universelle à ce sujet. Mais personnellement je ferais dans presque 100% des cas l’effort de corriger le bug. Même si je dois tout casser. Une seule raison :

• cacher plutôt que fixer obligera à construire le reste sur une partie de code bancale (la fameuse dette technique). On pourrait comparer ces zones d’ombres du code aux actifs pourri que les états rachètent aux banques : un jour ca vous pète à la gueule.  On ne sait pas quand, ni même si ca arrivera. Mais le jour où cela arrivera, vous pouvez être sur d’une chose : cela coutera beaucoup, beaucoup plus cher de réparer les dégats que si le bug avait été fixé sur le moment…

Mais ça c’est uniquement mon avis Il arrive parfois qu’après discutions, j’ai fais le choix de cacher le bug (pas souvent cependant ). En effet, un délai hyper serré à tenir (une mise en prod’, typiquement) et le choix de coeur passe à l’as (ohoh joli). Après la release il sera temps de le fixer correctement (ou pas…toujours plus vite, plus vite…).

En fait, au fond je pense que la réponse à cette question est étroitement liée à d’autre pratique (agile?) telle que le courage (ne pas hésiter à casser du code) et le refactoring permanent. Bref j’ai un peu du mal à trouver des arguments pour le « cachage » de bug hormis celui des délais…

Je suis donc tout ouïe pour connaitre vos avis sur la question!