L’exemple paraît clair jusqu’à la page vide
Dans un exemple de cours, les données sont déjà choisies et les étapes ont un ordre. On peut suivre une boucle ou une méthode et comprendre ce qu’elle fait. Devant un nouvel énoncé, ces décisions redeviennent les miennes. Ma première session m’a fait sentir cette différence : reconnaître une solution ne signifie pas encore savoir en construire une.
Le point de départ n’était donc pas toujours la syntaxe. Il fallait comprendre ce qui entrait dans le programme, ce qui devait en sortir et les règles entre les deux. Reformuler le problème m’aidait à voir ce qui était demandé, mais aussi ce qui restait flou. Une question précise sur l’énoncé pouvait éviter beaucoup de code écrit dans la mauvaise direction.
Découper jusqu’à obtenir une étape vérifiable
Une consigne large comme « gérer un inventaire » cache plusieurs actions. Dans un exemple de travail, on pourrait commencer par représenter un objet, ajouter une quantité, puis afficher le résultat avant d’aborder les règles plus complexes. Chaque étape ajoute une question à résoudre et un résultat à examiner avant de continuer. La demande abstraite devient ainsi une progression que l’on peut suivre.
Une étape devient utile lorsqu’on peut dire ce qui montrera qu’elle fonctionne. Cela oblige à nommer un résultat plutôt qu’à seulement compter les lignes écrites. Une méthode qui produit une valeur attendue donne un point d’appui pour la suite. Si le résultat diverge, le problème reste plus facile à localiser que dans un programme construit en bloc.
Relier la notion à une question réelle
Les notions me restaient davantage lorsque je comprenais le besoin auquel elles répondaient. Parcourir une collection donne une raison à la boucle. Réutiliser une opération donne une raison à la méthode. Représenter un état donne une raison au choix des données. Ces liens ne rendent pas chaque exercice facile, mais ils donnent un sens aux outils appris en cours.
Ils permettent aussi de reconnaître une idée sous une autre forme. Deux exercices peuvent utiliser des noms très différents tout en demandant le même type de parcours ou de validation. Je cherchais moins à retenir la solution exacte qu’à comprendre son rôle. C’est ce qui rend une notion réutilisable quand l’énoncé ne ressemble plus à celui étudié ensemble.
Le débogage demande une autre sorte d’attention
Une erreur ne prouvait pas automatiquement que je n’avais pas compris le concept. Le programme pouvait suivre une condition différente de celle que j’imaginais ou recevoir une valeur inattendue. Il fallait regarder ce qu’il faisait réellement. Lire le message, reproduire le problème et observer les valeurs m’aidait à séparer l’explication du cours de mon implémentation.
Changer plusieurs lignes à la fois rendait cette lecture plus difficile : même si le résultat s’améliorait, la cause restait incertaine. Essayer une hypothèse puis vérifier son effet donne une information. Un résultat négatif peut être utile s’il élimine une piste. Cette manière d’avancer demande de la patience, mais elle évite de confondre une coïncidence avec une explication.
Garder une trace de ce qui est enfin devenu clair
Les cours donnent une progression et des contraintes. Les projets permettent de revenir sur un sujet plus longtemps, avec de nouvelles questions. Une note courte sur un blocage peut faire le lien entre les deux : ce que je croyais comprendre, ce qui se passait réellement et le détail qui a permis d’avancer. Elle devient plus utile qu’une copie de la solution seule.
Je n’ai pas terminé cette première session avec une méthode parfaite ou toutes les réponses. J’en ai surtout retiré une façon plus précise de commencer : clarifier la demande, choisir une petite étape et comparer le résultat à ce qui était attendu. Ce point de départ laisse de la place à l’erreur sans lui laisser décider de toute la suite.