Imagine que je suis en train de travailler dans un café avec mes écouteurs. Avec potentiellement du punk dans les oreilles ou la trame musicale du jeu d’Eve Online en version orchestre symphonique d’Islande.
À côté de mon ordi, j’ai un petit canard qui tient une pancarte inscrite : conseils dev en échange d’un café.
Coup de théâtre : tu as un bogue avec ton site web. Tu ne sais pas pourquoi, mais il y a une erreur 503 sur ton navigateur. Quelle coïncidence.
Quelles sont les chances ?!
Dans ce monde hypothétique, si tu m’abordes avec seulement l’information : “Mon site web ne fonctionne pas”.
J’aurais 10 questions, beaucoup de charges mentales et de la réticence à t’aider. J’aurais l’impression que ça prendra beaucoup de temps trouver le problème.
Aborder un développeur avec une question
Comment tu sais, la technologie fait seulement ce qu’on lui dit de faire. Sans rancune, mais il faut d’abord reconnaître que c’est généralement de notre faute.
Sans autoflagellation. Il faut vérifier une deuxième fois si on a bien appliqué ce qu’on sait.
Ce que je veux dire, c’est que tout ce qui fonctionne grâce à des processeurs exécute ta commande.
C’est anxiogène, je sais. On contrôle pas souvent quel chemin on traverse lorsqu’on clique sur un bouton. Entre ta clique et le résultat escompté, c’est souvent une boîte noire si on ne connaît pas le système. C’est un espace mixe entre l’expérience utilisateur et l’expérience développeur.
Chaque élément pourrait être un indice.
Donc il faut être attentifs sur toutes les rétroactions que l’interface nous communique. Par exemple : un loading infini, un code d’erreur, une redirection vers une page blanche, etc.
Qu’est-ce qui détermine que c’est un bon indice ?
Chaque élément qui sert à reproduire le problème. Chaque manipulation vérifiable et qui mène toujours au problème. Il faut le noter.
Souvent on remarque des indices, mais on n’est pas certain s’ils font partie des problèmes collatéraux ou de notre problème principal. Note-les quand même. On élaguera ensuite.
Garde les exemples avec ton point de vue
- Qu’est-ce que je tente d’accomplir (observable désiré),
- Par où j’ai commencé pour tenter de l’accomplir (porte d’entrée pour reproduire le problème).
- Quelle(s) étape(s) je me souviens que j’ai fait avant ou pendant qui aurait pu résulter par ce problème
Par exemple :
J’essaye de mettre à jour mon site web, mais je reçois une erreur 500 lorsque je clique sur mettre à jour, j’observe X, Y et Z.
Les éléments observables c’est le nerf de la guerre
Il faut être en mesure d’identifier ce qui ne fonctionne pas. Quels éléments précis ne devraient pas être là.
Il faut noter tout ce que tu peux. Chaque geste et rétroaction comptent.
Si je reviens avec mon exemple :
- On peut décrire les observables avec ces points :
- J’ai cliqué gérer la version php, dans la section de gestion de php-fpm dans l’interface de gestion de mon serveur (CPN).
- Ensuite, j’ai mis à jour vers php 8.1.
- Tout fonctionne comme avant.
- Ensuite j’ai cliqué sur le lien inscrit mettre mes plugins Wordpress
- et c’est après 10 sec que mon navigateur dans l’url de mise à jour des plugins que mon chrome m’affiche une erreur 503.
Si je tente de schématiser tout ça
Je présenterais ça avec ces 3 points :
Objectif (Je veux mettre à jour mes plugins wordpress),
Observations (le navigateur load, erreur 503) et
Actions (je clique sur le bouton tout mettre ajour),
Dans le meilleur des mondes
Tous ces détails en amont de ta question, c’est un absolu. Avec quelques informations, on est mesure de voir les solutions et les sources potentielles rapidement.
Et si en plus de présenter tout ça, tu présentes des manipulations que tu as faites pour essayer de résoudre le problème, c’est pratique x1000.
On évite d’explorer des hypothèses déjà testées
Toujours dans le même exemple, tu pourrais ajouter tes hypothèses en amont. Après tes objectifs, observations et actions. Grâce à elles, on pourrait passer directement à les tester ou à émettre d’autres hypothèses.
C’est juste une machine
Je crois que c’est souvent l’objectif qu’on oublie de présenter dans ces cas-là. On est fâché parce que ça ne fonctionne pas. Le trio Objectifs, Observations et Actions aide beaucoup à avoir un portrait de la situation.
Je t’ai préparé un mini aide mémoire de tout ce que je t’ai parlé ici. Ensuite tu vas être en mesure de créer des issues sur github pour ton projet open source préféré.
Et n’oublie pas : Don’t be dick. C’est une machine, on lui dit quoi faire. Shame pas le projet ni un autre développeur. Essayons seulement de reproduire le bogue et de trouver la meilleure correction.
Comme toujours tu peux me répondre ici et me partager ton point de vue, et me dire je suis trop abstrait avec mon algèbre de situation.
Aide mémoire
Mini document pour se rappeler des 3 points.
Template pour github
Afin que tes utilisateurs commences du bon pied avec ton projet.
Le mois en rafale
Mes découvertes
This is a teenager
Visionnement de donnée conçu par pudding sur l’adolescence.
Lichess
J’adore les échecs. Je joue au moins 2 partie par jour. Principalement avec chess.com, mais j’ai un ami qui m’a partagé cette plateforme.
Carte d’origine des aliments
Carte d’origine des aliments, parce qu’on est chanceux de manger des banane à l’année.
Nouvel article de Josée Plamondon
Redéfinir la découvrabilité pour une pensée stratégique
Nouvelle
Women who code n’est plus
Women Who Code started as a community group in 2011 by a small team of engineers in San Francisco who were seeking connection and support for navigating the tech industry. The movement grew, city by city, fueled by passionate volunteers that were inspired by the mission and vision. In 2013, Women Who Code, Inc., was registered as a 501(c)3 non-profit organization in California and moved its headquarters to Atlanta, Georgia in 2018.
Mon outil
Je présente un outils du mois, soit en mode testé et approuvé, soit en test ou soit en découverte.
Usersnap
C’est un logiciel comme service qui permet de faire des rapports de bug avec une impression écran, des commentaires et dessins. Super pratique en phase de développement.
C’est un outil payant. Ceci n’est pas un lien d’affilié.