Forum Programmation.autre Problèmes lors de la conception / abstraction de programmes

Posté par  . Licence CC By‑SA.
2
11
sept.
2020

Bonjour à tous,

je vous écris aujourd'hui car je rencontre des difficultés dans mon travail (c'était déjà le cas lors de mes études) lors de la conception d'un programme.

J'ai tendance à penser et faire tout compliqué dès le début, le tout rendant le programme peu réutilisable et facile à comprendre. Même si nous faisons régulièrement des "Code Review" qui m'aident, je souhaite de mon côté changer et évoluer dans la bonne direction.

Je suis donc à la recherche d'un moyen, de méthodes qui pourraient me permettre de m'améliorer dans ces domaines.

Existe-t-il des méthodes pour penser simplement ?

Je recherche des cours en ligne dans le domaine de la conception logicielle et l'abstraction. Est-ce la bonne direction ou bien serait-il préférable de reprendre mes cours de base?

Je vous remercie!

Pascal

  • # decoupage

    Posté par  . Évalué à 4.

    il faut apprendre à découper ton probleme en plusieurs sous-problèmes simples, pour les résoudre individuellement, pour creer ensuite des actions simples

    ces actions simples, mises bout à bout, feront un programme plus compliqué.

    Pour apprendre à conduire, tu as d'abord appris à débrayer, passer les vitesses, en ligne droite, sans gérer le volant, les retros, etc
    puis on a ajouté d'autres elements, et aujourd'hui tu gères chacun des elements, en meme temps…

    • [^] # Re: decoupage

      Posté par  . Évalué à 1.

      Bonjour NeoX,

      merci pour ton message qui illustre bien mon problème!

    • [^] # Re: decoupage

      Posté par  . Évalué à 2.

      Entre autres solutions : découpage + découplage.
      Des interfaces réfléchies entre les composants.

    • [^] # Re: decoupage

      Posté par  . Évalué à 1.

      Très bon sujet que je veux creuser également.
      J'avais fait un kata avec un meetup sur le software craft par chez moi sur l'Elephant Carpaccio et j'avais trouvé l'exercice très intéressant.

      Aussi, essaye de voir l'approche TDD. En commençant par les tests et en ne réduisant qu'à des cas simple qui se complexifient au fur et a mesure, tu arrives à une implémentation la plus simple, et avec la partie refacto de TDD, tu en fais en plus une implémentation propre.

  • # Quelques remarques en vrac

    Posté par  (site web personnel) . Évalué à 6.

    Difficile de répondre à ton problème, car il est complexe de manière général, et qu'on ne te connaît pas personnellement ; en revanche le fait de vouloir progresser est une très bonne chose (il n'y a pas pire que les gens qui pensent être bon et ne se remettent pas en question).

    • Il faudra (si tu veux être compétent) toute ta vie continuer à étudier (ne serait-ce que des articles de blog sur des problématiques pointues, de nouveaux langages…) mais aussi pratiquer (sinon tu as tendance à te rouiller) ; donc pas de panique c'est une bonne chose de s'y mettre dès maintenant.
    • Il est tout à fait normal que les premières solutions qui te viennent à l'esprit soient tordues ; on a tendance à envisager le cas nominal, puis à rustiner pour gérer les cas à la marge. On abouti alors à du code de piètre qualité. Donc premièrement n'hésite pas à attendre avant d'implémenter ta première idée et de réfléchir un peu plus (prendre 1 heure quand tu te lances dans un développement de plusieurs jour ça vaut le coup); deuxièmement ne t'attends pas à ce que ton code soit bon du premier coup, il est normal d'améliorer itérativement un code (tu es ton 1er relecteur en soit).
    • Si tu as des collègues compétants qui te font des retours c'est là où tu vas apprendre le plus (car tu vas apprendre de tes erreurs, pas de celles des autres, ce qui est bien plus difficile). Si tes collègues te parlent de concepts que tu ne connais/maîtrises pas, c'est clairement qu'il faut un peu bosser ta théorie (ex: les design patterns, le couplage faible, la complexité algorithmique…).
    • Concentre toi sur la qualité pas la quantité ; tu progresseras plus en perfectionnant du code, même si la tâche qu'il effectue te semble relativement simple, qu'en pissant des milliers de lignes. Si tu n'y arrives pas sur des petites choses, tu n'y arriveras pas sur des grosses.
    • Avec le temps tu vas réussir à détecter les motifs qui se répètent dans ton code ; pas de problèmes de faire du copier-coller en première intention, mais ensuite ré-usine ton code en essayant de factoriser, de trouver des abstractions suffisamment génériques pour être utiles dans différents cas de figures et qui sont le plus faiblement couplée avec le reste du code. Je te conseillerai le développement piloté par les tests pour un ré-usinage moins stressant, mais aussi car en te forçant à faire du code testable il est souvent bien meilleur (limiter les états globaux par exemple).
    • Balade toi dans le code des autres c'est intéressant de voir d'autres approches ; l'apprentissage d'autres langages (de préférence pas dans ta zone de confort) aussi.

    J'espère que quelques uns de mes conseils te seront utile !

    • [^] # Re: Quelques remarques en vrac

      Posté par  . Évalué à 1.

      Super conseils ! , je te remercie !

      Je pense que je dois comme tu le dis, prendre plus temps pour réfléchir et ne pas me jeter dans la programmation tout de suite.

      Régulièrement j'apporte mon aide à mes collègues et je m'aperçois que je peux aussi améliorer leur code!

      Tout n'est pas négatif bien sûr, j'ai du chemin à faire et je dois être patient.

      Les différents points que tu as cité m'aident à mieux voir comment je peux développer une méthodologie dans mon travail d'analyse/ de conception.

      • [^] # Re: Quelques remarques en vrac

        Posté par  . Évalué à 2.

        Je pense que je dois comme tu le dis, prendre plus temps pour réfléchir et ne pas me jeter dans la programmation tout de suite.

        Comme dans beaucoup de travaux de conception ou de création, le plus important c'est de préparer la structure du projet pour faire en sorte que l'exécution ne soit plus qu'une traduction du plan.
        Je ne suis qu'un amateur en programmation mais dans tous les projets que je conçois (code, logique cablée, électronique analogique, mécanique, menuiserie, carrelage, graphisme, etc.), je commence par poser sur papier tous les objectifs, les paramètres et contraintes, l'UI (si elle existe) puis je réfléchis au schéma de principe et aux différentes méthodes (protip : toujours en chercher plusieurs, analyser les travaux de ses pairs pour comparer et choisir la solution la plus adéquat) et les étapes pour parvenir à mes fins et pour certaines parties je fais un PoC, une étude de cas. Ça me m'empèche pas dans certaines disciplines de me laisser des degrés de liberté durant l'exécution mais les premières notes avec les objectifs sont toujours à portée de vue ou dans un coin de ma tête.
        C'est long mais le but c'est de ne pas passer son temps à déboguer, faire des rustines, rattraper des erreurs ou des choses pas prévues au départ.

  • # Considérer le problème c'est déjà presque le résoudre!

    Posté par  (site web personnel) . Évalué à 2.

    Salut Pascal,

    je voudrais commencer par un message assez encourageant et rassurant: c'est une très beau problème que tu te poses et se le poser est déjà presque le résoudre. Il n'y a pas d'absolu dans la simplicité et en ce qui me concerne je continue d'avancer sur ce chemin même si je programme depuis maintenant presque 30 ans!

    Pour faire des progrès dans ce domaine, voici quelques idées que tu pourrais voiloir incorporer dans ta pratique:

    En parler à tes collègues!

    C'est tout bête mais si tu travailles dans un environnement assez ouvert et qui stimule la progression c'est un sujet que tu peux aborder très ouvertement avec tes collègues et par exemple convenir avec ton équipe que le critère de simplicité soit systématiquement abordé dans les revues par exemple pour les 3 prochains mois.

    Programmer en binôme

    C'est une pratique plus ou moins répandue mais un des nombreux bénéfices de la programmation en binôme (pairing) est généralement l'obtention d'une code plus simple.

    Faire des lectures critiques régulièrement.

    Pour les 3 prochains mois tu peux te réserver 1-2h par semaine pour lire des programmes écris par d'autres, ou des programmes que tu as écris toi-même il y a longtemps, en te concentrant particulièrement sur les aspects de simplicité qui te préoccupent en ce moment. (C'est en général une bonne chose de lire du code écrit par d'autres!)

    Un exercice consiste par exemple à partir d'un comportement du programme qu'on voudrait modifier et à examiner le programme pour 1/trouver la partie responsable et 2/comprendre les conséquences de cette modification. Tous les obstacles à 1 et 2 sont autant d'enseignements qu'on peut retirer.

    Faire du développement gouverné par les tests (test driven development en beau nanglais)

    Le cycle de va et viens entre les tests et le programme aident à se concentrer sur les attentes du programme et souvent à privilégier des solutions simples.

    Apprendre de nouveaux langages de programmation

    C'est un gros investissement en temps mais apprendre de nouveaux langages tous les 3-4 ans est vraiment quelque chose qui m'a fait progresser dans la programmation en général et en simplicité en particulier. Par exemple quand j'étais encore à la fac je faisais surtout du OCaml et des Shell scripts. Un beau jour je me suis rendu compte que j'écrivais beaucoup plus rapidement mes programmes avec le Shell qu'avec OCaml – alors que ce langage très primitif qu'est le Shell devrait être battu à plate couture par le langage de très haut niveau qu'est OCaml! C'est donc dans ma pratique de ces langages que je devais chercher l'explication et En faisant un peu d'autocritique je me suis rendu compte quellen programmant OCaml je passais beaucoup plus de temps à m'amuser et à explorer les possibilités expressives du langage qu'à me concentrer réellement sur les fonctions de me programme. Bien-sûr cette exploration a aussi des vertus mais en ce qui concerne la recherche de simplicité elles sont plutôt nuisibles.
    Quand on programme le Shell tout est simple: typiquement une fonction lit son entrée sur STDIN écrit sa réponse sur STDOUT e basta.

    Ce point est particulièrement important si tu fais de la POO avec un langage tel que Java, où tout est un object ce qui pousse naturellement à faire de plutôt mauvaises modélisations (souvent beaucoup trop granulaires et avec les relations de dépendance dans le mauvais sens) et à définir trois classes là où le problème n'en exige qu'une.

    Bonne chance!

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.