Comment puis-je faire face à l'attitude de programmation cargo-culte?
J'ai des étudiants en informatique dans un cours de programmation d'introduction obligatoire qui voient un langage de programmation comme un ensemble de sorts magiques, qui doivent être lancés afin d'obtenir un certain effet (au lieu de le voir comme un moyen flexible pour exprimer leur idée de solution) .
Ils ont tendance à copier-coller du code à partir d'affectations précédentes d'aspect similaire sans tenir compte de l'essence du problème.
Existe-t-il des exercices ou des analogies pour rendre ces élèves plus confiants qu'ils peuvent et doivent comprendre la structure et la signification de chaque morceau de code qu'ils écrivent?
Vous pouvez leur présenter une série d'exercices, chacun s'appuyant sur le précédent tout en ajoutant un élément supplémentaire ou une torsion au problème, ou en étudiant le problème sous un angle différent, ce qui révèle une faiblesse de la solution précédente, nécessitant une nouvelle approche différente . Cela les oblige à réfléchir, analyser, modifier et expérimenter avec chaque solution, au lieu de simplement copier-coller un morceau de code prêt à l'emploi.
Une autre possibilité - bien que n'étant pas strictement une tâche de programmation - est de leur demander d'estimer diverses choses. Par exemple. combien d'eau coule dans le delta du Mississippi par seconde? Ces questions n'ont pas de réponse fixe, en particulier parce qu'il faut faire certaines hypothèses pour arriver à une (gamme de) valeur (s) convaincante (s). Et - bien que les réponses à bon nombre de ces réponses "classiques" puissent être recherchées sur Google - vous pouvez facilement en créer de nouvelles qui ne se trouvent (encore) nulle part sur le net.
Des exemples de ces deux types d'exercices peuvent être trouvés dans par ex. Programmation de perles par Jon Bentley. Le programmeur pragmatique a de bons défis.
Un troisième type de tâche serait de leur présenter un morceau de code avec (un ou plusieurs) bogues, qu'ils doivent trouver et corriger. Cela les oblige à nouveau à utiliser leurs compétences analytiques et à expliquer pourquoi le programme fonctionne réellement.
Mise à jour
Retour d'un commentaire de Billy ONeal:
Le problème avec la "série d'exercices" est que les étudiants qui ont un problème avec un exercice antérieur sont complètement vissés pour les exercices restants.
Vous avez raison, même si j'estime qu'il s'agit davantage du problème général que pose la difficulté du cours au bon niveau/le regroupement d'étudiants de niveau de compétence similaire. De plus, on peut organiser les élèves en petits groupes où ils doivent discuter et débattre des problèmes et des solutions, et résoudre les problèmes ensemble. Si quelqu'un ne comprend pas, les autres peuvent aider (cette configuration améliorerait également les compétences de travail d'équipe). Et si quelqu'un essaie d'être paresseux et laisse les autres faire tout le travail, il est sûrement remarqué par l'enseignant (qui est censé se promener, superviser et encadrer les élèves, ne pas jouer WoW sur son ordinateur portable dans le coin ;-)
Et on peut également ajuster les exercices pour accueillir des étudiants avec différents niveaux de compétence. Les débutants peuvent aller plus lentement, les plus expérimentés plus rapidement.
Vous vous battez contre l'équilibre des étudiants de leur besoin de se soucier de votre sujet et de leur besoin d'obtenir des notes de passage . De nombreux étudiants estiment que:
(Get it Wrong || Experiment) == (Échec de la catégorie et du temps perdu)
Dès qu'un élève sent que son temps ou sa classe est en danger, même pour un sujet intéressant, il arrête d'apprendre et passe directement à "Je m'en fiche, donne juste à l'enseignant la bonne réponse" . Vos élèves essaient de couper les coins ronds (ou du moins ils le pensent) en réfléchissant le moins possible au problème et en le piratant simplement en copiant et collant .
Voici mes suggestions sur la façon de gérer cela:
- Utilisez la méthode de Bob Ross: Prouvez-leur qu'il est à la fois possible et plus rapide de recommencer à zéro par rapport au copier-coller. Créez de nouveaux programmes sous leurs yeux pendant le cours - montrez-leur vraiment que la programmation peut être comme peindre une image.
- Fournissez des tâches qui nécessitent de la créativité. Par exemple, demandez à chaque étudiant de créer ses propres structures de données (quels sont les objets nécessaires pour créer un zoo, une animalerie, une ville, un collège, etc.) sur papier à utiliser tout au long du cours. Le devoir # 2 peut être de convertir ces structures en classes ou en objets, etc. Fondamentalement, incitez-les à penser de manière abstraite - récompensez-les pour leur créativité, puis récompensez-les pour avoir transformé leur créativité en programme informatique.
- tilisez le moins de syntaxe possible. Les trucs comme la création de classes et la syntaxe du langage sont si répandus dans l'introduction de la programmation qu'ils induisent souvent les étudiants en erreur en leur faisant croire que toute la programmation ne fait que savoir où mettre des accolades. - ils ne réalisent pas que ce qui est au milieu des accolades est là où la créativité coule. Choisissez une langue simple et fournissez des exemples de fichiers (comme un fichier de classe vide) aux élèves qui souhaitent toujours copier et coller quelque chose. Vous pouvez progressivement devenir plus strict sur la syntaxe et les devoirs compilables à mesure que le cours progresse.
Plusieurs choses qui me viennent à l'esprit:
Donnez-leur des tâches où ils doivent réellement expliquer le code que quelqu'un (vous) avez écrit. La compréhension du code précédent ou plus précisément son absence est à la fois la cause et le danger les plus importants de la programmation culte du fret. Demandez-leur d'utiliser des commentaires, ligne par ligne si nécessaire, pour expliquer votre programme en anglais simple (ou dans la langue humaine que vous utilisez).
Seulement après avoir expliqué le code, demandez-leur de le modifier afin d'apporter un certain changement. Par exemple, si vous leur avez donné une fonction de tri qui trie par ordre décroissant, demandez-leur de le faire trier par ordre croissant. Ou quelque chose de plus exigeant. Mais assurez-vous que c'est quelque chose qui nécessite compréhension du code donné.
Vous pouvez, si vous le souhaitez, mettre des oeufs de Pâques en code. Une ou deux lignes qui ne font rien d'utile ou même du tout liées au problème. Donnez-leur un indice que de telles lignes existent et accordez des points supplémentaires à ceux qui les suppriment.
Alors et seulement alors, vous pouvez leur confier une tâche pour écrire un morceau de code à partir de zéro par eux-mêmes. À ce stade, ils devraient avoir une bien meilleure compréhension de ce qu'est vraiment le code. Ils pourraient même trouver un peu plus facile de le faire eux-mêmes.
L'idée de base est que la programmation ne consiste pas seulement à écrire du code, mais aussi à le lire. La lecture du code doit également être enseignée.
Regardez-le d'une autre manière. Ce phénomène de cargaison culte est l'étape novice du modèle Dreyfus d'acquisition de compétences . Ça c'est comment qu'on apprends. Quand j'ai appris à programmer, je ne faisais que taper des pages de code à l'arrière de Compute! magazine. La répétition est la clé. Les bébés apprennent à parler en copiant les sons qu'ils entendent leurs parents. Tout ce que nous apprenons se fait par imitation. Il suffit d'apprendre à passer de l'imitation à la maîtrise.
Le problème que vous avez, c'est que vos élèves ne répètent rien, ils le copient à partir d'Internet. Il y a un avantage à cela, mais les gains sont minimes. Le fait de taper le code est ce qui m'a amené à un lieu de compréhension. J'ai commencé à voir des modèles dans ce que je tapais et j'ai acquis une compréhension de ce que je faisais.
Une option consiste à structurer votre laboratoire comme un dojo de code. Demandez aux élèves de s'associer à tour de rôle sur le même problème. Choisissez un problème qui prend environ 10 à 15 minutes à résoudre. Répétez ce problème sur plusieurs laboratoires et introduisez une nouvelle tournure au problème à mesure que la compétence de la classe augmente. Commencez peut-être le laboratoire en demandant aux élèves de regarder la programmation de la solution et demandez-leur de la répéter. Changer de paire à chaque itération.
Pour vos tests, ayez un code kata où chaque élève résout les problèmes du semestre devant le reste de la classe. Concentrez-vous non seulement sur l'exactitude, mais sur la forme et la créativité. Je pense que cela fournirait une meilleure compréhension de la façon de programmer que de donner des missions à emporter.
J'ai enseigné des cours d'introduction dans le passé et, si je me souviens bien, je regarde en arrière maintenant:
Certains étudiants pensent que la programmation est comme ça pour différentes raisons. Je me souviens une fois d'un bon garçon qui a beaucoup cultivé le fret ce que j'ai fait:
Croyant que ce n'était pas un problème isolé, mais que d'autres élèves de la même classe pourraient avoir un comportement similaire ou aborder le problème et ne pas l'exprimer, je m'adressais toujours à la classe.
Un certain temps a été consacré à expliquer certaines choses comme le déterminisme, ce qui signifiait pour eux que dans le même environnement avec les mêmes données et le même code, ils auraient les mêmes résultats (dissiper le "hasard"),
Étant donné que la résolution de problèmes dépend de ce que les actions de l'élève et de rien d'autre, l'attention devrait être accordée à la résolution du problème et non à la recherche du bon sort,
Ils sont dans un environnement éducatif, donc les problèmes sont conçus pour offrir une expérience d'apprentissage, le résultat est d'apprendre à programmer (ou dans certains cas, comme des cours pour les administrateurs système, comment les programmes fonctionnent, ce qui est différent) et non à donne moi une solution. ("Le monde n'a pas besoin d'une autre calculatrice, c'est un exercice"), donc leurs problèmes pourraient être résolus avec les matériaux disponibles (exemple: notes fournies),
Je pense que c'est dans Code Complete: "Même si vous copiez et collez, le code est à vous". Si quelqu'un l'a fait, il ne devrait pas être de style cargo. Chaque ligne devait être expliquée à moi (individuellement) ou à un autre étudiant (même) ou à la classe.
Vos élèves ont-ils début au 'niveau d'abstraction correct' au début du cours? Par exemple. un devoir qui les introduit aux principales structures de programmation comme les boucles et les conditions sans écrire une seule ligne de code?
Quand j'ai commencé la programmation, notre première tâche s'appelait ' Rick le robot '. Nous avions un morceau de papier avec une carte aérienne d'une ville avec des points intéressants, comme des banques, des épiceries, etc ... Nous avions un mec appelé 'Rick' et avions des actions comme 'faire un pas', 'regarder à gauche', "regardez à droite", "traversez la route" et nous pourrions utiliser des choses comme "répéter" et "si quelque chose, alors faire quelque chose". (Ce n'est pas 100%, car je n'ai pas pu trouver ce devoir) L'idée était que Rick ne pouvait utiliser que ce qui lui avait été donné et qu'il devait se rendre à différents endroits sur la carte.
C'était un exercice amusant et quelque chose qui vous a présenté les bases (qui sont parfois les plus difficiles à saisir pour les nouveaux arrivants). Il n'y a pas de bonne réponse à ce problème (c'est un jeu) et il n'y a pas de solutions pour copier et coller. Quelque chose comme ça pourrait également vous permettre de jouer un peu plus avec leur créativité sans les intimider avec du code.
Enfin, l'idée est de commencer avec le abstrait et de se diriger vers le concret. Ils ne peuvent pas copier coller un résumé. Ils doivent le comprendre pour résoudre un problème.
Ce que vous leur demandez de faire, c'est de démontrer l'analyse et la synthèse dans le domaine cognitif de Bloom's Taxonomy , où ils ne font actuellement que démontrer l'application.
Malheureusement, c'est une sorte de situation de type "conduire le cheval dans l'eau". L'analyse et la synthèse sont également très difficiles à faire lorsque vous avez encore du mal à comprendre. Sans la compréhension en place, les activités d'analyse et de synthèse vont agir plus comme des éliminations que des activités d'apprentissage.
Mon opinion personnelle est qu'il est normal de ne rien attendre de plus qu'une application en introduction aux cours de programmation. C'est la première fois que les étudiants sont exposés à ces concepts, c'est donc comme enseigner aux enfants à lire avant de leur demander d'écrire un essai. Ces compétences d'ordre supérieur suivront dans leurs classes ultérieures.
Avez-vous envisagé en fournissant de commencer avec du code? Quel que soit l'échafaudage simple dont l'affectation a besoin, comme une fonction principale vide (je ne sais pas quelle langue vous utilisez). Quelque chose qui compile et s'exécute et ne fait rien. Ensuite, ils peuvent commencer à ajouter leur code avec une certaine assurance qu'au moins en partie cela fonctionne.
C'est en fait assez courant dans le "monde réel"; de nombreux IDE et autres outils créent des projets vides avec des bibliothèques/modèles/fichiers de configuration typiques déjà en place.
Toute sorte de mentalité de culte du fret (y compris les cultes du fret eux-mêmes) provient d'un manque de compréhension fondamentale de la technologie impliquée.
La programmation axée sur le fret ne doit pas être considérée comme une habitude problématique, mais plutôt comme un symptôme de la confusion sous-jacente à laquelle le programmeur est confronté.
Plus important encore, l'hypothèse selon laquelle le manque de compréhension de l'étudiant n'est que la conséquence de son manque de confiance est fondamentalement erronée et ne résout pas le problème sous-jacent.
Au lieu de cela, le style de programmation copier-coller de l'étudiant devrait être un drapeau rouge vous indiquant que cet étudiant est submergé par la complexité de ce qu'il devrait faire.
Il utilise instinctivement le travail passé comme échafaudage sur lequel construire son projet actuel, essayant de composer une solution en utilisant des problèmes précédemment résolus comme blocs de construction. Nous le faisons tous dans une certaine mesure, mais la plupart d'entre nous le font en utilisant les connaissances acquises du travail passé comme blocs de construction. Cet étudiant utilise plutôt le travail lui-même, ce qui signifie qu'il ne comprend pas vraiment les blocs avec lesquels il travaille. Il a décomposé le travail autant que sa compréhension le permet, et traitant de gros blocs de code comme des unités atomiques car il ne comprend pas comment ils fonctionnent. Il sait seulement ce qu'ils font.
Envisagez d'utiliser un langage de très haut niveau qui nécessite un minimum de code passe-partout.
Pour moi, c'est souvent le code passe-partout dans les grands cadres ou les langages verbeux qui se sentent comme des sorts magiques et entrave la compréhension.
J'ai appris personnellement ML lors de mon cours d'introduction à la programmation CS. Pendant de nombreuses années, LISP a été enseigné comme introduction à la programmation au MIT. Les deux sont d'excellents choix. Certains de leurs avantages sont
- Interprète interactif. Très important, car cela permet l'exploration.
- Très succinct. Pas de passe-partout du tout. Il permet aux étudiants de se concentrer sur les idées qu'ils essaient d'exprimer.
- Relativement obscure et étrangère (au moins par rapport à Java, C ou à d'autres langages traditionnels avec lesquels les étudiants peuvent déjà avoir une certaine expérience). Oui, je le mentionne en tant que pro. Il uniformise les règles du jeu pour les étudiants, car personne n'aura probablement d'expérience préalable. Et cela rend moins probable qu'ils pourront simplement copier-coller des solutions pour faire leurs devoirs sur le Web.
Changer votre idée de projets!
Dans le monde de la programmation, nous créons rarement de nouveaux projets pour chaque solution qui se présente. La plupart du temps, nous modifions les anciens.
Changez votre idée d'un projet d'une solution pour chaque mission à une solution pour tout le semestre. Chaque affectation construit sur l'affectation précédente.
Exemple
Projet: construire un système d'ascenseur
- Devoir 1: imprimer l'étage actuel
- Affectation 2: créer les structures de données pour une classe d'ascenseurs et imprimer le sol en fonction de l'ascenseur
- Devoir 3: Créez un code qui "déplace l'ascenseur", imprimant le sol. Accepter la saisie au clavier (> saisir l'étage:)
- Tâche 4: gérer plusieurs ascenseurs
Le fait est que vous build sur l'affectation précédente au lieu de recycler les anciennes affectations pour une nouvelle tâche.
J'ai fait quelques recherches sur les problèmes des programmeurs débutants dans les années 80. D'après mon expérience avec les programmeurs débutants aujourd'hui, peu de choses ont changé. Les novices n'ont pas de modèle mental utile de ce que font réellement les ordinateurs. Ils recourent à des incantations magiques car la machine elle-même est magique.
La programmation nécessite de diviser des tâches naturellement simples en étapes anormalement petites. Étant donné que les novices ne traitent pas avec une granularité aussi fine dans la vie quotidienne, il leur est difficile de comprendre quelles devraient être les petites étapes, surtout quand on ne sait pas quelles petites étapes la machine met à disposition. Mais même s'ils parviennent à comprendre cela, ils sont alors confrontés à la syntaxe guindée et à la sémantique limitée d'un langage de programmation (un langage non naturel se faisant passer pour un langage quasi naturel) qui contrôle la machine mystère par télécommande.
Puisqu'ils ne peuvent pas faire le lien entre une solution logique au problème et la fonctionnalité de la machine, ils se concentrent sur la satisfaction des exigences de la langue. Le premier objectif est d'écrire quelque chose - n'importe quoi - qui se compile. La seconde consiste à modifier ce programme - quoi qu'il fasse réellement - pour l'empêcher de planter. Ensuite, s'ils ont le temps, l'énergie et l'intérêt, ils essaient d'obtenir que le programme produise des résultats qui ressemblent à ce que le problème requiert. En cours de route, ils peuvent accidentellement produire du code bien écrit.
Selon toute vraisemblance, les novices qui apprennent à programmer réussissent parce qu'ils ont déduit un modèle mental utile de l'ordinateur, non pas parce qu'on leur en a intentionnellement donné un et qu'il l'a internalisé.
Vous pourriez leur poser des questions sur des morceaux de code qui nécessitent des réponses écrites? Comme "Que fait ce code?" "Pourquoi le programmeur l'a-t-il résolu comme ça?" "Y a-t-il une meilleure façon?", Etc?
Cela leur permettra en fait de réfléchir au problème, ce qu'ils peuvent faire sans même toucher au code.
- Mettez-les au défi de créer les solutions les plus courtes possibles au problème.
- Récompensez les solutions les plus succinctes avec une incitation.
- Créez des exercices qui tournent entièrement autour de la refactorisation du code
- Demandez aux élèves d'échanger leurs devoirs et de les simuler pour l'efficacité et la propreté du code, et utilisez certains des moins efficaces comme exemples, sur un rétroprojecteur.
Semblable à l'idée de JoelFans, demandez-leur de faire les affectations initiales sur papier en utilisant un pseudo-code (langage) que vous créez. Vous pouvez ajouter les structures comme bon vous semble et elles ne se soucient pas de la boîte magique.
Je vais supposer que par `` culte du fret '', vous voulez dire qu'ils insèrent des choses qui sont nécessaires, mais en réalité ne font absolument rien pour résoudre le problème.
Si tel est le cas, vous pouvez toujours ajouter un facteur de classement basé sur la concision - laisser du code inutile ou redondant dans votre programme pose des problèmes à l'avenir, car il peut se casser ou le rendre plus difficile à maintenir.
Ils seraient jugés de la même manière dans un exercice d'écriture dans un cours d'anglais - personne ne veut de trucs qui se déclenchent dans une tangente aléatoire ou qui sont tout simplement décousus sans en venir au fait.
Quand je prenais un cours d'assemblage, le professeur nous disait pour chaque exercice s'il voulait que nous écrivions le code pour la vitesse, la taille ou l'utilisation de la mémoire, et il marquait si vous n'étiez pas près d'optimiser ce qu'il demandait pour.
...
S'ils copient et collent du code à partir d'affectations similaires précédentes, et c'est en fait quelque chose pour résoudre le nouveau problème ... eh bien, c'est juste une réutilisation du code, et à moins qu'ils aient fait de mauvaises hypothèses sur la pertinence du code pour la réutilisation , Je pense qu'il est parfaitement raisonnable pour eux de le faire. (par exemple, lire un fichier, proposer une entrée ... toutes les parties modulaires qui peuvent être réutilisées. Si vous ne vouliez pas qu'elles le fassent, vous devez rendre les exercices différents.
Malheureusement, c'est ainsi que fonctionnent les cerveaux de beaucoup de gens. Allez donc dans cette compréhension qu'il y a des gens que vous ne pouvez pas "guérir" de cela. Il y a beaucoup de gens qui sont incapables de travailler au niveau de précision mentale nécessaire à la programmation. Certaines personnes ne sont tout simplement pas conçues pour cela. Je ne dis pas abandonner les étudiants - je dis ne présumez pas que vous échouez si tout le monde ne le prend pas.
Sans en savoir plus sur le contexte de la classe, je dirais me concentrer davantage avec ces élèves à problèmes sur les structures très basiques - simple if/thens, boucles, etc. Routines simples pour imprimer des nombres impairs, chaque dixième nombre, etc. Pas plus de 10 lignes de code chacune. S'ils sont de la "pensée magique", ils n'ont évidemment pas encore maîtrisé ces bases. Demandez-leur de faire différentes routines simples jusqu'à ce qu'ils comprennent ce qui se passe. Quelqu'un d'autre a mentionné avoir écrit le code sur papier - je pense que ce serait aussi un excellent moyen de faire ces routines simples.
Vous pourriez également envisager de leur faire apprendre le diagramme de flux. Pour certaines personnes, être en mesure de voir le flux d'un algorithme, puis comment celui-ci se connecte au code, peut être utile pour eux de connecter le code au flux.
Juste une petite suggestion. Chaque fois que j'ai un problème de programmation qui doit être résolu ou débogué, j'aime regarder mon code et "jouer à l'ordinateur" où, dans ma tête, je garde une trace des variables et de leurs valeurs et de ce que je m'attends à ce qu'elles soient lorsque chaque ligne est exécutée . Donc, si j'ai copié du code quelque part, à moins qu'il ne soit complet en lui-même et que je doive simplement le référencer, j'aime aller ligne par ligne pour comprendre exactement ce qui se passe. Jouant essentiellement à l'ordinateur. Le débogueur VBA facilite essentiellement cette tâche, mais faire en sorte que vos élèves le fassent sur papier pourrait leur donner des fondamentaux comme. Que fait réellement cette ligne?
J'ai enseigné la programmation d'introduction au niveau collégial. C'était un cours de pain et de beurre, tous les professeurs l'ont fait, et je pense que nous l'avons très bien fait. Nous avons suivi un texte commun et passé des examens communs, mais nous avions chacun notre propre méthode de classe qui fonctionnait. Cela fait longtemps, mais de temps en temps je donne des cours particuliers à un enfant en programmation, et l'image est à peu près la même.
Ma façon de procéder est de commencer par le bas, le plus concrètement possible. Ce que les élèves savent, c'est une structure. Ils ont déjà beaucoup de concepts. Je construis d'autres concepts en plus de ceux-ci, et j'élague les concepts qu'ils peuvent former et qui sont contre-productifs. En même temps, je les fais apprendre en faisant.
J'avais construit un petit ordinateur avec une puce Intel 8008, de l'EPROM et quelques circuits. Je l'avais programmé pour jouer un petit duo lorsque la puce d'E/S était connectée à quelques haut-parleurs. J'expliquerais comment le petit programme fonctionnait, avec une boucle interne pour décompter un compteur. Cela constituerait un retard. Ensuite, il basculerait le bit de sortie et recommencerait. Il ferait cela pendant un certain temps, puis passerait à un autre délai, donnant un autre pitch, et ainsi de suite. La puce de mémoire avait un petit minuteur, et si je glissais un câble de condensateur sous l'une des entrées du minuteur, le programme s'exécuterait veeeeery lentement. La classe pouvait entendre les haut-parleurs cliquer, cliquer, cliquer ... Je voulais que la classe comprenne que l'ordinateur faisant des choses très simples une étape à la fois. Ensuite, je déconnectais le câble du condensateur et la "musique" éclatait. (applaudissements)
Ensuite, j'avais construit un simulateur pour un ordinateur décimal très simple, ayant 1000 emplacements de mémoire, chacun contenant un nombre décimal signé à 4 chiffres. Il avait des opcodes très simples comme "ajouter à l'accumulateur", "sauter si négatif", etc. Je leur demanderais d'écrire de petits programmes dans ce "langage machine", comme l'ajout de deux nombres ou l'ajout d'une liste de nombres. Ensuite, ils pouvaient le regarder fonctionner en une seule étape, ou en maintenant la touche Entrée enfoncée pour le regarder fonctionner "rapidement".
L'objectif était de mettre en place le concept selon lequel les ordinateurs ne peuvent effectuer qu'un très petit nombre d'opérations de base différentes, et ils les effectuent une par une. C'est pour contrer l'impression qu'ils ont que les ordinateurs sont compliqués, et qu'ils font tout en même temps, et lisent votre esprit dans le marché.
De là, nous sommes passés à la programmation dans un "vrai" langage (BASIC :), en commençant par des programmes très simples mais intéressants, en passant par les conditions, les boucles, les tableaux, les fichiers, les fusions, etc. Le but était de mettre en place un ensemble de compétences suffisant pour qu'ils puissent entreprendre un projet de leur choix, car c'est la seule chose qui rend la programmation intéressante - l'utilisation à laquelle vous pouvez la mettre. Je jetais des idées de projets, puis ils les prenaient à partir de là. Je demanderais des idées écrites, puis des rapports d'étape, pour les empêcher de reporter à la dernière minute, puis de paniquer. Je pense que les projets étaient la meilleure partie, car ils apprenaient par leur propre pouvoir.
Cette mise à la terre initiale dans une compréhension très concrète de ce que font les ordinateurs a rendu beaucoup plus facile l'enseignement de concepts ultérieurs qui seraient autrement de vrais ralentisseurs, comme des tableaux ou (dans un cours ultérieur) des pointeurs. Nous avons tendance à glorifier le concept de "l'abstraction" en tant que chose merveilleuse, mais il doit être construit sur des fondations en béton, pas sur l'air.
[~ # ~] un [~ # ~] programmeur autodidacte je crois animation pour être le plus difficile en termes de savoir ce que fait le code. Lorsqu'un programme contient des algorithmes et des transformations mathématiques effectuant des manipulations abstraites, la seule façon de comprendre ce que font les mathématiques à un moment donné (sauf si vous êtes un génie) nécessite de comprendre l'exécution du code lui-même.
Corrigez-moi si mon idée naïve est incorrecte. Ce que vous voulez faire, c'est not empêcher vos élèves d'utiliser des "modèles de conception", mais trouver un moyen de s'assurer qu'ils comprennent ce qu'ils sont le CnP? Mettez ensuite vos élèves au défi de manipuler une animation. Pour modifier la sortie d'une animation, il est nécessaire de comprendre ce qui se passe à chaque étape. Pour votre préoccupation déclarée, j'imagine qu'un projet d'animation bien conçu se manifestera de manière évidente lorsqu'un étudiant "l'obtient" - lorsqu'il a réalisé une transformation que vous n'attendiez pas ou n'a pas modifié certaines variables interdépendantes connexes.
Sans connaître les limites et les objectifs pédagogiques sous lesquels vous travaillez, je ne peux pas dire que l'animation est la réponse complète. Tout un programme d'animations en dehors du métier d'animation est, je devrais hasarder de deviner, hors de question. Quelques projets peuvent néanmoins aboutir à quelque chose d'artistique et de merveilleux, ce qui n'est pas mauvais.
Sur une autre note, j'ai lu un article de journal (oui, du papier!) Sur un lycée Jeux olympiques de codage - wot-wot - compétition pour programmeurs pré-universitaires. La description de leurs défis était l'articulation la plus claire du codage pur dont je me souvienne avoir lu. Les concurrents sont jugés les uns par rapport aux autres et selon les normes de bonnes pratiques. Pour ces compétitions, les étudiants doivent tous deux planifier leur solution et coder à la main le "modèle de conception" élémentaire que le problème nécessite pour terminer dans les délais. Ainsi, la solution à votre préoccupation concernant la programmation CnP est de tester si les étudiants peuvent écrire les mêmes "morceaux de code" qu'ils sont CnP'n!
Je suis sûr que c'était dans le NY Times. Une recherche rapide ne l'a pas trouvé. Un exemple similaire est Concours international de programmation collégiale d'ACM. Ce concours met l'accent sur une programmation rapide: "La programmation rapide comme l'éclair dans une compétition par équipe est une compétence résolument excentrique, pas exactement un grand nombre de demandeurs d'emploi placerait au sommet d'un CV." Ainsi, je recommanderais l'abstraction des problèmes du monde réel est la réponse.
Aussi,
Idéalement, dans la première conférence, commencez-les par quelque chose de complètement abstrait: demandez-leur (en groupe, avec vous en tant que chef) d'écrire les instructions sur la façon de faire l'épicerie à partir d'une liste et de décomposer progressivement les instructions de haut niveau jusqu'à ce qu'ils atteignent l'illumination.
Il est utile de leur dire que ces instructions vont être suivies littéralement par un robot, qui ne sait pas déduire les choses. Cela doit être une activité très pratique où vous êtes chargé de les guider.
Alistair Cockburn parle du concept de Shu-Ha-Ri et de son application à la programmation, http://alistair.cockburn.us/Shu+Ha+Ri . Je pense qu'il peut être important de garder à l'esprit où se trouvent vos élèves dans ce continuum. Tout d'abord, cela aidera à atténuer une partie de votre frustration. Copier/imiter est une réponse très naturelle et un mode accepté lorsque vous commencez à apprendre quelque chose. Deuxièmement, cela peut vous aider à vous faire une idée de la marche à suivre. Par exemple, vous voudrez peut-être envisager de choisir un problème qui peut être résolu de plusieurs manières (boucles vs récursivité, console vs web/gui), puis demandez-leur explicitement de le résoudre d'abord dans un sens, puis dans un autre - bonus qu'ils peuvent apprendre sur la réutilisation de code légitime, la segmentation, la création de bibliothèques réutilisables, etc.
Un autre moyen réussi que j'ai vu utilisé est d'avoir une série de projets qui s'appuient les uns sur les autres, rendant une version de travail par défaut disponible à chaque étape après la remise des affectations pour empêcher les gens de prendre du retard. Chaque étape du processus devrait introduire quelque chose de nouveau. Je vous accorde que cela peut être plus facile à faire dans une classe de conception qu'une classe de programmation, mais cela devrait toujours être faisable. Une bonne chose à ce sujet est que vous leur donnez explicitement une bonne implémentation (espérons-le) à comparer avec la leur à chaque étape. Exposez cette comparaison comme une tâche, c'est-à-dire faites un examen de mini-code de leur propre code par rapport à leurs efforts. Vous voudrez peut-être en faire l'une des nombreuses options de crédit supplémentaires.
Bien que je ne sois généralement pas très intéressé par les "commentaires", vous souhaiterez peut-être faire de la documentation du code l'un des éléments de note. Demandez-leur de produire un document "Théorie de fonctionnement" pour chaque projet qui décrit leur approche, comment chaque composant s'intègre et comment ils résolvent ensemble le problème. Normalement, je voudrais que le code fasse une grande partie de cela tout seul, mais cela les inciterait à mettre leurs bouchons de réflexion et à le mettre sur papier.
Enfin, vous voudrez peut-être faire preuve de créativité et demander à vos élèves de réviser le code de l'autre et de lui donner une évaluation. Mettez la pression des pairs à votre service. Autorisez cela à faire partie de la note ou du crédit supplémentaire pour le code (et les documents) les mieux notés.
Enseignez à la classe en utilisant un langage de programmation techniquement bon mais si obscur qu'ils ne pourront pas trouver de code existant à copier.
Vous pouvez également les traiter à la dure.
Trouvez un moyen de leur faire un copier-coller. Je n'ai pas d'exemple précis, mais si vous créez un premier exercice dont la solution, si elle est collée dans un deuxième exercice similaire, amène les étudiants du cargo dans un bug très long et douloureux "instabilité instable" ou "corruption de données silencieuse". Pendant ce temps, une réflexion "non cargo-culte" de 2 mn aurait apporté une solution évidente même au pire élève (s'il n'avait pas vu la première solution d'exercice). Ensuite, il est peut-être possible qu'ils apprennent la leçon et réfléchissent à deux fois avant de copier le code dans le troisième exercice.
Je voudrais signaler le problème de l'enseignant, avec une vision intuitive.
Un acteur (cinéma) est quelqu'un avec une image bancable (capable de le vendre), une star pour tout le monde.
Un acteur (théâtre) est quelqu'un qui a la capacité de se mettre dans les rôles de l'auteur, d'ombrer son ego derrière ses connaissances pour se donner une part.
Pour enrichir (avec la science et les connaissances) vos élèves, vous devez vivre en cours comme un acteur de théâtre.
Vous avez besoin, au-delà d'une solide connaissance technique, de donner quelque chose de vous: vous n'êtes pas un diplômé/technicien connaissant tout le sujet informatique lié à la phrase de livraison comme un livre,
... mais un homme d'expérience (un début possible d'intuition) avec un panel de cours et d'exercices partageant expérience et savoir vivre.
Ensuite, vous pouvez demander à vos élèves d'avoir la même approche: ne pas acheter de connaissances/notes, mais assimiler une langue et des capacités pour la maîtriser, faire quelque chose que vous ne pouvez pas copier/passer, mais qui lie l'esprit au travail.
Tous les conseils donnés ci-dessus sont inutiles ou non: êtes-vous capable d'avoir confiance en vous, avez-vous la maîtrise du gourou/théâtre. Pour atteindre ce niveau, les cours de théâtre peuvent vous donner le cliquetis/l'étincelle. Une bonne façon de "se connaître" et non de manière procédurale.
Le problème: c'est à vous de décider: vous devez quitter votre siège, avoir conscience de votre corps et de votre espace et d'autres techniques, vouloir aller plus loin dans le langage (ce qui n'est plus des mots, des méthodes)
... un "travail" pour toute votre vie, avec des compétences de créativité. ... ou pas: tout ce "travail" pour 5% de mon travail? (alors, demandez-vous ce qu'est "être vivant") ...
En espérant qu'il soit lisible en anglais,
Claude
Ne leur donnez jamais des affectations de même son.
Ou, plus fou, apprenez-les TDD depuis le début. Il pousse à écrire (pas à copier, à écrire) beaucoup de code (à savoir des tests) qui aide réellement à formuler le problème qui est résolu.
Lorsque j'étais dans un cours de programmation d'introduction, l'instructeur a demandé à tout le monde d'écrire un algorithme en anglais, de l'imprimer et de le rendre avant de commencer à écrire du code. Ensuite, nous devions mettre beaucoup de commentaires tels que Créer des variables, Obtenir les entrées de l'utilisateur, Effectuer des calculs, Imprimer la sortie, etc. J'ai été ancré plusieurs fois pour ne pas avoir suffisamment de commentaires quand je pensais qu'il y en avait beaucoup, alors j'ai commencé à ajouter plus. Cela m'a obligé à réfléchir à ce que je faisais et à écrire les solutions et à continuer à traduire entre l'anglais et Java.
Quelque chose que j'ai trouvé très utile pour les gens de ma classe, c'est d'écrire un petit projet sur eux, sur un sujet qu'ils peuvent choisir eux-mêmes.
Quand j'ai commencé à programmer, c'était difficile pour moi aussi, et j'ai copié beaucoup en classe. Puis à la maison, j'ai commencé à faire des petits jeux, car je veux devenir programmeur de jeux, et je les ai trouvés beaucoup plus faciles à faire. Même s'ils étaient beaucoup plus durs que ce que nous avons vu en classe. Juste parce que ça m'intéressait.
Quelques autres personnes de ma classe sont passées de 40 à 50% à leurs examens à 90 à 100%, car elles ont fait exactement la même chose.
Je doute que ce comportement soit dû à la croyance que les programmes sont des sorts magiques - plus probablement c'est la paresse et le manque de motivation.
Je pense donc que votre travail en tant qu'enseignant est de motiver vos élèves - aucun élève véritablement motivé ne copiera et ne collera une solution (c'est uniquement pour les programmeurs qui travaillent avec des délais et des résultats à respecter ...)
Enseignez les sous-programmes. Demandez-leur de prendre le code qu'ils récupèrent des affectations précédentes et de le transformer en sous-programme. Enseignez-leur la documentation des fonctions pour les aider à comprendre ce que le sous-programme fait réellement.
Demandez-leur de faire le devoir devant vous dans la salle de classe sans accès à Internet (demandez à l'école de le couper, de ne pas utiliser le téléphone également pendant le cours). Faites-le au moins pour les tests. Il n'y a aucune raison qu'ils utilisent Internet pour des expériences de programmation de base. Le livre devrait être une ressource suffisante pour les exercices d'introduction. Autorisez l'utilisation d'Internet une fois que vous êtes dans une classe avancée et ils ont déjà appris à penser.
J'ai écrit un article de blog à ce sujet, du point de vue de ce que nous, les programmeurs qui écrivent des tuts, devrions faire différemment pour aider à atténuer ce problème chez les programmeurs professionnels juniors (j'espère!), Et en partie le blâmer sur nous. Je pense que la façon dont nous créons du matériel pour eux est une partie essentielle de ce problème. Quelques suggestions que je fais:
Divisez votre code en petites parties incomplètes: ce n'est vraiment qu'une chose mécanique, et peut-être un peu une suggestion "controversée". Ne postez pas de gros morceaux de code de travail dans votre didacticiel. Faites-les travailler pour assembler le tout, espérons-le, tout en lisant et en comprenant chaque partie. Ce n'est pas facile - il y a déjà tellement de tutoriels avec du code cassé, je peux voir cela frustrant pour un apprenant. Mais je crois vraiment que s'ils sont au niveau où ils lisent "Comment créer un formulaire de connexion", ils doivent vraiment passer par chaque étape par eux-mêmes (et créer un lien vers Stackoverflow avec des questions s'ils ne peuvent pas le faire fonctionner)
Expliquez le problème avant d'y répondre: Une technique courante en rédaction de tutoriel consiste à publier un bloc de code, puis à le parcourir ligne par ligne. Je dirais que nous devrions dire ce que nous devons ajouter ET POURQUOI, puis l'ajouter, puis répéter. Donc, "Nous devrons créer un formulaire, avec une méthode de publication, un élément pour contenir notre nom d'utilisateur et notre mot de passe, et un bouton pour soumettre", puis l'écrire. Savoir ce que vous regardez AVANT de le voir est une méthode d'enseignement beaucoup plus efficace.
Enseignez le débogage, pas le codage: dans un récent post sur ce site, j'ai essayé (avec un peu de succès avec un peu de chance) une nouvelle technique - j'ai posté un tas de code cassé, puis j'ai appris à comprendre ce qui n'allait pas. Beaucoup trop de nouveaux programmeurs ne comprennent même pas la définition de var_dump (); c'est la cause numéro un de la plupart des nouvelles questions de programmeur, à mon humble avis.
Allez plus loin, pas plus loin: Anthony Ferrara a commencé une brillante série de vidéos de programmation à Programming with Anthony. La raison pour laquelle je les aime tellement, c'est qu'ils choisissent un sujet spécifique et l'expliquent vraiment "profondément". Au lieu d'essayer de créer un "Social Widget Scroller" complet, il explique simplement les tableaux jusqu'au niveau de la mémoire. Au lieu d'essayer de couvrir de vastes sujets, choisissez quelque chose de petit et expliquez-le soigneusement et patiemment.
Apprenez à signaler le bogue: pas pour notre commodité. Nous savons tous combien de fois nous avons trouvé quelque chose en écrivant le problème sur un forum. La raison est simple - quand vous devez expliquer quelque chose, vous devez y penser. Ne leur apprenez pas à "rechercher sur Google" - apprenez-leur à s'asseoir et à y réfléchir, ou écrivez-leur une lettre sur le problème.
Texte intégral: http://codebyjeff.com/blog/2013/05/death-to-teaching-cargo-programming
1) Apprenez-leur l'histoire des ordinateurs, la programmation. 2) Apprenez comment fonctionnent les différents langages de programmation. 3) Enseignez ce qu'est une bonne programmation et de bonnes pratiques de programmation. 4) Apprenez-leur à analyser un problème, à trouver une solution, puis à commencer à coder.