[Formation NOOB] Débugger sans peine !
Vous êtes chef de projet web junior ? Votre client fait face à un bug ?
Cette vidéo est faite pour vous : vous comprendrez la logique et les démarches à suivre pour débugger facilement votre application !
COMPRENDRE VOTRE CLIENT
Appel paniqué de votre client : plus rien ne fonctionne, plus rien ne va… panique générale !
Avant toute chose, il est essentiel de bien comprendre le message de votre client pour identifier correctement le problème à résoudre : vous devez écouter et reformuler le message de votre client.
Aussi, et bien que cela soit délicat, n’hésitez pas à le faire patienter… Vous devez bien identifier la nature du problème avant de vous lancer dans une correction hasardeuse.
METTRE EN PLACE UN OUTIL DE SUIVI DE BUG
Vous l’aurez compris, à ce stade, la communication avec votre client est essentielle. Pour ce faire, vous devez absolument utiliser un outil de suivi de bug, comme par exemple Mantis, Redmine ou Jira.
Quel qu’il soit, ce type d’outil est indispensable pour faciliter les échanges avec votre client, et ainsi permet d’améliorer la compréhension des problèmes à résoudre. Vous allez devoir poser de nombreuses questions sur les éléments à corriger : en découpant vos bugs en tâches, vous vous assurez de ne pas perdre le fil des actions à mener.
Il est capital d’instaurer ce type de procédure avec votre client et vous devez insister auprès de lui pour la mettre en place.
REPRODUIRE LE BUG EN LOCAL
Si vous avez le moindre doute sur le bug, ne commencez rien car vous risquez de passer à côté ! En effet, vous ne parviendrez pas à reproduire les anomalies si vous manquez d’informations, et ce malgré les efforts que vous fournirez.
Vous perdrez du temps et vous créerez une frustration tant du côté du client – qui va penser que vous n’avancez pas suffisamment vite – que du vôtre, car vous tenterez de reproduire en vain, un bug qui n’apparaît pas dans votre environnement.
Cette phase est donc elle aussi très importante : si vous ne reproduisez pas exactement le bug en local, vous allez passer à côté du bug ! Vous en corrigerez peut-être un autre, mais pas celui de votre client…
Le prérequis pour cette étape est d’être le plus proche de l’environnement sur lequel l’anomalie a été déclarée :
- L’utilisation de la même branche git, ou une copie à jour
- L’export/import de bases de données
- L’ajout de fichiers ou d’images
Pensez à tout ce qu’il y a autour de votre projet, ce que vous avez construit mais aussi à toutes les possibilités de manipulation de votre client…
DU BUG À LA RÉSOLUTION, TOUTES LES ÉTAPES
La première chose à faire si vous faites face à un bug, c’est évidemment de consulter la console de votre navigateur. Lisez bien toutes les lignes de votre message d’erreur : si l’information n’est pas dans la première ligne, les suivantes vous diront probablement où se situe le problème !
Le message d’erreur ne vous dit rien ? Essayez de mettre un point d’arrêt dans votre navigateur, et essayer de débugger pas à pas.
Si vous ne trouvez toujours pas l’erreur, rendez-vous directement dans l’onglet Network : vous aurez une liste d’appels, en « Get » ou en « Post » qui vous permettra de rejouer facilement le test (évitez d’effacer votre cache à ce moment-là, sinon vous devrez recommencer tous vos appels).
Toujours pas de message clair ? Lisez les Logs PHP ! La plupart du temps vous aurez une trace complète – votre log d’erreurs – qui vous permettra d’identifier d’où vient le bug, vous pouvez ensuite identifier la fonction PHP et y accéder dans votre IDE.
Vous n’avez toujours pas de solution ? Ajoutez un point d’arrêt. À cet instant, XDebug vous aidera fortement car il vous permet d’aller lire l’état des variables quand vous faites votre appel.
Ce schéma vous paraît complexe ? Allez voir notre explication sur Youtube
BUG EN PROD, COMMENT LE TRAITER ?
Vous n’avez pas réussi à corriger le bug en local ? Testez ensuite sur le poste d’un de vos collaborateurs : mac, pc, navigateurs, versions différentes… Si le bug est reproduit, identifiez les différences qui vont vous permettre de le corriger.
Si vous n’arrivez toujours pas à traiter le bug, essayez de le faire sur un autre environnement de votre client (Dev, recette, préprod…).Attention, cela nécessite un certain nombre de manipulations qui peuvent impacter la solution de votre client.
Lisez les logs, vous aurez déjà 50 % de vos réponses ! S’ils ne donnent rien, vous pouvez en ajouter. 
Encore sans réponse ? Reproduisez le problème en production, toujours avec l’accord de votre client, en faisant un dump de la base de données à un moment où l’activité est faible pour pouvoir faire les corrections. Une fois que tout est corrigé, n’oubliez pas d’annuler vos modifications.
ALLEZ PLUS LOIN AVEC XDEBUG
XDebug permet de faire un point d’arrêt sur votre projet, d’arrêter votre programme, d’éditer et voir vos variables au cours de l’exécution de vos tests.
L’installation dans un environnement LAMP est assez facile et consiste à voir s’il est actif dans le PHP info, et l’activer si nécessaire, sans oublier de l’ajouter dans votre IDE.
Sous Docker, notez que c’est XDebug qui va chercher votre IDE. Par exemple, PHP Storm autorise une machine à se connecter et ouvre un port sur lequel vous lui demandez de se connecter. Votre Docker ira se connecter sur le port ouvert par PHP Storm, et non l’inverse !
En pratique, près de 60 % des bugs sont des erreurs courantes, et donc faciles à corriger :
- Quelle que soit l’application, pensez à purger vos caches: templates, anciennes versions…
- Vérifiez la mise à jour de vos fichiers, et pas seulement le Git pull: branches git, Composer Install, build d’application Angular…
- Vérifiez le jeu de données
- Vérifiez que vous avez instancié vos classes
D’autres corrections peuvent être bien plus complexes que prévues…
N’oubliez pas de communiquer avec votre client à chaque action et chaque étape clé pour qu’il comprenne que vous êtes actifs !
