Programmer sans faire la course : apprendre C#, trouver son rythme et créer Snake
Un atelier pratique pour développeurs : compétences relationnelles, travail sans surcharge, apprentissage de C# par l’expérimentation, Snake en console et questionnaire avec profil envoyé par e-mail.
L’article complet est disponible ci-dessous. Activez JavaScript pour les quiz et les simulations.
Atelier C# et bonnes habitudes de travail
Programmer n’est pas une course contre la montre. C’est apprendre à prendre de bonnes décisions avec une attention limitée.
Vous pouvez passer dix heures à coder et ne toujours pas savoir si vous avez résolu le bon problème. En quarante-cinq minutes, vous pouvez aussi monter une petite expérience, vérifier une hypothèse, noter votre conclusion et reprendre demain sans reconstruire tout le contexte.
Cet atelier associe compétences relationnelles, pratique de C# et repos conscient. Vous construirez un Snake en console inspiré de la simplicité des anciens téléphones, prendrez trois décisions de conception et découvrirez votre style de travail dominant.
Commencez par changer de mesure
Travailler longtemps ne signifie pas produire un travail utile
En programmation, il est facile de confondre effort et progrès. L’éditeur est ouvert, le clavier s’active et les onglets se multiplient. Pourtant, le produit ne gagne rien à cette agitation. Il a besoin d’un risque réduit, d’une hypothèse vérifiée, d’un contrat clair ou d’une fonctionnalité que l’on puisse réceptionner en confiance.
Avant chaque plage de travail, écrivez donc une phrase : à quoi verrai-je que cette séance a été utile ? Une bonne réponse est observable : un test reproduit le bug, un endpoint renvoie le bon contrat, le joueur déplace un caractère ou l’équipe connaît la décision et son responsable.
Il ne dit ni si le problème a été compris, ni si la modification est sûre.
Il montre que nous en savons davantage et pouvons passer à l’étape suivante.
Elle permet de reprendre demain sans recharger tout le problème dans votre tête.
Après 70 minutes de débogage, vous ne percevez plus de nouveaux indices. Quelle réaction favorise le plus les progrès ?
Je reste devant l’écran jusqu’à ce que le problème disparaisse
Je note mes hypothèses, prends une vraie pause et reviens avec un nouveau test précis
Choisissez une réaction et examinez son coût.
45 minutes de travail + 15 minutes pour retrouver votre attention
Une heure peut constituer une boucle d’apprentissage complète
Il ne s’agit pas d’obéir à un chronomètre. Il s’agit de poser des limites qui imposent un retour concret. Si la tâche ne tient pas dans la boucle, réduisez le résultat attendu. N’ajoutez pas des heures à un travail mal défini.
Mini-jeu : reconstituez la boucle
Quel ordre apprend mieux que la lecture seule ?
Exécuter et observerRecueillez un résultat ou une erreur précise.
Définir un résultatUn comportement, pas le système entier.
Quitter l’écranLaissez l’information s’ancrer et retrouvez votre attention.
Construire la plus petite étapeLe code doit répondre à une seule question.
Expliquer avec vos motsNotez la décision et la question suivante.
Commencez par définir le résultat.
Recommencer
Des compétences relationnelles qui tiennent en production
Les erreurs les plus coûteuses commencent souvent par une phrase que personne n’a précisée
Les compétences relationnelles ne sont pas un supplément à la technique. Elles synchronisent les représentations de chacun. Le développeur, le responsable produit et l’utilisateur peuvent employer les mêmes mots pour désigner trois résultats différents. Le code ne fait que figer l’une de ces interprétations.
Au lieu de demander « que dois-je faire ? », demandez : qui prend cette décision, quel état d’entrée est valide, comment reconnaîtrons-nous la réussite et que doit-il se passer en cas d’erreur ? Ces quatre réponses évitent souvent davantage de travail qu’une bibliothèque supplémentaire.
Elle expose le contexte, l’observation, la tentative et l’inconnue exacte.
Elle permet aux autres de contester la direction avant d’écrire du code coûteux.
Elle sépare la personne de la décision, et le point bloquant de la suggestion d’amélioration.
Il communique le risque tant que l’équipe peut encore adapter le plan.
« Je ne sais pas » est une réponse professionnelle si elle s’accompagne d’un plan de vérification. Une certitude feinte est une dette que la production finit généralement par payer.
La personne qui relit le code écrit seulement « ce n’est pas bon ». Quelle réponse améliore le plus la qualité ?
Je demande de préciser le contrat non respecté, le risque et le comportement attendu
Je défends mon implémentation parce qu’elle fonctionne sur mon ordinateur
Choisissez la démarche qui transforme une opinion en décision.
Apprendre avec un modèle qui fonctionne
C# devient plus simple quand chaque notion reçoit une mission
Les débutants essaient souvent de mémoriser le langage chapitre par chapitre : types, boucles, classes, collections. Mais une connaissance sans usage s’oublie vite. Le jeu donne une responsabilité à chaque élément. Une position décrit un point, un enum la direction, une collection le corps du serpent, une boucle le temps et une méthode de mise à jour un changement d’état.
Vous n’avez pas besoin de connaître tout C# pour commencer. Il vous faut quelques repères et les retours rapides du compilateur. Écrivez une étape, lancez-la, nommez le résultat, puis ajoutez seulement la règle suivante.
Une paire X/Y décrit la position sans état caché.
L’enum limite la direction à quatre valeurs valides.
Le début est la tête, la fin est la queue et le coût du déplacement est lisible.
Un seul endroit gère les règles, les points, la nourriture et le rythme.
internal readonly record struct Position(int X, int Y)
{
public static Position operator +(Position left, Position right) =>
new(left.X + right.X, left.Y + right.Y);
}
internal enum Direction
{
Up,
Right,
Down,
Left
}Projet : Snake en console
D’abord un caractère. Ensuite une règle. Enfin un jeu.
Ce classique est un bon laboratoire : le résultat est immédiatement visible. Ne commencez pas par les points, la nourriture et les couleurs. Dessinez d’abord le plateau, puis déplacez la tête. Ajoutez ensuite le corps, les collisions et, seulement alors, la vitesse.
Télécharger Program.cs complet Télécharger SnakeLab.csprojUne boucle sur X et Y enseigne les coordonnées.
La direction devient un changement de position.
Une nouvelle tête arrive, l’ancienne queue disparaît.
Conserver la queue allonge le serpent.
Le mur ou le corps du serpent met fin à la partie.
private void Update()
{
_direction = _nextDirection;
var head = _snake.First!.Value;
var next = head + Delta(_direction);
var grows = next == _food;
var tail = _snake.Last!.Value;
var hitsWall =
next.X <= 0 || next.X >= _width - 1 ||
next.Y <= 0 || next.Y >= _height - 1;
// Entrer sur la position actuelle de la queue est sans danger
// si la queue est supprimée au cours de la même étape.
var hitsBody = _occupied.Contains(next) && (grows || next != tail);
if (hitsWall || hitsBody)
{
_running = false;
return;
}
AddHead(next);
if (grows)
{
_score += 10;
SpawnFood();
return;
}
var removedTail = _snake.Last!.Value;
_snake.RemoveLast();
_occupied.Remove(removedTail);
}La tête entre sur une case actuellement occupée par la queue. Est-ce toujours une collision ?
Oui, toute case occupée met fin au jeu sans exception
Non, lors d’un déplacement ordinaire, la queue disparaît dans la même mise à jour
Pensez à l’état avant et après une étape du jeu.
Simulation d’un retour utile
Découvrez comment une petite étape transforme une idée en connaissance
Lancez le parcours : objectif, code, compilation, observation, note et pause.
Lancer la boucle
Mesurer sans microgérer
Un outil doit révéler le rythme, pas punir la réflexion
Un minuteur peut rendre visibles les pauses et les changements de contexte. L’historique des commits peut montrer la taille des étapes. Un tableau de tâches peut limiter le travail en cours. Aucun de ces outils ne peut toutefois évaluer seul la qualité des décisions.
Ne mesurez que ce qui conduit à une discussion ou à une expérience. Si un graphique ne change aucun comportement, c’est de la décoration. S’il pousse à paraître actif en permanence, il nuit au travail qu’il devait soutenir.
| Besoin | Outil simple | Que mesurer | Ce qu’il ne faut pas en conclure |
|---|---|---|---|
| Protéger la concentration | Minuteur du système | Nombre de séances achevées | Plus de séances ne signifie pas un meilleur code |
| Apprendre C# | Journal d’expériences | Question, résultat, explication personnelle | Le nombre de pages ne mesure pas la compréhension |
| Fluidifier le travail d’équipe | Tableau avec limite de WIP | Ancienneté des tâches et blocages | Une personne bloquée n’est pas un « développeur lent » |
| Modifier sans risque | Test et petit commit | Délai du retour et possibilité de revenir en arrière | Le nombre de commits ne mesure pas la productivité |
Plan de départ
Sept jours pour apprendre davantage sans sacrifier vos soirées
- Jour 1Lancez une application console vide et dessinez le cadre.
- Jour 2Ajoutez Position, Direction et le déplacement d’un caractère.
- Jour 3Ajoutez la collection du corps et une gestion correcte de la queue.
- Jour 4Ajoutez un point, la croissance et le tirage aléatoire d’une case libre.
- Jour 5Séparez Update et Render ; nommez les responsabilités.
- Jour 6Écrivez trois tests des règles sans lancer la console.
- Jour 7Expliquez le projet avec vos mots et supprimez le code inutile.
Découvrez maintenant votre profil
Ne cherchez pas la méthode parfaite. Trouvez un fonctionnement que vous pouvez répéter.
Le questionnaire ci-dessous ne juge pas votre valeur de développeur. Il identifie votre manière habituelle d’aborder l’incertitude : par les repères, l’expérience, les relations ou le rythme. Après confirmation de votre e-mail, vous recevrez votre point fort, un signal à surveiller et une expérience de sept jours. L’adresse sert à la vérification et à l’envoi du résultat.