4 réponses

★ Meilleure réponse

Ce qu'on ne voit jamais mentionné, c'est d'utiliser l'onglet Network en parallèle. Souvent tu penses que ton JavaScript est buggé alors qu'en réalité le problème c'est qu'un appel API a échoué silencieusement ou a retourné des données bizarres. Vérifie toujours les réponses du backend avant de creuser dans ton code front-end - ça te sauve des heures.

Pour le reste, l'vrai truc c'est d'apprendre à lire la stack trace. Quand une erreur surgit, ne regarde pas juste où ça dit « erreur ici », mais remonte la chaîne d'appels qui l'a causée. Souvent la vraie source du bug est deux ou trois niveaux plus haut dans la chaîne. Et si tu utilises TypeScript ou un bon linter, tu catches déjà pas mal de problèmes avant même de faire du debugging sérieux.

Combien de console.log() tu ajoutes au code avant de réaliser que Chrome DevTools a déjà tout ce qu'il te faut?

Le vrai changement de perspective, c'est d'arrêter de voir le debugging comme une chasse au trésor désespérée. Chrome DevTools a les Sources, qui te permettent de mettre des vrais breakpoints - pas juste "affiche cette valeur et croise les doigts" - et de parcourir le code ligne par ligne. Ce que les gens n'utilisent pas assez, c'est la fonction watch sur des variables spécifiques, comme ça tu vois en temps réel ce qui change pendant que le code s'exécute. Et puis il y a le console drawer qui reste toujours à portée de main, parfait pour faire des vérifications rapides sans arrêter l'exécution.

Un truc qui m'a sauvé pas mal de fois : utiliser l'onglet Network non seulement pour voir si les requêtes partent, mais pour vérifier exactement ce que tu reçois du serveur. J'ai passé des heures à debugger de la logique qui était en réalité un problème dans les données qui arrivaient. Si l'appli est complexe et a un état interne, Vue DevTools ou React DevTools (selon ce que tu utilises) sont des tueurs - tu vois l'état muter en temps réel et tu peux revenir aux états précédents. C'est pas de la magie, c'est juste que les gens souvent ne savent pas que ça existe.

Ah, et un dernier truc bête mais vrai : mets des breakpoints conditionnels. Tu ne veux pas toujours t'arrêter sur une ligne, tu veux t'arrêter seulement quand une certaine variable a une certaine valeur. Au moins tu te sauves le temps de cliquer sur "continue" mille fois.

Ne gaspille pas ton temps à placer des breakpoints au hasard dans les fonctions ; utilise plutôt les conditions dans Chrome DevTools pour que l'exécution s'arrête seulement quand une variable atteint une valeur spécifique - ça change complètement la manière dont tu débogues les bugs dans les apps complexes. Et quand tu fais face à une erreur qui semble aléatoire, l'onglet Network révèle souvent ce que tu ne vois pas dans le code, comme les conditions de course ou les réponses API mal formées.

Quand tu commences à déboguer, combien de points d'arrêt tu mets avant de te rendre compte que le problème est probablement ailleurs?

Ce qui manque souvent, c'est une approche systématique. Chrome DevTools est super puissant mais beaucoup l'utilisent juste pour console.log et des points d'arrêt classiques. Essaie les points d'arrêt conditionnels: clique droit sur la ligne de code, choisis "Add conditional breakpoint" et tape la condition qui t'intéresse. Par exemple, un point d'arrêt qui se déclenche seulement quand `user.id === undefined` au lieu de t'arrêter à chaque fois. Après, utilise les Logpoints (pareil, mais affichent un message sans stopper l'exécution) quand tu dois tracer des valeurs sans casser le flux.

Un truc que peu de gens connaissent: dans l'onglet Network de DevTools, tu peux filtrer et regarder exactement ce qui va mal avec tes requêtes. Si l'app se comporte bizarrement, souvent le problème c'est qu'une requête n'est pas ce que tu crois ou la réponse est malformée. Utilise aussi l'onglet Performance si tu soupçonnes du lag: enregistre ce qui se passe et vois où ton code ralentit vraiment. Enfin, apprends à utiliser les Watch expressions: dans la section Scope, ajoute les variables qui t'intéressent et regarde-les se mettre à jour en temps réel pendant que tu avances dans le code. Ça te sauve un paquet d'affichages inutiles.

ricci1987 asker Merci pour les conseils ! Je n'utilisais pas les conditional breakpoints et les logpoints, c'est exactement ce que je cherchais. Je vais tout de suite essayer l'onglet Network pour les requêtes.

Votre réponse

Se connecterpour répondre.