— Tu vas résoudre les bugs comme un agent du FBI, mon cœur —

Quand tu écris du JavaScript, tu rencontres trois types de personnes :

1. Ceux qui exécutent le code en disant : “Ça va marcher, c’est sûr.”
2. Ceux qui cassent le clavier en criant : “POURQUOI ÇA MARCHE PAS ?!”
3. Et ceux qui voient l’erreur et disent : “Hmmmm intéressant”, puis activent leur mode Sherlock.

Après cet article, tu vas monter directement dans la 3ᵉ catégorie.
Désormais, quand tu croiseras un bug, tu resteras calme… comme si tu renversais du café dessus 😌☕️

🔥 Le Debugging, c’est quoi ? (Mais pas la version ennuyeuse)

Le debugging, c’est ça :

Imagine que ton code est une maison, et le bug est ce truc bizarre coincé entre les coussins du canapé…
Le debugging = “Okay toi, T’ES QUI ET COMMENT T’ES ARRIVÉ LÀ ?!”

Le but n’est pas seulement de trouver l’erreur, mais de comprendre pourquoi elle existe.
Car résoudre un bug ≠ résoudre le problème.
Comprendre un bug = augmenter ton niveau 🧠✨

🔍 1. Console.log : L’allumette du debugging mais toujours notre meilleur ami

Console.log est immortel.
Console.log est la vie.
Sans console.log, la vie d’un développeur est comme du thé sans sucre : possible, mais triste.

Ce que tu peux voir :

• La valeur des variables
• Jusqu’où la fonction s’exécute
• Quel chemin logique a été suivi
• Les entrées / sorties
• L’état de ton application

Mini Astuce : Utilise des labels

const user = { name: "Cansu", level: 4, mood: "legendary" };
console.log("USER INFO :", user);

Version plus professionnelle :

console.log({ age, username, isLoggedIn });

Quand tu vois ces logs propres dans ta console, tu te sens comme un ingénieur de la NASA, bébé 🚀

🛑 2. Debugger : Le moment “STOP, QUI ES-TU ?”

Le mot debugger, c’est comme dire à la police : “Arrête-moi ici”.

Comment ça marche ?

Quand le code atteint cette ligne, il s’arrête net.
Puis tu avances étape par étape.

function calculatePrice(price, tax) {
  debugger;
  const total = price + tax;
  return total;
}

calculatePrice(100, 18);

Dans DevTools, tu vas voir :

• Call stack (dans quelle chaîne de fonctions l’erreur apparaît)
• Scope (d’où vient cette variable ?)
• Watch expressions (la transformation des variables en temps réel)
• Step in / step out / step over (comme un agent secret)

Debugger fait de toi un “détective de CSI Miami”.
Mets tes lunettes, s’il te plaît 😎🕶️

🧩 3. Breakpoints : Les policiers du code

Les breakpoints disent au code : “Quand tu arrives ici, TU T’ARRÊTES.”

Breakpoints avancés :

• Conditional Breakpoint → “Arrête-toi quand i = 5”
• DOM Breakpoint → “Si cet élément change, stoppe”
• XHR Breakpoint → “Quand cette requête s’envoie, arrête-toi”

Exemple (Conditional Breakpoint)

for (let i = 0; i < 20; i++) {
  console.log("Index :", i);
}

Clic droit sur le numéro de ligne → “Add conditional breakpoint”
Condition : i === 13

Tu exécutes le code…
BAM !
Ça stoppe à 13.
Un nombre maléfique, mais chanceux pour le debugging.

🔄 4. Try…Catch : L’art de dompter le chaos

Le JavaScript, parfois, ça te sort des erreurs qui…
Te laissent devant un écran tout blanc.
Et toi : “Qu’est-ce que tu fais là, mon ange… ?”

Try/catch te sauve la vie dans ces moments-là.

Exemple :

try {
  const data = JSON.parse("{this is not json}");
} catch (err) {
  console.error("Erreur capturée mon amouuur :", err.message);
}

Mini Astuce :

Ne mets pas tout dans un try/catch.
Seulement les zones à risque.
Sinon, trouver la source de l’erreur = résoudre un nœud de laine.

🧠 5. Lire les messages d’erreur est une compétence (ils ne mentent pas)

Être développeur =
50% écrire du code
50% lire des erreurs

Les erreurs JS les plus connues

1. “Unexpected token”

Souvent dû à :

• Une apostrophe manquante
• Une parenthèse en trop
• Une virgule mal placée

const obj = { name: "Cansu" } 

2. “Cannot read property of undefined”

Quelque chose est undefined →
Et tu essaies d’y chercher une propriété.

let user = null;
console.log(user.name); // Mais il n’existe pas 😭

3. “ReferenceError”

Variable utilisée avant d’être déclarée.

console.log(a);
let a = 5; // Le hoisting te gifle ici

🔬 6. Isoler le problème : Coincer le bug dans un coin

Chercher un bug dans un grand projet = chercher un anneau dans un labyrinthe.

Technique efficace :

• Désactive blocs par blocs
• Déplace le code suspect dans un fichier séparé
• Teste chaque partie seule
• Mets en commentaire ce qui n’est pas important
• Réduis progressivement la zone du crime

Et là, tu accules le bug au mur…
Puis tu lui dis : “Salut mon chéri, on doit parler.”

🧼 7. Code propre = Moins de migraines

La plupart des bugs viennent de petits détails…
Comme les relations passées 😂

Règles d’or du clean code :

• Fonctions courtes
• Un seul rôle par fonction
• Noms de variables clairs
• Pas trop de if/else
• Les commentaires servent à EXPLIQUER, pas à faire de la magie

Mauvais code :

function x(a, b) {
  return a + b * 2 / 5;
}

Bon code :

function calculateDiscount(price, rate) {
  const discount = price * rate;
  return price - discount;
}

70% du debugging vient d’un mauvais nommage.
Un bon nom = moins de souffrance ❤️

💂 8. Outils & Extensions : Ton arsenal pour débugger

Les héros de VS Code :

• Debugger for Chrome
• ESLint (élimine les erreurs avant qu’elles ne naissent)
• Prettier (nettoie le code et apaise ton âme)

Les super-pouvoirs de Chrome DevTools :

• Analyse réseau
• Graphiques de performance
• Détection de fuites mémoire
• Inspection des event listeners

Debugging ≠ juste trouver une erreur
Debugging = améliorer ton code.

🎯 CONCLUSION : Le debugging n’est PAS un cauchemar

Je sais que le debugging te faisait peur…
Mais maintenant tu es :

• Magicien(ne) du console.log 🔮
• Guerrier(ère) du debugger ⚔️
• Ninja du breakpoint 🥷
• Traducteur/trice des messages d’erreur 📜
• La lumière de l’univers JS ⭐

Souviens-toi :
Il n’existe pas de développeur sans erreurs,
Seulement des développeurs qui ne savent pas encore les attraper.