Où en es-tu ?
Chargement…
Méthode : 20 minutes par exercice
- Lis le brief et devine. Avant de lancer quoi que ce soit : que devrait faire ce code ? Écris la réponse dans ta tête, en une phrase.
- Exécute. Bouton Exécuter. Compare la sortie réelle à ce que tu avais deviné. C'est là que 80 % du bug devient visible.
- Formule une hypothèse. Pas « ça marche pas », mais « la boucle s'arrête un tour trop tôt » ou « la fonction reçoit une copie ».
- Corrige une chose. Si tu corriges trois lignes d'un coup et que ça passe, tu n'as rien appris. Une hypothèse = une modification.
- Vérifie. Bouton Vérifier : un test caché valide le comportement, comme un vrai test Go.
- Lis l'explication, même si tu as trouvé. Le bug est la partie visible ; la leçon est la partie utile.
Plan sur 8 semaines
Semaine 1 — Diagnostic et fondations
Passe le diagnostic (onglet 1). Puis 2 exercices du niveau 1 par jour, 20 minutes chacun. Objectif : 100 % du niveau 1 validé avant de passer à la suite, pas 80 %.
Semaine 2 — Slices, maps, structs
Tout le niveau 2. C'est le palier qui rapporte le plus : l'aliasing de slices et la sémantique de copie des structs expliquent la majorité des bugs Go qu'on voit en production.
Semaine 3 — Erreurs et defer
Niveau 3, exercices 1 à 3. Écris à la main le tableau « ce que defer voit » pour chaque exercice. Ajoute 30 minutes de lecture de la doc errors et defer sur pkg.go.dev.
Semaine 4 — Interfaces et pointeurs
Le reste du niveau 3. Force-toi à écrire les jeux de méthodes à la main (valeur vs pointeur) : c'est ce qui fait la différence entre « ça compile » et « je sais pourquoi ça compile ».
Semaine 5-6 — Concurrence
Tout le niveau 4, sans exception. Règle absolue : avant de lire la solution, écris sur papier les goroutines en présence, qui envoie, qui reçoit, qui ferme, et qui attend qui.
Semaine 7 — Idiomes et production
Tout le niveau 5. Ici on ne cherche plus un bug, on repère une dette technique : fuite de timer, allocations inutiles, erreurs ignorées, tags JSON oubliés.
Semaine 8 — Code réel
Relis 300 lignes de la bibliothèque standard (strings, sort, net/http) en te demandant à chaque fonction : « quel bug l'auteur a-t-il évité ici ? ». Puis reprends tes propres dépôts avec cette grille.
Les 10 règles à retenir
- Une slice est un en-tête de 3 mots (pointeur, longueur, capacité) : passé par valeur, elle partage son tableau.
- append peut écrire dans une case déjà utilisée si la capacité le permet. Toujours réassigner le résultat.
- range copie l'élément : pour modifier, itère par index et prends &s[i].
- Lire une map nil est légal, écrire est un panic. Initialise toujours avec make.
- defer s'exécute à la sortie de la fonction, jamais du bloc.
- Une erreur ne se compare pas avec == si elle est enveloppée : errors.Is / errors.As.
- Une interface n'est nil que si son type et sa valeur sont nil. Le « typed nil » ment.
- WaitGroup et Mutex ne se copient jamais : toujours par pointeur.
- Seul l'émetteur ferme un canal. Recevoir d'un canal fermé est normal, y envoyer panique.
- Une méthode avec receiver pointeur modifie l'original ; par valeur, elle travaille sur une copie.