Le ZdS est-il déjà mort ?

gasche, mardi 04 septembre 2018 à 13h49
Modifié

Du côté des sceptiques, on peut quand même remarquer que beaucoup de méthodes de travail en programmation font plus de sens quand on a déjà été confronté, dans sa pratique, aux problèmes qu’elles attaquent. Quand on commence tout juste, on ne ressent pas le besoin d’un outil de gestion de version, on travaille dans un fichier, éventuellement on fait des copies (code_1, code_2 etc.) quand on veut des sauvegardes. Pareil pour le build system, on peut appeler le compilateur/l’interpréteur à la main au début, etc. Les tests unitaires, on comprend vraiment l’intérêt quand on voit sa première régression dans un projet, au début on fait juste des tests sur le moment et on les efface.

Du coup, montrer tout ça à quelqu’un qui vient tout juste de programmer, il y a un risque de le dérouter avec ce protocole et cette complexité dont il ne voit pas l’intérêt. J’aurais plutôt tendance à apprendre aux gens le minimum pour être productifs pour faire de petites expériences, coder un vrai petit projet de leur côté, et ensuite dans un second temps introduire plus d’outils et de méthodes. Tout cela peut se faire au sein d’un même cours (avec un chapitre "vrai projet" au milieu, guidé ou non), mais c’est aussi naturel de séparer en plusieurs cours.

(Pour l’algorithmique aussi je suis personnellement de l’avis que ça vient plus naturellement après une pratique basique de la programmation, et que ça peut se faire en donnant des exemples dans plusieurs langages de programmation différents, en évitant le pseucode qui ne s’exécute pas.)

04/09/18 à 13h49
Modifié

+8 -0

unidan, mardi 04 septembre 2018 à 14h00

Au risque de paraphraser gasche, je rajouterai que le problème des cours considérés peut être trop théorique vient peut être aussi de projets trop ambitieux par rapport au cours.

04/09/18 à 14h00

+1 -0

nohar, mardi 04 septembre 2018 à 15h44
Modifié

Je ne vois pas ce qu’il y a de particulièrement ambitieux ou complexe, à partir du moment où le lecteur a compris comment importer un module et écrire une fonction, à lui présenter un exercice sous la forme d’un énoncé accompagné d’une dizaine de tests que sa fonction devrait passer avec succès…

Encore une fois, je précise bien que ces trucs là devraient venir au compte-goutte dans un tutoriel (ou un parcours, ou ce que vous voulez), mais toujours est-il que le lecteur devrait être guidé.

Par exemple, je trouverais absurde de parler de métaclasses avant que le lecteur sache écrire un test : la première notion ne servira probablement jamais au lecteur dans toute sa vie (ou alors une fois à la rigueur, dans quelques années, ce qui lui imposera de revenir de toute façon sur un cours et la doc), pourtant elle a toute sa place dans un cours de Python, là où la seconde lui évite de devoir se palucher la console Python en retapant en entier son code de test à chaque fois qu’il aura fait une modification… À l’inverse, il est inconcevable de lui demander d’écrire un test s’il ne sait pas ce qu’est un module ni une fonction.

À partir de là, ces deux apprentissages doivent se faire en même temps, en construisant sur une notion de l’un pour mieux aborder la suite de l’autre. Est-ce vraiment si ambitieux que ça de vouloir parler des choses dans un ordre de complexité et de spécialisation croissantes ?

PS:

À mes yeux, un débutant qui sait :

écrire du code uniquement procédural avec les conteneurs et les types builtins de python,
écrire des fonctions de test pour s’assurer que son code fonctionne, et dénicher plus facilement les bugs le cas échéant,
utiliser pip pour installer des bibliothèques qui font le café et les chocapics à sa place,

A bien plus de pouvoir et de chances de s’amuser et de réussir ce qu’il entreprend qu’un "moins débutant" qui :

Sait écrire des arborescences de classes qui héritent les unes des autres,
Réinvente la roue parce qu’il n’a pas le réflexe de chercher un paquet qui lui simplifie la vie,
Se paume avec des print et des messages de debug pour comprendre ce qui ne fonctionne pas dans son projet.

Au bout d’un moment, même si je suis d’une génération qui a appris à programmer longtemps avant que GitHub n’existe ou que le TDD ne soit une mode, je pense qu’il y a des leçons à en tirer et des choses qu’on gagnerait à apprendre à faire correctement dès le début.