Ma question n'est peut-être pas assez explicite dans le titre, je vais donc la reformuler ici.
Lorsque je développe quelque chose, peu importe le langage, ou que je fais du scripting (Batch, PS...), je reste bloqué sur le même problème : Je n'ai pas toujours la logique adéquate pour répondre à la problématique donnée. Or c'est l'étape la plus cruciale avant de s'aventurer dans le développement de manière générale. Autrement dit, je n'arrive plus à décomposer un problème en algorithmes à partir du moment où ce problème devient un poil plus complexe. Cette difficulté m'impacte fortement dans mon parcours scolaire et professionnel et c'est quelque chose que je voudrais corriger.
Comment pourrais-je apprendre à penser comme un développeur, autrement dit décomposer la problématique donnée, adopter une certaine logique qui, même si elle ne répond pas à tous les cas de figures, me permettrait au moins de progresser dans le développement. Existe-t-il des cours ou d'autres supports permettant d'apprendre à adopter cette logique ?
Ceci me permettrait, en plus de m'ouvrir à d'autres compétences, de grandement avancer sur mon parcours scolaire et professionnel.
Si je manque encore de clarté, n'hésitez pas à me le dire et je développerais les points que vous avez du mal à suivre.
On ne décompose pas un problème complexe en algo, sinon l'algo est complexe et forcément, on ne s'en sort pas, on le décompose en sous-problèmes plus simples, qu'on peut décomposer à leur tour si ils sont toujours trop complexes, et pour chacun on le transforme soit en algo si y a une logique particulière, soit en traitement si on veut résoudre un problème technique (lecture de fichier, call http,..).
Quelle expérience as tu? Décomposer ton problème en sous problèmes est une première bonne étape (plutôt que de vouloir sauter sur les algos), et pour le reste je recommanderai beaucoup de pratique.
Sinon quelque chose qui m'as personnellement beaucoup aide c'est de rendre le développement ludique. Factorio par exemple est nécessite un mode de pense assez similaire et te permettra de développer ça sans te mettre la pression. (Anntention Facotio est un jeu dangereux https://www.youtube.com/watch?v=e_zqCPFOXTI)
J'ai déjà réalisé pas mal de programmes au cours de ma scolarité. Je connais l'algorithmique de base et c'est justement ce sujet que souhaiterais re-travailler : Faire des algorithmes pour décomposer le problème en sous-problèmes et ainsi de suite, adopter une certaine logique de résoudre tous ces petits problèmes et tester (selon la complexité du programme final, la phase de test peut être plus compliquée) si ce que j'ai construit tient la route. Si oui, j'adapte mon algorithme en code pour construire mon programme.
L'algorithmique n'est pas quelque chose à négliger, c'est pour moi la première étape avant de faire chaque programme.
@Play50hz : Quitte à décomposer notre problème en 16 sous-problèmes plus simples s'il le faut, l'objectif restera toujours le même : Penser à faire un algorithme qui se rapproche de la problématique avant de faire le programme dans le langage souhaité. Ce que tu dis là est un des principes clés de l'algo et au vu de ton expérience, il est très fort probable que tu en fasses à chaque fois avant de vraiment te jeter dans ton code.
@Elried : Ouaip merci, je vais garder cette piste et continuer à chercher. Elle pourra me servir pour appliquer de manière ludique un cours par exemple.
(EDIT : J'ai trouvé un cours sur OC qui pourrait peut-être me permettre de résoudre mon problème. Je reste malgré tout preneur de chacune de vos suggestions).
> L'algorithmique n'est pas quelque chose à négliger, c'est pour moi la première étape avant de faire chaque programme.
Et je pense que la se trouve peut être le problème. L'algorithmique n'est en effet pas a négliger mais cela correspond plus au "comment". Mais la première étape correspond généralement au "quoi".
Un exemple avec la robotique:
Avant de se demander comment contrôler un robot de manière optimale, il nous faut avoir définit que oui on aura besoin de le contrôler. Et avant de penser a comment je vais pouvoir le contrôler, je dois définir ce que je veux pouvoir faire avec ce robot (par exemple si je veux pouvoir interrompre un mouvement ou non).
A partir de la je commence a avoir une idée de quels composants je vais avoir besoin. Je peux ensuite définir ce que doivent faire ces composants. Et au moment ou j'ai une granularité qui me plaît, je commence a penser a comment ces composants doivent réaliser leur jobs. Et une fois que c'est fait alors je peux commencer a coder.
Sinon autre suggestion, essaie le peer programming. Assied toi avec un collègue (ou un ami ou qui tu veux) avec qui tu te sent en confiance. Puis développez un truc a deux. C'est une bonne façon de s’imprégner de la façon de penser de l'autre et d'identifier des schéma classiques de problèmes/solutions. (Après tout une grosse partie de la prog c'est d'appliquer et d'adapter des schémas relativement classiques).
La partie "avec qui tu te sens en confiance" est importante car tu dois pouvoir lui demander de t'expliquer son raisonnement et pouvoir accepter ses remarques (et lui les tiennes) ce qui n'est pas forcement facile au début.
@Play50hz : Quitte à décomposer notre problème en 16 sous-problèmes plus simples s'il le faut, l'objectif restera toujours le même : Penser à faire un algorithme qui se rapproche de la problématique avant de faire le programme dans le langage souhaité. Ce que tu dis là est un des principes clés de l'algo et au vu de ton expérience, il est très fort probable que tu en fasses à chaque fois avant de vraiment te jeter dans ton code.
Non, pas du tout, décomposer un problème et faire un algo sont 2 choses distinctes.
Pour représenter ça, une fonctionnalité se représentera par un diagramme de classe/séquence qui définiront les problématiques atomiquement (single responsability), et un algo par du pseudo-code qui définira la manière d'implémenter le comportement attendu.
En gros, un problème c'est "quoi", un algo c'est "comment".
Vous deux avez une façon de penser très similaire mais qui est complètement différente de celle que j'ai apprise sur le système scolaire classique. Je vais voir pour travailler cette façon de penser. Je résume vos deux messages ici, ce qui me permettra de savoir si, avec vos réponses, j'ai bien compris vos explications :
Le problème est représenté par la question suivante "Quoi ?", où répondre à cette question impliquerait de dé-construire le problème en sous-problèmes, les schématiser de diverses façons dans l'objectif de les comprendre.
L'algorithmique est représente par la question "Comment ?" qui se focalisera plus sur comment on peut résoudre au cas par cas ce qu'on à décomposé précédemment et imbriquer ensemble les solutions apportées pour résoudre le problème de départ.
@Play50hz et @Elried, je vous laisse confirmer ou infirmer mon résumé
C'est ça oui, pour ma part, en java je vais représenter le "quoi" par les interfaces, et construire ma fonctionnalité avec uniquement des interfaces qui interagissent entre elles, puis ensuite je vais les implémenter une par une dans des classes, avec les tests unitaires qui vont bien, le "comment".
Edit, les tests unitaires permettent aussi de valider que tu as suffisamment découpé ton problème.
Vous deux avez une façon de penser très similaire mais qui est complètement différente de celle que j'ai apprise sur le système scolaire classique.
Je sais pas quel parcours tu as suivi, mais à la fac quand j'y étais on faisait pas mal d'algo, le plus classique étant les algos de tri, mais quand on programme sauf cas très spécifique on écrit assez peu d'algo de ce style, en général ils on déjà été écrits et on réutilise ce qu'il y a dans les bibliothèques et on assemble le tout.
C'est pas forcément plus simple comme tu l'as constaté, quand un projet devient relativement gros ça demande de savoir bien organiser son projet pour pas que ça devienne trop bordélique.
Le fait de découper son code en modules, objets ou autres formes de regroupement et d'en définir des interfaces, et de faire en sorte qu'ils se comportent un peu comme des boîtes noires est une des choses qui aident bien pour ça comme le dit Play50Hz.
Il y a des bouquins qui parlent de ça, si je me rappelle bien How to Design Programs est pas mal : https://htdp.org/
> Vous deux avez une façon de penser très similaire mais qui est complètement différente de celle que j'ai apprise sur le système scolaire classique.
Je me suis retrouve plus ou moins dans le même cas que toi. C'est après être arrive dans la vie pro et en bossant sur des projets a plus grande échelle que j'ai vraiment commence a voir les choses comme ça.
Bon courage pour la suite.
Apprendre à penser comme un développeur
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
PXL Le retro gaming facile Thread sur le forum: https://openclassrooms.com/forum/sujet/retro-pxl
PXL Le retro gaming facile Thread sur le forum: https://openclassrooms.com/forum/sujet/retro-pxl
PXL Le retro gaming facile Thread sur le forum: https://openclassrooms.com/forum/sujet/retro-pxl
Blond, bouclé, toujours le sourire aux lèvres...