La panne de ce matin était du fait de ce billet : je suis tombé dans le bug de renommage de billet… j’ai re-publié et mis à jour le lien ci-dessus.
Je n’ai hélas pas de source pour t’aider à apprendre divers paradigmes et les choisir. Peut-être que quelqu’un d’autre poura t’aider.
Java est multi-paradigme dans ses versions modernes. Il fait de manière très convaincante : procédural, impératif, orienté objet, et fonctionnel. Il y a aussi des systèmes d’ECS en Java, pour faire le lien avec le présent sujet. Pour moi c’est à nouveau devenu un langage intéressant à connaitre (je n’aurais pas dit pareil il y a 15 ans), surtout si tu es dans des cas où l’exécution sur la JVM est intéressante (cas typique : un back-end de service web).
A mon avis, c’est la seule solution pour apprendre. Et cela prend des années. C’est pas quelque chose qui suit des règles fixes. Ca dépend réellement de la compréhension qu’on a du projet (donc bien avant que le projet soit commencé et donc bien avant qu’on puisse évaluer correctement les choix de design…), des moyens qu’on dispose et disposera (par exemple, si on a une petite équipe et qu’on sait que cette équipe va grandir avec le temps, on peut choisir un design pas bon mais simple a implémenter, et le faire évoluer quand on aura plus de devs dans l’équipe), des avantages et défauts de chaque design (sur ce point, tu as des livres comme ceux de C Martin "clean code", "clean architecture", etc. ou ceux de M Fowler "Addison-Wesley Signature Series") et de choix d’entreprise sur ce qu’on veut fournir aux utilisateurs et avec quel planning.
En pratique, quand tu débutes, le mieux est simplement de suivre les principes et designs classiques, même si tu ne comprends pas leur intérêts et impacts. Juste pour apprendre.
Il ne faut pas non plus avoir peur de se tromper et recommencer. Encore et encore. Les corollaires a cela, c’est :
ne pas commencer directement par des trop gros projets, parce que c’est plus difficile de recommencer un gros projet. Faire des projets de tailles et difficultés progressives. Pour cela, n’hésite pas à découper un gros projet en petits projets autonomes (par exemple, si tu veux faire un jeu, fais d’abord un projet de moteur de rendu indépendant)
faire un design qui autorise les erreurs et les corrections facilement. Un "bon" design qui ne serait pas évolutif sera souvent un mauvais choix quand tu débutes. Parce que cela obligera a tout recommencer, plutôt que corriger.
Et donc, il ne faut pas négliger les outils et méthodes de gestion de projets. Regarde des choses comme le TDD, la CI, la méthode scrum, les outils dans GitHub (pas juste le versionning du code), l’automatisation des builds et tests, etc. C’est a dire tout ce qui simplifie l’évolution du code existant.
Le problème avec les projets "scolaires", c’est que c’est des petits projets (max quelques milliers de lignes de code), fait par 1 personne seule souvent et du "one shoot" (le projet est jeté à la poubelle à la fin, il n’y a pas de maintenance sur le long terme). Or, sur de tels projets, les erreurs de design ont peu d’impact. Les designs sont fait surtout pour les vrais projets pros (centaines de milliers de ligne, équipe de devs, maintenu sur des années). Pour apprendre le design sur des projets scolaires, il faut se forcer à les mener comme si c’était des projets pro.
En pratique, quand tu débutes, le mieux est simplement de suivre les principes et designs classiques, même si tu ne comprends pas leur intérêts et impacts. Juste pour apprendre.
Le problème avec les projets "scolaires", c’est que c’est des petits projets (max quelques milliers de lignes de code), fait par 1 personne seule souvent et du "one shoot" (le projet est jeté à la poubelle à la fin, il n’y a pas de maintenance sur le long terme). Or, sur de tels projets, les erreurs de design ont peu d’impact. Les designs sont fait surtout pour les vrais projets pros (centaines de milliers de ligne, équipe de devs, maintenu sur des années). Pour apprendre le design sur des projets scolaires, il faut se forcer à les mener comme si c’était des projets pro.
Honnêtement, ceux sont des conseils que je garde précieusement, et je suis partis aujourd’hui dans cette optique là. C’est plaisant d’avoir des retours d’expérience de gens qui sont passés par là.
Un exemple tout bête mais : même si j’ai pris l’habitude de toujours croiser plusieurs sources quand j’apprends quelque chose, pour ne pas rester focalisé sur une seule pédagogie, je me rends compte que malgré tout c’est vraiment difficile de trouver de bonnes sources fiables. Par exemple, j’ai lu plusieurs "formations/tutoriels" sur la POO, et c’est bête à dire, mais avant de lire le contenu de ce site (ZdS), je n’avais par exemple jamais entendu parlé de la notion de composition, qui pourtant est très utile à connaître je pense. L’accent est surtout mis sur l’héritage dans les différentes sources que j’ai pu lire. Un exemple parmi tant d’autres avec avec cette formation
Du coup j’imagine qu’un bon conseil qu’on peut donner à un débutant est d’apprendre en premier lieu le langage de programmation en lui-même, découvrir les notions de la POO à travers ce genre de formations, et ensuite suivre une formation ou lire un ouvrage spécifique sur la POO une fois le langage assimilé peut-être.
Merci beaucoup à tous pour le temps que vous avez pris à me répondre
Je ne peux pas te dire pour le cours de coursera et encore moins celui pour le Java. En tout cas dans le big tuto C++ ici présent (aller sur la version en béta!) on a essayé de prendre les concepts dans l’ordre et d’insister sur les choses importantes (le tout saupoudré de syntaxe C++). Je ne sais plus quel poids a été donné à la composition, mais de sûr il n’y a pas eu d’abus d’héritage, et l’héritage public a bien été employé pour modéliser du sous-typage/de la spécialisation/implémentation-au-sens-Java.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
