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 NeoX . É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 iex.new . Évalué à 1.
Bonjour NeoX,
merci pour ton message qui illustre bien mon problème!
[^] # Re: decoupage
Posté par AncalagonTotof . Évalué à 2.
Entre autres solutions : découpage + découplage.
Des interfaces réfléchies entre les composants.
[^] # Re: decoupage
Posté par 16aR . É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 GuieA_7 (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).
J'espère que quelques uns de mes conseils te seront utile !
[^] # Re: Quelques remarques en vrac
Posté par iex.new . É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 Anonyme . Évalué à 2.
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 Michaël (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!
[^] # Re: Considérer le problème c'est déjà presque le résoudre!
Posté par iex.new . Évalué à 2.
Bonjour Michaël,
merci beaucoup pour ces bons conseils!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.