Difficulté croissante : dans un même projet ou différents projets ?

Bonjour,

Je retranscris une question que j’ai posée sur le Discord non-officiel pour pouvoir en discuter plus confortablement. Tous les types de programmation sont concernés, mais il a bien fallu choisir un forum.

Quand on apprend à programmer, on nous dit tout le temps de commencer par des projets facile et d’augmenter progressivement en difficulté. Quel est l’intérêt par rapport à commencer par un projet difficile, mais de le découper un parties de difficulté croissante ?

Et quand on débute, on ne sait pas encore où on va bloquer, et ce qui sera compliqué pour quelqu’un, juste que ça se produira à un moment, donc même définir la difficulté des projets, c’est pas trivial. Des suggestions ?

J’ai aussi eu une réponse par @Aabu, que je copie ici

Ça me parait une question complexe. Je pense que c’est important d’avoir des projets/exercices bien calibrés pour en voir le bout et garder une certaine motivation. Découper un projet difficile en parties faciles (avant même de le réaliser) me paraît déjà difficile en soi pour un débutant.

La difficulté des projets me paraît plus facile à quantifier dans beaucoup de cas. Pas forcément par l’apprenant cependant. Tu as différents curseurs objectifs : complexité architecturale, des algorithmes, du problème en tant que tel (simulation numérique subtile par exemple, ou apprentissage profond), criticité de la performance, etc.

Ça permet de dire que faire un morpion, ou une calculatrice c’est plus simple que de faire un RTS 3X en 3D qui permet de jouer en réseau et avec une IA à l’état de l’art (à savoir qui commence à battre de bons humains sans tricher)

Du coup, j’en remets une couche. J’ai une éducation scientifique assez solide, donc j’ai beaucoup moins peur de devoir implémenter un modèle où il va falloir choisir comment calculer une différentielle par rapport à des trucs qui pourraient être traditionnellement vus comme plus simples (i.e. faire un front, ou gérer des connections multiples, ou mettre à jour un modèle de base de données, ou … la liste serait longue).

C’est pas du tout évident pour moi de savoir comment partitionner pour ne pas avoir l’impression de me retrouver face à une montagne. Dès que je commence quelque chose, même facile, il faut utiliser git, et un environnement virtuel, et choisir un langage/framework, et parfois choisir la bdd, etc. Et je ne sais pas trop si ça vient du fait que mes projets sont trop ambitieux pour l’état de mes connaissances et compréhension, ou si ça vient du fait que je ne les découpe pas correctement.

Un intérêt de faire plusieurs projets, c’est la gratification associée au fait de terminer. Il y a des projets qui ont beaucoup de chance et où les étapes intermédiaires sont déjà gratifiantes. Mais souvent il y a peu de moments vraiment gratifiants avant que toutes les briques puissent s’assembler avant de "faire" quelque chose. Si tu choisis tes projets un peu à l’arrache (on ne parle pas du cadre d’un cours monté par un-e enseignant-e ayant choisi un projet spécialement pour ses qualités pédagogiques), il y a plus de chance qu’il soit dans la seconde catégorie.

Dès que je commence quelque chose, même facile, il faut utiliser git, et un environnement virtuel, et choisir un langage/framework, et parfois choisir la bdd, etc. Et je ne sais pas trop si ça vient du fait que mes projets sont trop ambitieux pour l’état de mes connaissances et compréhension, ou si ça vient du fait que je ne les découpe pas correctement.

Si ces questions te semblent difficiles, c’est que tu ne t’y prends pas correctement. Choisir une BDD, c’est facile: prend la première qu’on te conseille. Choisir un langage/framework, c’est facile: prend celui qui te tombe sous la main. Faire du git, c’est facile: lit le premier tutoriel "les super-bases de github pour les nuls" que tu trouves en ligne. Tant que cette approche fonctionne, tu n’as pas besoin de rentrer dans les détails. Quand tu commences à vouloir approfondir un point ou un autre (… mais pas tous en même temps !), tu pourras revoir ce choix et en faire d’autres, revoir ton niveau d’exigence sur cette partie et/ou choisir un projet plus exigeant sur cet aspect pour mieux creuser.

Une autre façon de faire est d’essayer de contribuer à un projet existant, au lieu de tout refaire soi-même. Il y a le coût en plus de rentrer dans un système existant, mais aucune "fatigue de décision" à devoir choisir les briques. Personnellement c’est l’approche que j’utilise le plus souvent. (Et au bout d’un moment on a vu 2/3 choix dans chaque catégorie dans des projets existants, et on est assez autonome pour creuser soi-même pour des projets from scratch.)

Attention à l’abus de "c’est facile". Que ce soit utiliser Git¹, choisir un langage ou une BDD, rien n’est facile quand il s’agit de faire les choses du mieux possible. Surtout pour un débutant qui fait face à plusieurs choix, outils et techniques qu’il ne connait pas.

Mais je valide l’idée du propos : si c’est un projet pour apprendre il n’y a pas forcément de mauvais choix technique. Va sur ce que tu connais ou un environnement dans lequel tu te sens le plus à l’aise.

Et utiliser Git sur un projet perso n’a pas forcément besoin d’être une priorité. C’est une option sympa, mais tu peux aussi très bien utiliser une solution de backup toute simple si tu es tout seul et que tu ne cherches pas à automatiser des tests ou déploiements.

rien n’est facile quand il s’agit de faire les choses du mieux possible

Ce n’était peut-être pas assez clair mais justement mon propos est que quand on fait un premier projet, on peut laisser tomber l’idée de faire tout "du mieux possible", on se concentre sur le fait de s’en sortir, ou éventuellement on choisit un domaine précis où on fait le-la perfectionniste et pour le reste on fait comme ça vient.

Je suis plutôt d’accord avec l’approche de @gasche : le mieux est l’ennemi du bien et il est préférable de ne pas laisser le "mieux possible" nous paralyser.

Même le projet le plus simple en apparence (au hasard, un key/value store) peut devenir vraiment complexe et pousser à manipuler des choses compliquées au fur et à mesure que l’on itère sur des problèmes de plus en plus fins.

Le tout, c’est d’itérer justement. Faire un truc qui répond au problème de façon sommaire au départ, puis raffiner, en traitant les problèmes au fur et à mesure qu’ils (re-)viennent. Un "problème", ici, peut tout autant désigner "je ne sais pas faire ça avec git", que "le cache n’est pas invalidé au bon moment".

Au final la quantité de choses que l’on apprend d’un projet ne dépend pas tant que ça du problème lui-même que du temps que l’on passe à améliorer notre solution.

C’est pas du tout évident pour moi de savoir comment partitionner pour ne pas avoir l’impression de me retrouver face à une montagne. Dès que je commence quelque chose, même facile, il faut utiliser git, et un environnement virtuel, et choisir un langage/framework, et parfois choisir la bdd, etc. Et je ne sais pas trop si ça vient du fait que mes projets sont trop ambitieux pour l’état de mes connaissances et compréhension, ou si ça vient du fait que je ne les découpe pas correctement.

C’est un peu une redite, mais j’avais envie de développer ce que les autres ont dit avant.

Rien n’est vraiment une montagne si on prend les choses les unes après les autres, comme elles viennent. La programmation a l’avantage que de tout changer est assez peu coûteux, si ce n’est en temps. Rien n’est vraiment irréversible. Tu pars simple et adapte au fur et à mesure des besoins ; ce qui peut venir vite, mais ça reste au fur et à mesure. C’est assez peu productif de faire de la surconception au démarrage.

T’as plein d’exemples possibles. Tu prends ton langage préféré. S’il est trop lent ou inadapté, tu retrousses tes manches et tu changes. Pas agréable, mais si c’est ce qu’il faut faire, alors ça sera utile. Si stocker tes données dans un fichier texte à l’arrache devient trop limitant, tu peux partir sur du SQLite (ou un serveur de base de données, ou encore plus raffiné). Si tu penses que ton bidule gagnerait à être versionné, tu crées ton dépôt git à ce moment-là. Si tu veux le partager, tu le mets sur un service GitHub à ce moment-là, et tu trouves peut-être une licence à ton goût. Si tu découvres que tu as besoin de le déployer sur un serveur, tu te renseignes à ce moment-là sur comment faire. Si tu penses que tu dois péter toute ton architecture parce que ça ne répond pas vraiment au besoin, tu le fais à ce moment-là. Si tu découvres que tes fondamentaux dans un certain domaine semblent être bloquants, tu les consolides à ce moment-là. Tu penses qu’il te faut de l’interactivité avec JavaScript ? Tu apprends JavaScript.

C’est assez con dit comme ça, mais ça marche pas mal pour avancer dans un projet, quitte à faire des projets-jouets pour tester certaines composantes sans impact sur ton « chef-d’œuvre ».

Tiens, sur un projet perso récent, j’ai pris Python parce que c’est ce que je connais déjà, Django parce que c’est pour un site web et que je connais déjà aussi. J’ai mon IDE favori. J’ai choisi une base SQLite parce que je sais que j’ai besoin d’un bidule relationnel à terme, mais pour le démarrage, c’est déjà un peu overkill. Je sais déjà que mon schéma est pas adapté et que je vais devoir le changer, mais ça viendra en temps et en heure (j’ai un peu de saisie de données à faire avant). J’ai pris le serveur le moins cher que j’ai pu trouver et je l’ai configuré comme un gros débutant pour que ça marche (et si la sécurité pose soucis, j’y reviendrais). Le design est simpliste (mais un jour il sera mieux). Chaque chose en son temps. Mais en vrai, ce projet était surtout un prétexte pour m’exercer sur un projet Django de zéro et le déploiement, alors ça se trouve, il n’ira nulle part, qui sait ?