Petit conseil : cet article contient de nombreuses animations de démonstration GIF. Sur mobile, veuillez essayer de lire dans un environnement Wi-Fi.

Avant-propos : Les compétences de débogage sont une compétence indispensable dans toute recherche et développement technologique. Maîtriser diverses techniques de débogage permet forcément d'obtenir le double de résultat avec la moitié de l'effort. Par exemple, localiser rapidement les problèmes, réduire la probabilité de défaillance, aider à analyser les erreurs logiques, et ainsi de suite. Aujourd'hui, alors que le développement front-end sur Internet devient de plus en plus important, la manière de réduire les coûts de développement et d'améliorer l'efficacité du travail dans le développement front-end rend la maîtrise des compétences de débogage en développement front-end particulièrement importante.

Cet article expliquera une par une diverses techniques de débogage JS front-end. Peut-être les maîtrisez-vous déjà, alors révisons-les ensemble. Peut-être existe-t-il des méthodes que vous n'avez jamais vues, alors pourquoi ne pas apprendre ensemble. Peut-être ne savez-vous pas encore comment déboguer, alors saisissez cette occasion pour combler cette lacune.

1. Maître du débogage de niveau vétéran : Alert

C'était une époque où Internet ne faisait que commencer. Les pages web front-end étaient principalement utilisées pour l'affichage de contenu, et les scripts de navigateur ne pouvaient fournir que des fonctions auxiliaires très simples aux pages. À cette époque, les pages web s'exécutaient principalement sur des navigateurs dominés par IE6, et les capacités de débogage JS étaient très faibles. Le débogage ne pouvait se faire que via la méthode alert intégrée à l'objet Window. À cette époque, cela ressemblait probablement à ceci :

Il convient de noter que l'effet visible ici n'est pas celui que l'on voyait dans les navigateurs IE de l'époque, mais l'effet dans une version plus récente d'IE. En outre, il ne semblait pas exister de console aussi avancée à cette époque, et alert était utilisé dans le code JS réel de la page. Bien que la méthode de débogage alert soit primitive, elle avait vraiment une valeur indélébile à l'époque, et même aujourd'hui, elle a encore sa place.

2. Le roi du débogage de nouvelle génération : Console

À mesure que JS peut faire de plus en plus de choses dans le front-end Web, ses responsabilités s’accroissent et son statut devient de plus en plus important. La méthode de débogage traditionnelle avec alert a progressivement du mal à répondre aux divers scénarios de développement front-end. De plus, les informations de débogage affichées par alert apparaissent dans une fenêtre peu attrayante et bloquent une partie du contenu de la page, ce qui la rend quelque peu peu conviviale.

D’un autre côté, les messages de débogage avec alert nécessitent d’ajouter des instructions comme "alert(xxxxx)" à la logique du programme pour fonctionner normalement, et alert bloque également la poursuite du rendu de la page. Cela signifie qu’après le débogage, les développeurs doivent supprimer manuellement ces codes de débogage, ce qui est assez fastidieux.

Par conséquent, une nouvelle génération de navigateurs, notamment Firefox, Chrome et IE, a successivement lancé des consoles de débogage JS, prenant en charge des formes comme "console.log(xxxx)" pour afficher les informations de débogage dans la console sans affecter directement l’affichage de la page. En prenant IE comme exemple, cela ressemble à ceci :

Eh bien, adieu à la laide pop-up alert. Et les étoiles montantes menées par le navigateur Chrome ont ajouté des fonctionnalités plus riches à Console :

Vous pensez que c’est assez satisfaisant ? L’imagination de l’équipe de développement de Chrome est vraiment admirable :

Bon, je me suis un peu écarté du sujet. En bref, l’apparition de la console et de l’objet Console intégré au navigateur a apporté une grande commodité au débogage du développement front-end.

Certains pourraient demander : ce genre de code de débogage ne doit-il pas aussi être nettoyé après le débogage ?

Concernant cette question, si vous effectuez d’abord une vérification d’existence avant d’utiliser l’objet console, alors ne pas le supprimer ne cassera pas la logique métier. Bien sûr, par souci de propreté du code, après le débogage, vous devriez tout de même supprimer autant que possible ces codes de débogage sans lien avec la logique métier.

3. Débogage par points d’arrêt JS

Point d'arrêt : l'une des fonctions du débogueur ; il peut interrompre le programme là où c'est nécessaire, ce qui facilite l'analyse. Vous pouvez également définir des points d'arrêt lors d'une session de débogage, et la fois suivante, laissez simplement le programme s'exécuter automatiquement jusqu'à la position du point d'arrêt défini, où il s'arrêtera au point d'arrêt précédemment défini. Cela facilite grandement l'opération et fait gagner du temps. — Baidu Baike

Le débogage par points d'arrêt JS consiste à ajouter des points d'arrêt au code JS dans les outils de développement du navigateur, afin que l'exécution de JS s'arrête à une position spécifique, ce qui permet aux développeurs d'analyser le segment de code et de traiter la logique. Afin d'observer l'effet du débogage par points d'arrêt, nous avons préparé à l'avance un morceau de code JS :

Le code est très simple : définir une fonction, passer deux nombres, ajouter un entier aléatoire à chacun, puis renvoyer la somme des deux nombres. En prenant les outils de développement Chrome comme exemple, examinons la méthode de base du débogage par points d'arrêt JS.

3.1. Point d'arrêt dans Sources

Tout d'abord, d'après la sortie de la console dans la figure ci-dessus, nous pouvons voir que le code de test aurait dû s'exécuter normalement. Mais pourquoi « aurait dû » ? Parce qu'un nombre aléatoire est ajouté dans la fonction. Le résultat final est-il vraiment correct ? C'est une supposition sans intérêt, mais supposons que je veuille maintenant vérifier : les deux nombres passés à la fonction, les nombres aléatoires ajoutés et la somme finale. Alors, comment faire ?

Méthode 1, la plus ordinaire mentionnée précédemment : que l'on utilise alert ou console, nous pouvons vérifier comme ceci :

D'après la figure ci-dessus, nous avons ajouté trois lignes de code console pour afficher les variables de données qui nous intéressent. Enfin, à partir de la sortie dans la console (panneau Console), nous pouvons clairement vérifier si l'ensemble du processus de calcul est normal, répondant ainsi aux exigences de vérification de notre énoncé de problème.

Méthode 2 : l’inconvénient évident de la méthode 1 est qu’elle ajoute beaucoup de code redondant. Voyons ensuite si l’utilisation de points d’arrêt pour la vérification est plus pratique. Tout d’abord, regardons comment ajouter un point d’arrêt et quel est l’effet après l’arrêt :

Comme le montre la figure, le processus d’ajout d’un point d’arrêt à un morceau de code est : « F12 (Ctrl + Shift + I) pour ouvrir les outils de développement » → « cliquer sur le menu Sources » → « trouver le fichier correspondant dans l’arborescence de gauche » → « cliquer sur la colonne des numéros de ligne » pour terminer l’ajout/la suppression d’un point d’arrêt sur la ligne actuelle. Une fois le point d’arrêt ajouté, actualisez la page et l’exécution JS s’arrêtera au point d’arrêt. Dans l’interface Sources, vous verrez toutes les variables et valeurs de la portée actuelle. Il suffit de vérifier chaque valeur pour satisfaire aux exigences de vérification de l’énoncé de notre problème.

Maintenant, le problème se pose : les lecteurs attentifs remarqueront que lorsque le code s’exécute jusqu’au point d’arrêt, les valeurs affichées des variables a et b ont déjà subi l’addition, et nous ne pouvons pas voir les 10 et 20 initiaux passés lors de l’appel de la fonction sum. Que faire alors ? Nous devons revenir en arrière et d’abord apprendre quelques bases du débogage avec points d’arrêt. Après avoir ouvert le panneau Sources, nous verrons en fait le contenu suivant. Suivons le curseur de la souris et voyons ce que signifie chaque partie :

De gauche à droite, les fonctions représentées par chaque icône sont :

• Suspendre/Reprendre l’exécution du script : suspendre/reprendre l’exécution du script (le programme s’arrête lorsqu’il atteint le prochain point d’arrêt).
• Passer par-dessus l’appel de fonction suivant : exécuter l’appel de fonction à l’étape suivante (sauter à la ligne suivante).
• Entrer dans l’appel de fonction suivant : entrer dans la fonction actuelle.
• Sortir de la fonction actuelle : sortir de la fonction en cours d’exécution.
• Désactiver/Activer tous les points d’arrêt : désactiver/activer tous les points d’arrêt (sans les annuler).
• Mettre en pause sur les exceptions : définir automatiquement un point d’arrêt sur les exceptions.

À ce stade, les touches de fonction du débogage par points d'arrêt ont été pour la plupart présentées. Ensuite, nous pouvons parcourir notre code de programme ligne par ligne et voir comment chaque variable change après l'exécution de chaque ligne, comme le montre la figure ci-dessous :

Comme ci-dessus, nous pouvons voir tout le processus des variables a et b, depuis leurs valeurs initiales, jusqu'à l'ajout de valeurs aléatoires entre-temps, puis enfin au calcul de la somme et à l'affichage du résultat final. Satisfaire aux exigences de vérification de l'énoncé du problème est plus que facile.

Pour les touches de fonction restantes, nous modifions légèrement notre code de test et utilisons une image GIF pour démontrer leur utilisation :

Une chose à noter ici : la fonctionnalité d'afficher directement les valeurs des variables dans la zone de code est une nouvelle fonctionnalité ajoutée dans les versions récentes de Chrome. Si vous utilisez encore une version plus ancienne de Chrome, vous ne pourrez peut-être pas afficher directement les informations sur les variables à un point d'arrêt. Dans ce cas, vous pouvez déplacer la souris sur le nom de la variable et marquer une brève pause pour voir la valeur de la variable. Vous pouvez également sélectionner le nom de la variable avec la souris, faire un clic droit et choisir « Add to watch » pour l'afficher dans le panneau Watch. Cette méthode fonctionne aussi pour les expressions. De plus, lorsque vous êtes à un point d'arrêt, vous pouvez passer au panneau Console, saisir directement le nom de la variable dans la console et appuyer sur Entrée pour afficher les informations sur la variable. Cette partie est relativement simple. Compte tenu de la longueur de l'article, je ne fournirai pas de démonstrations en images.

3.2. Point d'arrêt Debugger

Le soi-disant point d'arrêt Debugger est en fait un nom que je lui ai donné moi-même ; je ne connais pas le terme professionnel. Concrètement, cela signifie ajouter une instruction « debugger; » au code. Lorsque le code s'exécute jusqu'à cette instruction, il s'arrête automatiquement. Les opérations suivantes sont presque exactement les mêmes que l'ajout d'un point d'arrêt dans le panneau Sources, la seule différence étant qu'après le débogage, vous devez supprimer l'instruction.

Puisqu'à part la manière différente de définir le point d'arrêt, sa fonction et son effet sont les mêmes que l'ajout d'un point d'arrêt dans le panneau Sources, pourquoi cette méthode existe-t-elle encore ? Je pense que la raison est la suivante : pendant le développement, nous rencontrons parfois des situations où des fragments HTML (y compris le code JS intégré) sont chargés de manière asynchrone, et cette partie du code JS est introuvable dans l'arborescence Sources, nous ne pouvons donc pas ajouter directement des points d'arrêt dans les outils de développement. Si nous voulons ajouter un point d'arrêt à des scripts chargés de manière asynchrone, "debugger;" entre en jeu. Regardons son effet directement à travers une image GIF :

4. Débogage des points d'arrêt DOM

Les points d'arrêt DOM, comme leur nom l'indique, ajoutent des points d'arrêt à des éléments DOM à des fins de débogage. Dans l'utilisation réelle, l'effet des points d'arrêt se retrouve finalement dans la logique JS. Examinons tour à tour l'effet spécifique de chaque type de point d'arrêt DOM.

4.1. S'arrêter lorsque les nœuds enfants à l'intérieur d'un nœud changent (Pause lors des modifications du sous-arbre)

À mesure que le développement front-end devient de plus en plus complexe, le code JS front-end s'accroît et la logique devient plus complexe. Une page web apparemment simple est généralement accompagnée de gros blocs de code JS, impliquant de nombreuses opérations d'ajout, de suppression et de modification de nœuds DOM. Inévitablement, il existe des situations où il est difficile de localiser un morceau de code directement via le code JS, mais nous pouvons rapidement localiser le nœud DOM concerné via le panneau Elements des outils de développement. À ce stade, localiser les scripts grâce aux points d'arrêt DOM devient particulièrement important. Jetons un coup d'œil via la démonstration GIF :

La figure ci-dessus démontre l'effet des points d'arrêt déclenchés par les opérations d'ajout, de suppression et de permutation d'ordre sur les nœuds enfants (li) de l'ul. Notez que la modification des attributs ou du contenu des nœuds enfants ne déclenche pas les points d'arrêt.

4.2. S'arrêter lorsque les attributs d'un nœud changent (Pause lors des modifications d'attributs)

D'un autre côté, à mesure que la logique métier gérée par le front-end devient de plus en plus complexe, la dépendance au stockage de certaines données se renforce. Le stockage de données temporaires dans les attributs (personnalisés) des nœuds DOM est le choix privilégié des développeurs dans de nombreux cas. Surtout après que la norme HTML5 a renforcé la prise en charge des attributs personnalisés (par exemple, dataset, data-*, etc.), l'utilisation des paramètres d'attributs est devenue de plus en plus répandue. Par conséquent, les outils de développement Chrome fournissent également une prise en charge des points d'arrêt sur modification d'attribut, et l'effet est à peu près le suivant :

Cette méthode nécessite également une attention particulière : toute opération sur les attributs des nœuds enfants ne déclenchera pas le point d'arrêt sur le nœud lui-même.

4.3. Interrompre lorsque le nœud est supprimé (Break on node removal)

Ce point d'arrêt DOM est très simple à définir, et la condition de déclenchement est claire : lorsque le nœud est supprimé. Par conséquent, cette méthode est généralement utilisée lors de l'exécution de l'instruction `parentNode.removeChild(childNode)`. Cette méthode n'est pas beaucoup utilisée.

Les méthodes de débogage présentées ci-dessus sont essentiellement celles que nous utilisons fréquemment dans le développement quotidien. Utilisées correctement, elles peuvent gérer presque tous les problèmes de notre développement quotidien. Cependant, les outils de développement prennent également en compte davantage de scénarios et fournissent des méthodes de point d'arrêt supplémentaires, comme le montre la figure :

5、XHR Breakpoints

Ces dernières années, le développement front-end a connu des changements spectaculaires — d'abord peu connu, il est aujourd'hui extrêmement populaire. Ajax alimente les applications web riches, et les applications monopages WebApp mobiles sont florissantes. Tout cela est indissociable de l'objet XMLHttpRequest, et "XHR Breakpoints" est une fonctionnalité de débogage par points d'arrêt conçue spécifiquement pour les opérations asynchrones.

Nous pouvons ajouter des conditions de point d'arrêt pour les points d'arrêt asynchrones via le bouton « + » à droite de « XHR Breakpoints ». Lorsque l'URL d'une requête asynchrone remplit cette condition, la logique JS déclenche automatiquement un point d'arrêt. L'animation de démonstration ne montre pas l'emplacement du point d'arrêt car la démo utilise la méthode ajax encapsulée de jQuery, et le code a été minifié, donc aucun effet évident n'est visible. En fait, le point d'arrêt XHR est déclenché à l'instruction `xhr.send()`.

La puissance des points d'arrêt XHR réside dans la possibilité de personnaliser les règles de point d'arrêt, ce qui signifie que nous pouvons définir des points d'arrêt pour un lot de requêtes, une seule requête, ou même toutes les requêtes asynchrones—très puissant. Cependant, il semble que cette fonctionnalité soit peu utilisée dans le développement quotidien, du moins je ne l'utilise pas beaucoup. Il y a probablement deux raisons : premièrement, ce type de besoin de débogage par point d'arrêt est rarement rencontré dans les activités quotidiennes ; deuxièmement, le développement front-end à ce stade est principalement basé sur des frameworks JS. Même le plus basique jQuery a déjà bien encapsulé Ajax, et très peu de personnes encapsulent elles-mêmes les méthodes Ajax. De plus, pour réduire la taille du code, les projets choisissent généralement des bibliothèques de code minifiées, ce qui rend le suivi des points d'arrêt XHR relativement moins aisé.

6、Points d'arrêt des écouteurs d'événements

Les points d'arrêt sur les écouteurs d'événements, c'est-à-dire définir des points d'arrêt en fonction des noms d'événements. Lorsqu'un événement est déclenché, le point d'arrêt suspend l'exécution à l'endroit où l'événement est lié. Les points d'arrêt sur les écouteurs d'événements listent tous les événements de page et de script, y compris la souris, le clavier, l'animation, les minuteurs, XHR, etc. Cela réduit considérablement la difficulté de débogage de la logique métier liée aux événements.

L'exemple de démonstration montre les effets de point d'arrêt lorsque l'événement click est déclenché et lorsque setTimeout est défini. L'exemple montre qu'après avoir sélectionné le point d'arrêt de l'événement click, le fait de cliquer sur les deux boutons a déclenché des points d'arrêt, et que lorsque setTimeout est défini, le point d'arrêt « Set Timer » est déclenché.

Le débogage est une partie très importante du développement de projet. Il nous aide non seulement à localiser rapidement les problèmes, mais nous fait aussi gagner du temps de développement. Maîtriser diverses méthodes de débogage apportera certainement de nombreux bénéfices à votre carrière. Cependant, parmi tant de méthodes de débogage, choisir celle qui convient à votre scénario d'application actuel demande de l'expérience et une accumulation par essais successifs.

Auteur : Zheng Wujiang
Source : http://seejs.me/2016/03/27/jsdebugger/