Zoom sur : les méthodes de débug !

Par Robin et Maxime, Développeurs Web à l’Agence Dn’D

En développement web, un bug se définit comme la différence entre le comportement attendu et le comportement obtenu. Il ne s’agit pas d’une erreur dans le code à proprement parler mais de son symptôme. Débugger, c’est donc chercher et corriger l’origine d’un bug. Véritable bête noire des développeurs, ces problèmes existent sous une multitude de formes. Qu’il s’agisse du célèbre bug de la Toyota Lexus ES350, du fameux Bug de l’an 2000 ou d’une anomalie quelconque repérée sur un site web, nous avons tous à un moment donné été confronté à un bug.

Étape n°1 : Minute papillon, informez-vous !

Si vous pensiez qu’il fallait attaquer directement par le code, c’est raté. En effet, avant même d’ouvrir votre IDE préféré, l’étape la plus importante est celle où vous devez récolter les informations nécessaires à la résolution du problème. De ce fait, le contexte, les spécificités du projet ou la stack technique utilisée font partie des informations dont vous avez besoin pour préparer au mieux votre recherche.

Pour cela n’hésitez pas à recueillir des informations pertinentes comme les dernières fonctionnalités ajoutées au site, les récents problèmes survenus sur la plateforme, la version de PHP… Plus vous recueillerez d’informations, plus les étapes suivantes seront simples !

De plus, c’est pendant cette étape que vous devez prendre du recul sur le problème que vous rencontrez et vous posez les bonnes questions afin de ne pas vous orientez dans la mauvaise direction. L’élément le plus important dont vous devez prendre conscience est qu’il ne faut pas traiter les symptômes, mais la cause. Prenons l’exemple d’un bateau qui coule ; rien ne sert d’écoper l’eau qui s’accumule dans la coque puisque la solution est de boucher les trous qui la rendent perméable. Ainsi, ces symptômes sont uniquement là pour vous aider à trouver la source du problème !

Étape n°2 : Se conditionner pour reproduire l’erreur

Il faut bien préparer son environnement pour pouvoir reproduire l’erreur. Les informations récoltées lors de la première étape permettent de s’assurer que l’environnement sur lequel vous avez choisi de travailler est capable de reproduire le bug, il doit donc être aussi proche que possible de celui sur lequel l’erreur est survenue. Vous pouvez, si le bug n’a pas trop d’impact business, le reproduire directement sur l’environnement au sein duquel le dysfonctionnement s’est fait connaître.

Si vous décidez de reproduire le bug sur un autre environnement, voici la liste des éléments importants à vérifier :

• Versions de PHP, MySQL, Lib Diverses
• Si l’environnement dispose d’un système de cache : Redis, Varnish..
• Vérifiez s’il y a plusieurs serveurs de Front
• Quelle branche Git est utilisée ?

 
En plus de cet environnement de développement à dupliquer, mettez-vous dans la peau de l’utilisateur qui a remonté le bug. Vous pouvez reprendre le compte utilisateur utilisé pour bénéficier de sa donnée propre, de ses droits, de façon à reproduire plus facilement et de mieux cerner le problème, autant du côté développement que fonctionnel.
Si, toutefois, il vous est impossible de reproduire le bug, appuyez-vous des informations relatives à l’étape n°1 et commencez dès à présent la construction de votre débug !

Étape n°3 : Se mettre dans le bon mood



Débugger nécessite de pouvoir se concentrer. Cela paraît évident, mais c’est bien souvent ce qui fait défaut et ralenti le débug : un manque ou une perte de concentration. Choisir une ambiance sonore adaptée en fonction des personnes, de la musique ou un silence complet permettra d’accentuer la concentration et de limiter les interférences liées à des stimuli extérieurs. Le mot d’ordre : avoir un cerveau disponible !

Toujours dans cette optique, il est également important d’anticiper d’éventuelles interventions extérieures. C’est sans doute le point le plus difficile à régler, car on ne peut pas être à 100% isolé dans sa bulle de développeur toute la journée. Si cela devient trop compliqué dans votre open-space ou votre bureau, isolez-vous ou portez un T-shirt « Ne pas déranger : débug in progress » !

Étape n°4 : La construction de votre débug



Il est temps de mettre la main à la pâte ! Tout d’abord, il faut trouver un “point d’entrée” à votre session de débug. Cela peut être un template en Front, un flux à activer, une action utilisateur à reproduire ou une configuration à effectuer. Lorsque vous avez trouvé cela, vous pouvez commencer à éliminer les pistes une à une. Ici, il est très important de se concentrer sur un seul test à la fois afin d’éviter tous conflits entre les tests. Ainsi, si vous modifiez une fonction, évitez d’en modifier une autre au risque de devoir débugger vos débugs.

Pour ce faire, mettez en place un protocole de débug qui contiendra toutes les étapes à effectuer pour être certain de tester l’ensemble des cas possibles. Ce protocole se rapproche d’une méthode scientifique où vous devez partir d’une ou de plusieurs hypothèses construites avec les étapes précédentes. Listez les étapes, numérotez les si besoin, cela vous permettra de faciliter le suivi et l’avancement de votre débug. Nous vous conseillons de garder une trace écrite des tests effectués afin de ne pas perdre de temps à revenir sur des hypothèses déjà invalidées et ainsi procéder par élimination (d’autant plus que ces notes permettent d’alimenter le compte rendu final de votre débug).
Votre débug doit se construire autour d’une donnée que vous maîtrisez. Pour un flux d’import produit par exemple, il faut connaître la donnée en important un seul produit à la fois, cela limite les temps de traitements inutiles et donc votre temps d’investigation !

Les outils pour vous aider dans votre tâche d’investigation

Rassurez-vous, vous n’êtes pas seul lorsque vous investiguez. De nombreux outils sont utiles et peuvent vous accompagner durant le débug, en vous offrant les données clefs nécessaires à une meilleure compréhension. Ces outils sont vos compagnons de débug à utiliser sans modération. Parmi eux, on peut citer :
 

• La boîte à outils native des navigateurs web. En effet, la plupart des navigateurs fournissent un inspecteur d’élément vraiment puissant. Vous y retrouverez une console JavaScript, un onglet Network permettant de consulter l’ensemble des requêtes ou encore un onglet Application pour administrer la donnée enregistrée comme le cache navigateur ou les cookies.

 

• Un bon IDE (Integrated Development Environment). La puissance des fonctionnalités de votre IDE ne peut pas forcément vous aider à résoudre le problème mais vous facilitera grandement la tâche avec ses points d’arrêt, ses méthodes de recherche de classe, de symbole, de fichiers, etc.

 

• Les outils de bureautique classiques. Ce ne sont pas forcément ceux auxquels l’on pense en premier, mais l’utilité d’outils comme Sublime text, Text edit ou Excel réside dans leur simplicité d’utilisation. Rien de mieux qu’un éditeur textuel ou un tableur pour étudier une donnée ou tout simplement pour s’en servir comme appui.

 

Il y a ensuite des outils qui vous aideront plus ponctuellement en fonction du contexte :

Xdebug : la plupart des développeurs PHP connaissent l’existence de Xdebug mais bien peu l’utilisent réellement, ils préfèrent se laisser tenter par la bonne vieille méthode du var_dump( ). Xdebug est une extension PHP qui permet de débugger, de profiler, d’effectuer du « code coverage » et de surcharger les fonctions natives PHP dans le but d’aider les développeurs. Pour utiliser Xdebug, il est nécessaire de posséder l’extension PHP Xdebug, une extension côté navigateur ainsi qu’un IDE. L’extension pour navigateur de Xdebug se nomme Xdebug Helper et est particulièrement efficace pour les utilisateurs de Google Chrome et de Mozilla Firefox. Plus d’infos sur la documentation officielle de Xdebug : https://xdebug.org/docs/

Quanta : Quanta est une solution visant à améliorer la performance web des E-Commerçants. Conçu par une équipe qui connaît très bien Magento, cette solution de monitoring des ressources a mis en place une analyse poussée des problèmes rencontrés au chargement des pages en détaillant les performances et les points bloquants (Layout, template, fore…) suivis de scénarios paramétrables.

Blackfire : cet outil permet de récolter de nombreuses informations sur les performances d’une application via une extension navigateur ou des lignes de commandes. Grâce à une représentation graphique simple, Blackfire offre une vision du code détaillée et complète du temps d’exécution pour chaque page et pour chaque fonction (soit en terme de mémoire, soit en terme de temps d’exécution), ce qui permet de dégager des perspectives d’optimisation du code intéressantes.

Étape n°5 : Il est temps de tout nettoyer !

Félicitations ! Vous avez décelé votre bug et élaboré une solution pour le résoudre ! Mais comme pour l’étape n°1, rien ne sert de se hâter : en effet, avant d’en finir une bonne fois pour toute, vous devez nettoyer derrière vous ! Ce nettoyage passe par la restitution d’un environnement fonctionnel tel que vous l’avez trouvé à votre arrivée. Vous devez donc :

• Supprimer l’ensemble des dump, log que vous avez disséminé dans le code de l’environnement en ligne ou local
• Supprimer la donnée que vous avez importé ou créée pour votre investigation
• Supprimer les fichiers de logs ou les erreurs que vous avez consciemment générés pour ne pas polluer les serveurs
• Remettre la donnée ou les configurations que vous avez modifié à la normale.

 

Les pires bugs rencontrées par l’Agence Dn’D

Nous avons interrogé nos équipes afin de connaître les pires bugs qu’elles ont rencontré et les méthodes utilisées pour les résoudre, en voici les éléments de réponse !

Côté Développeur

—

Un bug sur les calculs de prix. En réalité, il s’agissait d’un comportement induit par les développeurs de l’ancien intégrateur de notre client qui ne correspondait pas aux attentes.
 

Aucune. J’ai procédé à un débuggage brut via les commandes Mage::log( ) et Zend_Debug::dump( ).
 

En premier lieu, je suis parti du constat du bug, à savoir un affichage faussé du prix en front sur la page “catégorie”. Petit à petit, je suis remonté dans les tuyaux pour trouver à quel endroit le prix affiché était calculé, mais cela ne servait à rien puisque tout au long du débug, le prix retourné était bien celui du produit consulté. Par la suite, je me suis rendu compte qu’il s’agissait d’un comportement custom indépendant du calcul du prix de Magento : le produit configurable était en fait un groupé (les groupés avaient été globalement surchargés pour avoir un comportement de configurable), affichant le prix du produit simple le plus ancien (increment_id le plus bas) qui lui était associé.
Ce bug/comportement m’a fait perdre énormément de temps jusqu’à ce que je comprenne qu’il était inutile de cherche dans le core de Magento.

Côté Chef de Projet

—

Commande impossible sur la plateforme E-Commerce d’un client.
 

Utilisation de la Console chrome. La console Chrome permet un gain de temps par sa simplicité et sa rapidité de changer les éléments, que ce soit dans le HTML ou autre, ce qui est très utile pour débugger et entamer un travail de reproduction.
 

– Demande de scénario exact
– Reproduction impossible dans un premier temps
– Suivi du scénario avec le compte client reproduit à l’identique
– Problème résolu via la console chrome : l’adresse utilisée était trop longue et le message d’erreur ne l’indiquait pas
– Résultat : évolution

Conclusion

Vous l’aurez compris, l’art du débug informatique est un condensé de savoir-être et de savoir-faire. Un développeur doit faire preuve de méthode, de connaissances de ses outils, de patience, sans se lancer avec des idées pré-conçues. L’une des clés du débuggage réside aussi dans la passation des connaissances : les développeurs doivent transmettre leurs expériences sur le sujet pour permettre au plus grand nombre de se sortir d’affaire lors de situations complexes. Le débuggage est une discipline à part entière, maîtrisez-le et rien ne pourra vous arrêter ! 🙂