Un tutoriel pour débutant doit-il présenter les outils présents dans un workflow de développement classique ?

Salut,

@nohar a lancer la réflexion sur le style de rédaction à avoir pour être plus pédagogique auprès d’un débutant dans ce sujet. La conversation étant hors propos par rapport au topic, en voici un tout neuf pour en discuter

L’idée est d’inculquer les bonnes pratiques, qui ne sont pas forcément liées au langage, directement dans le tutoriel pour débutant, qui est centré autour d’un langage (ou une technologie de développement), notamment les outils permettant la qualité, à savoir :

• le versionnement (git)
• la documentation
• le test
• le déploiement

Bonne discussion

Pour ma part, comme je l’ai déjà exprimé, je pense qu’exposer un workflow complet est plutôt l’objectif d’un tutoriel "par l’exemple" qui me semble bien distinct du tutoriel d’introduction au langage

Je suis un peu dubitatif pour git et pour le déploiement ; par contre, je suis convaincu qu’un chapitre/une section sur la documentation est une grande plus-value, de même que pour les tests.

Plop !

Alors d’abord, il faut bien voir que c’est surtout une idée en l’air que j’ai lancée comme ça pour voir jusqu’où elle irait.

Pour ce qui est du packaging (plus que du déploiement) et du versionnement, on peut en effet considérer que ce sont des sujets avancés, et à la réflexion ça ne devrait probablement pas venir dans un tuto pour débuter.

En fait, pour le packaging, j’ai été influencé par Rust dont l’outil standard rend ça trivial, mais avant de chercher à packager son code, encore faut-il savoir le documenter et le tester. De même, il y a des technos dans lesquelles la distribution du code est sujette à caution : typiquement, à ma connaissance, il n’existe aucun moyen propre de déployer un soft en python sous Windows de nos jours.

En revanche, apprendre à tester son code et à le documenter me semblent importants, notamment parce que ce sont des guidelines simples et des habitudes à prendre qui permettent d’économiser pas mal de temps et d’énergie.

Ah, si c’est le packaging l’objectif, ça me semble en effet une très bonne idée¹.

@nohar en fait je pense que ces activités annexes (mais au combien essentiels) dans l’activité du codage n’ont pas une réponse toute simple pour qu’on généralise leur apprentissage à tous les langages.

Et pour le versionnage, à priori c’est tellement indépendant du langage qu’une référence doit être indiquée mais c’est à un autre tutoriel de s’en charger. En parlant de git / svn / mercurial / autres.

Pour l’indentation, la doc et le packaging, la décision dépend je pense du langage. Certains langages prennent en considération ces sujets de base. Dans ce cas avoir un chapitre dédié à la question de comment documenter ou packager son programme avec les outils fournis avec le langage (comme Rust) cela fait sens.

Si c’est pour aborder des outils plus génériques qui comblent un manque du langage comme Doxygen / Sphinx pour le C et C++, autant le faire à part. Il n’y a rien à gagner à faire des chapitres redondants à ce sujet et le lien avec le langage enseigné sera trop faible pour que ce soit pertinent.

Je remets ce message de nohar ici parce qu’il représente un genre de rêve éveillé pour moi :

J’aimerais tellement qu’un tel tuto existe. Je n’y connais rien en développement et s’il y avait un genre de "projet exemple pas à pas" qui permette d’expliquer comment tout ça fonctionne, je me jetterais dessus immédiatement.

En fait, j’apprendrais volontiers le langage choisi par l’auteur rien que pour ça.

Le problème de ce genre de discussion est qu’il n’y a pas une façon unique de définir ce qu’est un "débutant", et choisir quels sont les objectifs que l’on veut atteindre dans un cours. En partant de là, mettre ou ne pas mettre certaines choses sera toujours valide, selon les choix que l’on fait.

En particulier, savoir si on veut faire un cours pour apprendre la syntaxe d’un langage, ou un cours pour apprendre a programmer en utilisant un langage.

Et quand on voit les débutants sur les forums, ils se posent aussi la question de l’utilité des fonctions (pourquoi on ne met pas tout le code dans main) et encore plus des classes (ca sert à quoi la POO ?).

Si on estime que quelque chose a sa place dans un cours et qu’on vise un public qui ne connait pas déjà l’intérêt de la chose, c’est au cours de montrer justement l’intérêt. Que ce soit les fonctions, les classes, les tests, la gestion de version, etc.

Certains vont avoir peur des cours trop gros et vont préférer s’orienter vers des cours de petites tailles. Et pour eux, séparer les notions dans plusieurs cours seront mieux.

Certains vont s’amuser a suivre pleins de liens, pleins d’articles, sans se focaliser sur un cours (au risque d’avoir un apprentissage fragmenté).

D’autres vont préférer avoir un cours unique et n’iront pas voir les liens externes. (Combien de fois je vois des débutants réfuser d’aller lire mon tuto sur l’installation de Qt, alors qu’ils en ont besoin dès le début du cours C++)

Quelque soit le choix que tu fais, ça ne pourra pas convenir a tout le monde.

Malheureusement, tu vas probablement vite voir que ce n’est pas si simple que ça. Parce que sois tu ajoutes une nouvelle notion sans modifier le reste et tu auras l’impression de perdre la cohérence pédagogique. Sois tu réécris… et tu n’auras pas fini ton cours C++ dans 4 ans…

Un exemple concrèt. Si tu veux ajouter les tests dans ton cours. Tu vas par exemple parler des tests unitaires, de assert et la programmation par contrat.

Ou alors, tu vas te dire que les tests, ce n’est pas quelque chose qu’on ajoute simplement à un code existant, mais c’est une démarche qui doit être prise en compte plus en amont (testabilité et TDD). Et donc tu vas devoir réécrire un ou plusieurs chapitres, pour expliquer la démarche complète de conception d’un code testable.

Bon courage

Et je m’aperçois aussi que c’était surtout le versioning qui me dérangeait dans cette liste

Le test unitaire fait partie des compétences que le développeur doit mettre en oeuvre, et le moteur de test est lié au langage utilisé, ça ne me choque pas que ça fasse partie du cours d’introduction

L’outil de documentation pourrait être plus générique, mais dans les faits c’est quand même très lié au langage (bien qu’il le gère, je n’ai jamais croisé de doc python fait avec doxygen), et pour que les tests aient un sens il faut que la fonction soit bien définie, et donc pourquoi pas apprendre à écrire une doc au cours de cette conception de code testable

Le déploiement ça demandait un peu des connaissances systèmes et par conséquent sortait bien trop du cadre à mon goût, mais puisque tu parlais seulement du packaging (pour publier crates.io, npm ou pip par exemple c’est bien ça ?) alors effectivement ça fait partie des spécificités du langage de mon point de vue. Cependant c’est tout de même un usage un peu avancé, je ne pense pas que ce soit nécessaire dans un cours pour débutant

(pour publier crates.io, npm ou pip par exemple c’est bien ça ?)

C’est bien ça.

Je rejoins Emel plussoyant nohar sur le sujet mais plutôt sur une constatation personnelle : on trouve des cours s’adressant à des débutants (modulo la définition de débutant) qui s’arrêtent généralement sans évoquer tests, packaging ou bibliothèques majeures/l’écosystème courant du langage voire même les bonnes pratiques générales au langage.

Débutant, on se retrouve ainsi en ayant fini le tuto sans savoir que ces notions existent à moins de creuser au hasard ou questionner des développeurs chevronnés… On n’a aucune piste sur comment aller plus loin, sur comment trouver un tuto adapté au niveau de "débutantisme" auquel on a été laissé à la sortie du 1er tutoriel (1er réflex de recherche pour aller plus loin pour ma part) et si jamais on trouvait (pas trouvé pour ma part) : aucune garantie que ce nouveau tuto aborderait ces points, les considérant peut-être comme des acquis évidents. J’ai noté que dans plusieurs langages où j’ai fait un mini-peu de veille sur les cours (PHP, JS) en vu de les aborder, trouver des tuto très débutant, c’est simple, très avancés sur un point/une techno, c’est simple également, en revanche il n’y a rien du tout sur le fossé béant qui s’ouvre entre les deux.

C’est pourquoi je rejoins Emel sur le simple fait qu’un tutoriel qui va plus loin qu’une introduction au langage pour un débutant me semble essentiel et ce serait également un vrai point de démarcation avec bien d’autres sites proposant des tutoriels. Il embarquerait le langage, les bonnes pratiques du langage et du développement en général qu’un débutant ne connait pas, les tests, le packaging, les bibliothèques courantes/écosystème courant ne serait-ce qu’à titre informatif et de recherche personnelle. Le tuto peut renvoyer vers des ressources le cas échéant comme un le GitBook pour un versionnage avec Git qui sait donner l’essentiel en 10min pour le nécessaire du cours comme le cours complet d’utilisation tout en étant maintenu et traduit dans moult langues. Il me semble important de guider le lecteur pour se limiter à l’essentiel pour le cours mais aussi pour lui donner l’essentiel/le nécessaire à connaître en tant que développeur plus débutant du tout. Le lecteur lira ou saura sauter/lire en diagonale s’il connait déjà.

Au final, ayant écrit cela, je ne sais pas vraiment ni exactement ce qu’il faudrait, je ne suis pas développeur et globalement très débutant en programmation mais en tant que débutant ayant débuté, je ressens le besoin qu’un tutoriel laisse à sa sortie, celui qui l’a bien suivi, suffisamment "armé" pour savoir approfondir les points qu’il a abordé tout en sachant qu’il a vraiment abordé (et pas oublié) les points dont il aura besoin pour quitter le statut de débutant.

J’espère être assez clair ^^'

Ben je crois que tout le monde ressent que ça manque mais je pense que la question c’est plus sur "est-ce qu’il ne faudrait pas l’intégrer directement au cours d’introduction ?"

ce qui veut dire que d’une part chaque cours d’introduction va devoir répéter ces choses alors que le principe est générique et pourrait avoir un cours qui lui est propre et probablement plus complet, un peu comme on a un cours d’algo séparé des cours des langages car les paradigmes sont plus globaux que leurs implémentations dans les langages. C’est d’ailleurs de ce cours qu’est parti la remarque de nohar, il pense que ce format n’est pas attrayant pour un débutant et gagnerait donc en pédagogie d’avoir tout dans un seul cours et donc la question se pose aussi pour tout ce qui est extra-programmation mais inclut dans l’écosystème

et d’autre part que le cours soit impose un choix d’outil là où bien souvent il y a plusieurs solutions possible, soit doit décrire bien plus en profondeur le principe et la partie devient très lourde (et même en imposant un choix, s’il fallait une partie sur git détaillée ça prendrait au moins un joli bouquin de 150 pages)

Après comme l’a exprimé gbdivers, y’a pas vraiment de mauvais choix là, c’est une question d’angle d’attaque du cours, c’est simplement toujours bon d’en discuter

Et bien…j’ai plutôt le sentiment que si c’est le cas, ce n’est plus un cours d’introduction et qu’en somme, un cours d’introduction à quelque chose d’aussi large qu’un langage (ce qui embarque tout ce qui lui est spécifique en terme d’écosystème, bonnes pratiques, etc.) n’est pas si pertinent. Un cours d’introduction à une technologie comme git ou un framework, oui peut-être bien mais je n’ai pas le sentiment que ça suffise pour un langage en somme.

Partant de ce constat, il y a effectivement la question de ce que doit contenir un cours type sur un langage donné et celle pour chaque langage de ce qui doit faire l’objet d’un renvoie à un autre cours ou pas (à la lecture du fil, la partie documentation avec des outils spécifiques à Python aurait tout intérêt à y être alors que ce n’est peut-être pas le cas pour C/C++ avec Doxygen). Comme l’a dit un de mes VDD, l’auteur fait également un choix de technologie/outil à utiliser dans le cours. Si l’auteur fait le choix de git et l’intègre à son cours mais que le lecteur ne souhaite pas l’utiliser (mettons par exemple qu’il utilise SVN dans une association où il est investi), si le cours lui donne le périmètre de ce dont il aura besoin fonctionnellement (commiter, comparer, etc.), à la liberté du lecteur ensuite de parcourir un cours SVN jusqu’à ces prérequis détaillés et d’adapter sa lecture du cours. Je pense qu’à minima, si la technologie proposée est accessible et multiplateforme (idéalement Libre/Open Source ?), la plupart devrait pouvoir suivre le cours (ce qui revient à éviter Visual Studio sur un cours de C++ par exemple).

C’est assez vrai, on en revient à limiter/borner l’usage fait de cette technologie à minima pour la partie abordée, ce qui éviterait 150 pages. Il ne me semble pas impensable d’intégrer la notion que le lecteur peut continuer le tutoriel après avoir lu une partie équivalente à "L’essentiel pour ce chapitre" et sauter la partie lourdement détaillée pour y revenir plus tard. J’ai souvent vu cela dans des livres pédagogique ou même ne serait-ce que de vulgarisation scientifique, j’ai le sentiment que ça fonctionne.

Oui tout à fait je suis complètement d’accord, c’est aussi pourquoi je questionne plutôt la pertinence d’un cours d’introduction pour débutant à un langage au fond.

Et dans le tuto on peut utiliser des fonctionnalités de git que le gars va pouvoir chercher longtemps avant de s’apercevoir que ça n’existe pas dans svn ^^"
Mais on y peut pas grand chose

J’aime bien le parallèle avec l’IDE, même si ce n’était pas dans les interrogations de base de nohar. C’est quelque chose de suffisamment necessaire pour que ce soit difficile de lancer un cours sans en parler, de suffisamment complexe pour qu’il faille des explications sur son utilisation et sa configuration (qui pourrait avoir son propre tuto pour une utilisation avancé), mais également quelque chose significativement différent selon le choix que l’on fait.
Pour rester dans le C++, les chapitres ne se ressembleront pas vraiment selon si on parle de Visual Studio ou QtCreator, et même en laissant VS de côté car propriétaire, entre QtCreator, Code::Block, Eclipse, Vim/plugin/CMake, un débutant à vraiment de quoi se perdre si on ne lui explique rien, et si on lui explique on ne peut pas tout mettre, donc on va forcer 1 ou 2 choix

Pour SVN c’était bien sûr humoristique et tu as bien raison. Je visais surtout à introduire le fait de décrire le périmètre voulu sur les fonctionnalités que l’on va utiliser de git dans le chapitre.

Et bien je m’aperçois que tu m’en avais donné l’idée Et je te rejoins encore là dessus. Après quelques réflexions personnelles dans mon apprentissage, je finis par me dire que commencer le temps de l’apprentissage par l’IDE le plus simple/simpliste pour diminuer le temps d’apprentissage et d’explication à faire sur l’IDE initialement me semble plus rassurant pour le débutant que le perdre dans les arcanes d’un vim rempli d’extensions ou de l’immense étendue des fonctionnalités Visual Studio au 1er lancement, quitte à un moment du cours à proposer de changer d’IDE en exposant le pourquoi du comment : il facilitera des points que l’on a étudié tout au long de la partie de cours suivie, ce qui fait une sorte de progression. Quoiqu’il en soit, ces choix sont de toute façon forcés comme tu l’indiques. Tant que l’on expose des concepts que l’utilisateur retrouvera dans un autre IDE, ça devrait éviter de trop enfermer le lecteur dans un outil particulier, une fois les mots clés et concepts en tête, la documentation de l’IDE/l’Internet devrait pouvoir prendre le relais.