Le Bon et le mauvais Bug

Intro

Le mot Bug est souvent mal pris par les développeurs car certains le ressentent comme une attaque sur la qualité de leur travail. Pourtant un humain ne peut pas penser à tous les cas d’utilisation et la diplomatie et le dialogue sont alors nécessaires pour que les deux parties soient heureuses à la fin 🙂

La Petite Histoire

Le Bug provient du mot anglais « Bug » : la petite bête qu’on ne veut pas avoir chez soi. Il y souvent une sur utilisation de ce mot et aussi des mauvaises utilisations. Par moment, le mot est utilisé pour des changements que l’on veut avoir dans son application, il peut être utilisé aussi quand l’ensemble ne fonctionne pas alors que l’on serait plus sur un problème d’infrastructure. L’utilisation du mot Bug est souvent faite sur un large domaine alors que c’est un terme qui devrait être très ciblé et précis en terme de contexte.

Création du Bug : Un seul Objectif !

Le seul objectif d’un bug est qu’il soit corrigé à la fin 🙂

Pour faciliter le travail du développeur, le plus important est que le Bug soit facile à reproduire grâce à la description fournie dans la fiche de Bug.

En général le Bug contient les données suivantes :

  • Titre : La description du Problème
  • Les étapes pour reproduire
  • Le résultat Observé
  • Le résultat attendu

Titre : Description du Problème

Le titre permet de comprendre en une ligne ce qui ne va pas. Il doit être concis et clair pour toutes les personnes amenées à lire le titre de bug.

Quelques Exemples :

Enregistrement impossible des paramètres utilisateurs

Affichage incorrect des planètes sur l’écran Espace Personnel -> Simulation

Etapes pour reproduire

Les différentes étapes doivent être indiquées pour reproduire le problème. Une vidéo sous forme de gif peut être aussi utilisée.

Exemple :

Si le problème n’est pas reproductible à chaque essai, il faudra le préciser : 1/10, 1/5 etc

Une fois les étapes écrites, il ne faut pas hésiter à vérifier que le problème est bien reproduit avec ce que l’on a écrit dans le Bug.

Il s’agit de la partie la plus importante pour le développeur. Si les étapes sont claires et précises, le développeur passera moins de 5min à reproduire. Sachant que le temps passé pour reproduire un problème représente environ 75% du travail de correction : on peut presque dire que le dicton suivant :

« Bug reproduit : Bug Corrigé ! »

Le résultat observé

Décrivez ici ce qui vous semble incorrect. Tout simplement 🙂

Le résultat attendu

Indiquez dans cette section le résultat que vous attendez. Si vous avez un doute, n’hésitez pas à proposer des idées.

Résultat

Si le développeur corrige le problème directement sans votre aide : c’est gagné !! Vous n’aurez qu’à attendre la prochaine publication pour voir le correctif 😉

Par contre s’il n’arrive pas à le corriger ou s’il manque d’information, il vous laissera un message sur le bug. Faites donc attention à vos mails et à vos notifications GitHub ou autres.

Ensemble vous arriverez à trouver la correction sans aucun doute et à faire profiter à toute la communauté le correctif qui probablement gênait plus de personnes qu’on ne le pense 🙂

Conclusion

Un Bug est parfois difficile à identifier que ce soit du côté de celui qui le signale ou du côté du développeur : il est donc important de travailler ensemble pour réussir à décider de l’avenir du Bug. Parfois il pourra être corrigé immédiatement, il pourra aussi être planifié pour une prochaine version ou bien complétement abandonné car il concernera une partie de code qui sera bientôt supprimée.

Dans tous les cas la fiche de Bug ou le ticket aide le produit à devenir meilleur. Car même si aucune action directe n’est requise il amène la réflexion de ce qu’il faudrait améliorer et dans l’innovation toutes les idées sont à prendre 🙂

Utilisez NPM et Gulp pour éviter les CDN

L’idée est ici de garder votre application complètement indépendante, et d’éviter mes CDN sur votre page Web.

Nous allons utiliser le couple npm gulp pour ne prendre dans notre package que le nécessaire.

Présentations

NPM est le gestionnaire de package le plus connu de nodeJS

Gulp est une librairie très utilisée pour personaliser le déploiement et parfois préparer le package de livraison.

Création du Projet

Nous allons utiliser dans notre application les librairies JQuery et Loglevel. Pour ne pas les utiliser nous allons les récupérer avec NPM

Préparez un fichier package.json à la racine du projet comme suit : (Nous allons expliquer les scripts embarqués juste après)

{
  "name": "mon-extension",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "node-clean": "npm prune && npm install",
    "build": "gulp build",
    "test": "echo 'no test'"
  },
  "keywords": [],
  "author": "DarkNoon",
  "license": "GPL-2.0",
  "devDependencies": {
    "gulp": "^4.0.2"
  },
  "dependencies": {
    "jquery": "^3.5.1",
    "loglevel": "^1.6.8"
  }
}

Puis lancez npm install pour installer les packages dans le dossier node_modules.

npm install

Vous obtenez :

Gulp est mon ami

Nous allons créer une simple tâche de copie de fichiers avec Gulp. Nous faisons ça pour éviter de déployer le dossier node_moules qui est souvent bien trop rempli de dépendances que l’on n’utilise pas.

Voici le script :

const {  src, dest } = require('gulp');

function update_jquery() {
    return src(["node_modules/jquery/dist/jquery.min.js"]).pipe(dest("contribs"));
}

function update_loglevel() {
    return src(["node_modules/loglevel/dist/loglevel.min.js"]).pipe(dest("contribs"));
}

function build(cb) {
    update_jquery();
    update_loglevel();
    cb();
}
exports.build = build;

Le script va simplement copier les fichers nécessaires dans notre dossier contribs aveec la command build.

Ce qui nous permettra par la suite de produire un package sans Node Modules et de rester léger 🙂

J’espère que ce petit tutoriel vous a plu : vous pourrez le trouvez sur GitHub à cet endroit : Github