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.
# Considérer le problème c'est déjà presque le résoudre!
Posté par Michaël (site web personnel) . En réponse au message Problèmes lors de la conception / abstraction de programmes. É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!