Les élèves évaluent leurs productions

En informatique, il y a ceux qui codent, ceux qui testent, ceux qui maintiennent, ceux qui refactorent...

Une fois écrit, le code informatique est souvent relu par quelqu'un d'autre, une ou plusieurs fois. Il n'est donc jamais assez tôt pour se poser la question de la qualité du programme ou de l'algorithme qu'on a produit, car cela a des impacts importants dans le monde professionnel. Mais à l'école? 

Bien sûr, l'évaluation des connaissances est une évidence à l'école, mais analyser la qualité de sa propre production est déjà une démarche moins commune. Pourtant, cela apporte un vrai plus sur le plan pédagogique. Dans le cas de l'initiation à la programmation, ce n'est pas évident de le faire sur ordinateur, d'abord parce que les programmes sont souvent longs, ne tiennent pas en entier sur un écran, parce qu'il faut pouvoir le projeter devant la classe, et aussi parce que Scratch n'est pas vraiment compatible avec l'exécution pas à pas d'un code (il n'y a pas de mode debug). 

Plusieurs critères existent et sont proposés aux élèves et aux enseignants pour analyser les productions. L'intérêt de Code en Bois, c'est que l'exécution se fait au tableau devant la classe entière qui regarde (oui, cela peut être un peu stressant, mais on essaye de dédramatiser l'erreur). La rapidité, ou la lenteur d'un code, sa compréhensibilité lorsqu'on le prononce oralement, sont assez évidents à percevoir. Mais c'est encore mieux si on quantifie ces métriques. Utilisons le tableau latéral par exemple pour créer un tableau comparatif des deux ou trois variantes de programmes proposés par les élèves. On peut inclure un programme qui ne fonctionne pas, ça n'est pas grave. 

1. Le premier critère: le code est-il valide? #valide?
   A-t-on une erreur lorsqu'on l'exécute? Le robot rentre-til dans un mur? Essaye-t-il de tirer sans munition? A-t-ton oublié de passer un argument (ex: le nombre de répétitions d'une boucle)
2. Le second est tout aussi évident: le code atteint-il l'objectif? Est-il #correct? Parvient-on à trouver le trésor? A sortir du labyrinthe?
3. Un troisième critère facile à évaluer: sa #longueur. On propose de compter le nombre de lignes du programmes, en comptant toutes les lignes (on peux exclure la brique "début de programme". S'il y a des fonctions/routines séparées, on les additionne également. On va alors expliquer qu'un code court est plus facile à comprendre pour un être humain et donc plus facile de voir des erreurs dedans!
4. Le quatrième qu'on propose, est la #durée d'exécution, il est un peu plus délicat à expliquer. On compte le nombre total de briques Action qui sont exécutées, incluant les répétitions. On fait comme si chaque action prenait une seconde à être réalisée, et on mesure la durée du programme. Cela nécessite parfois de le refaire tous ensemble avec un élève qui compte à haute voix ou au tableau. La durée est très importante car en général, on n'aime pas attendre devant son ordinateur sans rien faire!
5. Un cinquième critère assez facilement approchable est la consommation de ressources: le code est-il économe (#efficacité). Notre ressource de base, ici, est le nombre de munitions utilisées symbolisé par le niveau de la batterie du robot. On peut aussi mettre un "score" de ressources différent sur chaque brique: creuser coûte beaucoup, tirer un peu, avancer et pivoter très peu.
6. A présent, on attaque des concepts moins évidents: l' #adaptabilité! C'est simple à expliquer: avant d'exécuter le programme, vous annoncez facétieusement que les élèves ont réfléchi trop longtemps et que les ennemis ont eu le temps de se déplacer! On verra bien si leur solution marche encore! On peut proposer des changements mineurs (disposition des ennemis), et des changements plus profonds (disposition du labyrinthe lui-même, orientation initiale du robot, etc). 
7. Un critère qu'on peut aussi mentionner est le critère de #terminaison. Dès lors qu'on utilise des boucles conditionnelles (tant que ceci ou cela est vrai, je répète), on prend le risque d'avoir une répétition qui potentiellement ne s'arrête jamais. C'est très embêtant dnas le monde réel, aucun robot n'y survivrait! Un code qui est certain de se terminer une fois l'objectif atteint, ou avant d'avoir épuisé toute sa batterie, c'est mieux! (voir le kit avancé). 
8. On arrive maintenant sur des concepts difficiles: en premier lieu, la #complexité! Il s'agit de la relation entre la taille du problème et la quantité de ressources qu'on va consommer pour l'atteindre. La taille du problème, c'est par exemple la longueur d'un chemin à parcourir, le nombre d'ennemis à abattre, etc. Est-ce que notre programme va y parvenir immédiatement? Ou de façon proportionnelle à la distance? Ou de façon exponentielle? C'est très important en informatique. Un bon schéma est toujours utile (le défi "mort par épuisement" est un bon support pour découvrir cette notion.
9. C'est à peu près tout ce qu'on peut faire avec Code en Bois. Dans un vrai code informatique, d'autres critères peuvent intervenir: maintenabilité, testabilité, sécurité, etc. mais on ne peut pas vraiment les utiliser dans nos ateliers. Libre à vous d'en parler à l'oral ou d'ouvrir à d'autres ressources pédagogiques (débranchées?)

Ce qui est intéressant, c'est que la plupart du temps, aucun programme n'est meilleur dans tous les critères à la fois, il faut donc faire un compromis, et expliquer dans quel cas tel ou tel programme serait vraiment meilleur? Exemple: si le robot est déjà bien usé et sa batterie presque à plat, il faut un programme court et économe! Si on écrit un code qui doit etre vérifié par un autre élève, c'est la longueur du programme qui est importante. Etc.

Le livret enseignant fourni avec nos kits EDU propose à certains moments de réaliser de telles activités d'évaluation. N'hésitez pas à utiliser toutes les ressources proposées sur le site!