Débugger son application Web
Est-ce un bug front ou un bug back ?
Même si nous faisons le maximum pour avoir un workflow minimisant les risques de bugs, nous avons tous vécu ce scénario : on développe tranquillement une petite fonctionnalité dans son coin, quand tout à coup Slack s’affole. Des notifications qui clignotent dans tous les sens, des @here partout…
L’origine de tout ce ramdam est simple, la QA vient d’annoncer dans le plus grand des calmes que…
On a un souci en prod. Quelqu’un s’en occupe ?
Le premier réflexe est alors de regarder les dernières mises en production afin de re-déployer la version stable la plus récente. Une fois fait, on respire un peu : les utilisateurs peuvent à nouveau se servir de l’application, mais notre problème est loin d’être réglé… Ce bug, il faut bien le résoudre !
Mais très vite arrive la fameuse question : où se situe le problème ?
Il devient rapidement vital d’éliminer la majorité des sources possibles en se posant une seconde question : est-ce un bug front ou un bug back ?
La réponse ne devrait pas être compliquée à trouver, et pourtant : je ne compte plus les fois où j’ai cherché l’origine d’un bug pour finalement réaliser qu’il est dû à l’API qui ne m’envoie pas le bon format de données…
Et inversement bien entendu, nos amis du back-end ne sont heureusement pas toujours les fautifs !
Trancher rapidement sur l’origine back ou front d’un bug est primordial pour le régler le plus efficacement possible. Alors comment faire ?
Bien entendu, tout dépend du contexte et des technologies utilisées dans le projet. Chez OpenClassrooms, nous avons des pages récentes en React communiquant avec une API OAuth2, mais nous avons également des pages un peu plus vieilles bâties en Twig avec du bon vieux jQuery. Il est évident que le debug ne se fait pas de la même manière dans ces deux cas…
… Vraiment ? Pas si sûr.
Dans cet article, je vais vous partager deux situations très différentes que nous avons vécues à OpenClassrooms, en expliquant comment nous en sommes venus à la conclusion que le bug venait du back-end… ou du front-end (ce qui arrive moins souvent, bien entendu 🙃 ).
Bug n°1 : on affiche deux fois les cours anglais mais pas les cours français !
Contexte : données du back injectées dans une page Twig, puis modifiées via API.
Afin de gérer nos nombreux mentors et étudiants, l’équipe d’OpenClassrooms dispose d’une interface d’administration proposant différents formulaires plus ou moins complexes.
Il est courant pour nos administrateurs de devoir chercher un ou plusieurs cours, nous avons donc créé un composant Autocomplete qui dialogue avec notre API.
Intéressons-nous plus particulièrement à un formulaire qui proposait de chercher séparément les cours français et les cours anglais :
Le problème qu’on a eu est le suivant : quelles que soient les valeurs soumises pour les cours français, au rechargement de la page seules les valeurs anglaises étaient affichées.
Pourtant, les données enregistrées en base étaient correctes, seul leur affichage était incohérent. La conclusion a semblé évidente : le bug venait du front.
Peut-être y-avait-il un conflit lorsque le composant Autocomplete était utilisé plusieurs fois dans la même page ? Après tout, c’était la première fois qu’on faisait face à ce scénario…
Cela dit, les données étaient bien sauvegardées en base de données, ce qui signifiait que l’Autocomplete fonctionnait correctement : il suggérait les bonnes informations et les envoyait bien au serveur. Il n’y avait donc aucun souci au niveau des requêtes vers l’API.
Le problème n’étant qu’à l’affichage, il fallait vérifier ce que recevait le composant via le template Twig.
Et surprise : tous les Autocomplete de la page ne recevaient que des cours anglais. Le composant est un peu simplet, il n’affiche que ce qu’il reçoit sans aucun autre traitement… Le problème venait donc du back finalement !
Il s’agissait d’une sombre histoire de loader Symfony qui était statique et ne se ré-instanciait pas comme il faut (un truc de back quoi, rien à voir avec le front !).
Bug n°2 : on n’affiche pas les couleurs des catégories des cours !
Contexte : données du back reçues via une requête API.
Pour traiter ce deuxième bug, vous devez savoir que nous avons déployé récemment une nouvelle interface pour l’affichage des résultats de recherche de cours. Ce qui nous intéresse particulièrement ici, ce sont les catégories de chaque cours qui apparaissent désormais dans une couleur précise :
Même si c’est de l’affichage, il a été décidé que ces couleurs soient des règles business : c’est donc l’API qui nous envoie l’information.
Mais lors du développement de cette petite fonctionnalité, nous avions ce rendu à la place :
Comme je l’ai indiqué, la couleur est renvoyée par l’API : puisque tout était noir, il a semblé évident que c’était parce que le front ne recevait aucune couleur. Un problème côté back, donc !
J’étais d’autant plus sûr de moi que le composant React affichant un cours prenait en compte l’affichage de cette couleur :
Mais ce composant CourseListItemWithWrapper est un container du composant CourseListItem. Et ce dernier gère un cas spécial lorsque le cours n’est pas encore ouvert :
Ceci était l’origine du problème : si on regarde attentivement le container précédent, on voit certes que la couleur de la catégorie est passée, mais pas la propriété openedAt. La couleur ne s’affiche donc pas, le souci venait bien du front-end…
Conclusion : vérifier les données est la première chose à faire
Même si ces deux bugs avaient des origines différentes, ils ont un point commun. Il aurait été plus rapide de trouver la source du problème en vérifiant directement un seul et même endroit : le retour du back-end.
Dès qu’il y a un problème d’affichage, dès qu’il y a une incohérence sur les données, le premier réflexe à avoir est de vérifier les données que le back-end renvoie.
Et ce avant même d’ajouter le moindre breakpoint dans votre code, avant même d’ouvrir votre IDE !
Si ces données correspondent au contrat défini au préalable, c’est que le bug vient du front-end, dans 100% des cas.
Si par contre elles ne correspondent pas, il faut d’abord régler ce premier souci. Cela va peut-être suffire à corriger le problème, ou cela va peut-être en révéler un autre… côté front cette fois.
