Un outil déjà ouvert
Quand un bug apparaît côté navigateur, le premier réflexe n’est pas d’ouvrir un gros outil de debug. La console est déjà là. Souvent ouverte, sinon à deux clics.
Avec le temps, c’est devenu mon point d’entrée par défaut pour comprendre ce qui se passe dans une application web. Pas pour vérifier que « ça log », mais pour voir des valeurs réelles, au moment où le code s’exécute.
Ce que la console traîne derrière elle
La console a une réputation un peu bancale. Elle est souvent associée à des console.log jetés au hasard, laissés dans le code, ou utilisés sans trop savoir pourquoi.
Le souci ne vient pas de la console elle-même. Il vient surtout du fait qu’on log sans se poser de question. Un log sans intention n’aide pas à comprendre grand-chose.
Un log utile répond à une question précise. Le reste, c’est du bruit.
Voir ce qui se passe vraiment
Ce que j’apprécie avec la console, c’est qu’elle permet de regarder le code tourner, sans tout arrêter. Pas besoin de mettre des pauses partout pour commencer à comprendre.
Elle permet par exemple de vérifier rapidement :
- quand une fonction est appelée
- avec quelles données exactes
- dans quel ordre les choses s’enchaînent
Dans beaucoup de cas, ça suffit pour repérer où ça déraille, surtout quand l’état change souvent ou que plusieurs événements se croisent.
Un point fixe dans des contextes variables
En tant que dev indépendant, les projets ne se ressemblent pas toujours. La stack change, le cadre aussi, parfois très vite.
La console, elle, ne change pas. Elle est là quel que soit le framework ou le projet. Ça en fait un outil simple, fiable, et sans prise de tête.
Pourquoi commencer par ça
Ce blog part d’une idée assez simple : la console n’est pas un outil de secours. C’est un outil de travail à part entière.
Bien utilisée, elle permet d’éviter de surcompliquer trop tôt et aide à comprendre ce que fait vraiment le code 🙂