Superpouvoirs de débogage

Le « console logging », c’est le pire. Certains peuvent contester mon opinion sur cet outil pratique, mais je pense que c’est une béquille qui est utilisée par beaucoup d’équipes malgré l’existence de meilleurs outils et méthodes de débogage.

Pour vous faire mieux comprendre ma pensée, je vais parler un peu de mon histoire. Mon premier langage de programmation professionnel a été Python. J’ai passé cinq ans et demi de ma carrière à développer des applications Python/Django, et l’une des choses que je préférais dans cet environnement était un outil appelé PDB, le Python Debugger.

Cet outil est à mon avis un rêve de développeur junior qui devient réalité. À tout moment, je pouvais stopper mon programme et inspecter son état du moment. Je pouvais observer le cycle de vie des variables. Je pouvais voir et suivre la pile des fonctions et des méthodes. En utilisant l’outil, non seulement j’ai pu résoudre les bogues et les problèmes plus rapidement, mais j’ai pu apprendre beaucoup de choses sur ce processus. J’avais l’impression d’avoir une vision à rayons X. Je me sentais comme un superhéros.

Avance rapide d’un certain nombre d’années, et j’ai commencé à travailler plus avec JavaScript. Mon bien-aimé PDB n’était plus là, mais j’ai rapidement appris à utiliser le débogueur et la console DevTools de Chrome. Ces outils ont répondu à tous mes besoins de débogage, proposant aussi un moyen facile et visuel d’ajouter des points d’arrêt à mon code. Je me suis une fois de plus senti comme un superhéros.

Dans ma fonction actuelle chez Spiria, les applications sur lesquelles je travaille sont toutes en TypeScript. Nous utilisons Node et Express en back-end, avec une application React côté client. Du côté client, les choses vont toujours bien. Nous utilisons WebPack pour transpiler le code TypeScript et générer les source maps, et nous sommes capables de déboguer dans Chrome comme nous l’avons toujours fait. En ce qui concerne le back-end, cependant, l’équipe dépendait exclusivement pour le débogage de l’enregistrement de la console. Notre processus de développement et de débogage consistait à faire des changements, à ajouter un tas de journaux de débogage, à exécuter le code, puis à analyser le journal de sortie pour essayer d’avoir une idée de ce qui se passait. C’était un processus lourd qui, à mon avis, produisait plus de bruit qu’il ne donnait des idées. Ma vision à rayons X avait disparu, et je ne me sentais plus du tout comme un superhéros.

De plus, contrairement à notre code front-end, le processus de compilation pour transpiler le code de back-end reposait sur une commande à lancer de façon manuelle. Le process de serveur ne surveillait pas non plus les changements et devait être redémarré manuellement si nous voulions que le dernier code transpilé soit reconnu. Après avoir passé quelques mois avec cet état de fait, je me sentais de plus en plus embourbé dans le processus, et j’aspirais à retrouver mes super-pouvoirs. Heureusement, je n’étais pas seul à me sentir ainsi, et notre équipe a été privilègiée de pouvoir prendre le temps d’améliorer ces processus.

Dans le cadre d’un projet qui impliquait un plus grand volume de travail en back-end, j’ai cherché à améliorer notre situation de débogage du mieux que j’ai pu. La première étape a été de récupérer des pouvoirs de débogage corrects. Heureusement, Node est livré avec un drapeau --inspect, qui ouvre un WebSocket sur un port particulier, exposant le processus Node pour le débogage. Chrome peut s’y connecter et ouvrir une instance de ses DevTools qui fonctionnent avec Node. Il y a même des extensions bien pratiques ; j’en utilise une appelée Node Inspect Manager (NiM), pour ouvrir automatiquement DevTools quand un débogueur est exposé à un port prédéfini. Pouvoirs des rayons X revenus !

Cependant, j’étais toujours insatisfait du processus dans son ensemble. Chaque fois que j’apportais des modifications au code, je devais tuer mon process serveur, reconstruire le code du serveur et démarrer le process serveur. Il y avait là aussi une solution facile. Le transpileur TypeScript est livré avec un drapeau --watch, qui lui permet de retranspiler chaque fois qu’il détecte des changements de code. Pouvoirs métamorphes, ok !

Enfin, je voulais que mon process serveur redémarre chaque fois qu’il détectait des changements dans le code transpilé. Ce fut relativement facile aussi, avec un outil appelé Nodemon. C’est un wrapper léger autour de Node, qui redémarre le process lorsque des changements de code sont détectés. Il supporte les mêmes drapeaux que la commande Node ; notre processus de débogage était donc constamment actif. Vitesse de l’éclair, ok aussi !

Je me sentais à nouveau comme un superhéros. J’ai été capable d’écrire efficacement du code et de le déboguer à la volée. Nous n’avions plus à faire le travail de rebuild du code et de redémarrage manuel des process. Il y avait cependant un dernier élément qui m’embêtait encore, je devais lancer toutes ces commandes séparées pour voir les changements de code, et démarrer séparément Nodemon. Je me suis souvenu d’un outil que j’avais utilisé dans un projet précédent appelé npm-run-all, qui est un excellent petit outil qui peut être utilisé pour exécuter un certain nombre de scripts distincts, en série ou en parallèle. Maintenant, nous entrons une commande, et npm lance watch:server ; le reste se fait comme par magie.

Des processus convenables pour le débogage sont cruciaux pour toute équipe. Tous les développeurs peuvent apprendre beaucoup en inspectant correctement leur code et leurs workflows, quel que soit leur niveau d’expérience. Il en résulte des applications plus performantes et sans bogues, pour satisfaire à la fois les développeurs, les différents intervenants et les clients.