Déboguer comme un développeur senior : observer et évaluer

Cette semaine a été spectaculairement intense. La nouvelle chaîne YouTube diffusant le cours explose avec les abonnements ; il vient d'entrer dans sa 3ème semaine...

Le site Web du cours est maintenant en ligne; vous pouvez voir tout le cours là-bas, même si j'ajoute des vidéos tout le temps et que j'ai fait environ 1/3 du travail.

À l'heure actuelle, il a 3 heures et 17 minutes de contenu. J'ai encore une heure de contenu prêt à ajouter, et je travaille sur plusieurs autres. Je suis à peu près sûr que le cours durera bien plus de 6 heures une fois terminé.

Je travaille également sur d'autres vidéos intéressantes, comme celle sur la protection contre les exploits de sérialisation . J'écrirai un article de blog complet à ce sujet dans les semaines à venir.

Si vous avez des questions, des pensées ou des idées, j'aimerais avoir de vos nouvelles. Vous trouverez ci-dessous la vidéo de cette semaine et la transcription.

Transcription

Bienvenue dans la troisième partie du débogage chez Scale où nous apprenons à chasser les bogues comme les pros !

Dans cette section, nous aborderons les expressions de surveillance qui sont la pierre angulaire du débogage. C'est tellement important que je reviendrai sur le sujet plus tard.

La zone de surveillance est la zone en bas de l'écran

Dans IntelliJ, nous pouvons également intégrer des expressions de surveillance à côté du code. La veille est l'une des capacités les plus importantes d'un débogueur. C'est ainsi que nous pouvons voir ce qui se passe dans le débogueur.

Mais je vais aller beaucoup plus loin que cela. Surtout pour le marquage d'objets qui est l'une des fonctionnalités de débogage les plus cool jamais créées.

Valeur de retour

Vous est-il déjà arrivé de revenir d'une méthode pour vous demander « qu'est-ce que cette méthode a renvoyé ? »

Ceci est très courant, surtout lorsque la valeur de retour n'est pas stockée dans une variable. Heureusement, l'IDE a la possibilité d'enregistrer cette valeur pour nous afin que nous puissions l'inspecter immédiatement !

En activant cette option, nous pouvons voir les valeurs de retour de toutes les méthodes futures. Si nous entrons dans la méthode isPrime puis en sortons, vous pourrez voir la valeur de retour de la méthode en bas ici.

Évaluer

L'expression d'évaluation est l'une des fonctionnalités intéressantes du débogueur que nous n'utilisons pas assez.

Nous pouvons lancer la boîte de dialogue d'évaluation de l'expression à partir du menu contextuel et saisir n'importe quelle expression Java valide. Il s'agit d'un outil puissant qui peut invoquer n'importe quelle méthode, faire de l'arithmétique et même modifier la valeur des variables en conséquence.

Si vous avez besoin de simuler quelque chose qui est difficile à tester dans le code actuel, c'est l'endroit où vous pouvez jouer avec la plate-forme et tester des "théories sauvages".

Cela ressemble beaucoup au REPL que nous avons dans les nouvelles versions de Java, mais c'est mieux à bien des égards car nous pouvons exécuter du code dans le contexte de notre application.

Si j'ai une méthode qui renvoie la mauvaise valeur, je copie souvent l'appel dans une boîte de dialogue d'évaluation et j'essaie différentes combinaisons de l'appel pour voir "ce qui fonctionne".

Le simple fait d'essayer toutes les options sans redémarrer peut nous faire gagner beaucoup de temps !

Vous pouvez lancer cette boîte de dialogue avec la Alt-F8 .

Regardez

La capacité de surveillance dans IntelliJ est absolument spectaculaire.

IntelliJ nous permet d'intégrer la montre directement dans l'éditeur IDE en sélectionnant "Ajouter une montre en ligne" dans le menu contextuel. Il s'agit d'une fonctionnalité étonnante qui, pour autant que je sache, est unique à JetBrains.

Une fois sélectionnée, la montre apparaît à droite à côté de la ligne où nous avons ajouté la montre en ligne qui facilite l'évaluation avec le code. Ceci est très pratique lorsque vous revenez plusieurs fois sur la même ligne.

On peut aussi utiliser la montre standard qui ajoutera des éléments avec les autres variables. Ceci est utile pour les objets que nous voulons suivre sur de grandes zones du code. J'ai beaucoup à dire sur la zone de surveillance à mesure que nous avançons, mais pour l'instant, mettons cela en attente.

Changer d'état

Définir la valeur est une fonctionnalité que j'oublie souvent d'utiliser lors du débogage.

C'est dommage car c'est tellement puissant. Nous pouvons définir la valeur de n'importe quel champ en cliquant dessus avec le bouton droit de la souris et en sélectionnant la valeur définie.

Nous pouvons également utiliser F2 pour accélérer cela

Je peux changer la valeur en n'importe quelle valeur arbitraire. Cela peut également s'appliquer aux objets où je peux attribuer une valeur existante ou invoquer une méthode de création, une nouvelle instruction ou toute expression de mon choix.

C'est une fonctionnalité remarquablement puissante où nous pouvons muter dynamiquement l'objet pour reproduire un état que nous voulons tester.

Nous pouvons combiner cette capacité avec le saut à la ligne dont nous avons discuté précédemment et tester une méthode à travers de nombreuses permutations différentes. Même ceux qui pourraient ne pas être reproductibles normalement. Un bon exemple serait le code que j'ai qui ne fonctionne que sur Windows. Mais j'ai un Mac.

Je change juste la valeur de la variable statique qui indique le système d'exploitation actuel et teste ce code.

Marquage d'objet

Le marquage d'objet est l'une des fonctionnalités les plus intéressantes dont nous parlerons dans ce cours et il est presque inconnu.

C'est un peu subtil; d'abord, nous ajouterons une montre pour Thread.currentThread() qui renvoie l'instance d'objet représentant le thread actuel.

Comme vous pouvez le voir, je peux voir le fil en cours dans la montre.

Maintenant, je peux exécuter cette méthode encore et encore et voir le thread actuel ; la méthode est-elle toujours exécutée à partir du même thread ?

Eh bien, je peux regarder l'ID du fil, et oui. C'est le même. Donc, c'est probablement thread-safe. Mais comment puis-je vérifier cela?

J'écris généralement l'ID de l'objet ou le pointeur de la variable sur un morceau de papier et je vérifie s'il s'agit de la même valeur. C'est une douleur et ne s'écaille pas. Combien de fois puis-je appuyer sur Continuer encore et encore ?

Dans le menu contextuel, je sélectionne Marquer l'objet et saisis un nom arbitraire. MyThread dans ce cas, une fois que j'ai fait cela, je peux appuyer sur OK

Cela remplace la valeur du thread actuel par la nouvelle étiquette. Ainsi, nous pourrions supposer à tort qu'il ne s'agit que d'un nom pour une expression de surveillance. Ce n'est pas le cas. Nous avons déclaré une nouvelle variable et lui avons donné le nom MyThread .

Nous avons copié la valeur actuelle de l'expression watch dans cette variable. Nous pouvons maintenant traiter cette variable comme nous traitons la plupart des variables dans l'EDI.

Nous pouvons évaluer la valeur ici et obtenir tout ce que nous voulons. Notez le suffixe _DebugLabel ajouté par IntelliJ pour éviter les collisions de noms, mais à part cela, nous pouvons invoquer n'importe quelle opération sur cet objet, comme obtenir le nom ou même accéder au nom du champ privé.

Mais cela va beaucoup mieux…

Ajoutons un point d'arrêt à cette méthode, un point d'arrêt complètement standard comme nous l'avons fait auparavant.

Ce sera un point d'arrêt conditionnel standard ; nous en discuterons assez tôt en profondeur, mais pour le moment, tout ce que vous devez savoir, c'est que je peux définir une condition qui déterminera si le point d'arrêt s'arrêtera ou non.

Zoomons.

Tapons la condition; Je peux comparer MyThread à la valeur actuelle du thread. Notez que cette condition se comportera en conséquence puisque la valeur de MyThread est indépendante de l'instruction watch d'origine de Thread.currentThread() .

Ainsi, si le thread actuel est effectivement différent, le point d'arrêt s'arrêtera à ce stade.

Ceci est extrêmement utile lorsqu'il s'agit de nombreux objets. Dans ce cas, je peux littéralement vérifier si la méthode sera frappée avec le même thread. Je peux l'utiliser pour comparer n'importe quel objet au lieu d'écrire leurs pointeurs sur un morceau de papier !

Oui. Je m'assiérais littéralement avec un morceau de papier et copierais l'adresse du pointeur pour m'assurer que je l'ai bien compris si je le revois. C'est mieux à bien des égards !

J'utilise souvent cela avec des API comme JPA où nous pouvons parfois avoir deux instances d'objet avec la même identité. C'est vraiment difficile à détecter. Marquez simplement un objet, et vous pourrez voir instantanément qu'il s'agit d'une instance différente.

Étant donné que ce cas est évidemment monothread, le point d'arrêt ne sera plus jamais atteint. Mais cela fonctionne plutôt bien pour les cas très élaborés et c'est un outil remarquablement utile !

Pour terminer

Ensuite, nous plongerons profondément dans les points d'arrêt et les choses incroyables qu'ils peuvent faire. Il s'agit d'une vidéo approfondie que vous ne voulez pas manquer.

Si vous avez des questions, veuillez utiliser la section des commentaires. Merci!