Conception d'un programme

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour,

M'attaquant à un projet relativement important, je me demandais comment je devais mener la conception de mon programme.

Jusqu'à présent, honte à moi, j'ouvrais mon IDE et, après réflexion sur l'organisation globale du code, j'écrivais.

Or j'ai cru comprendre qu'il était important de concevoir son code avant de l'écrire. Mais comment ? Comment m'y prendre pour que la partie programmation soit simple et a priori sans surprise - i.e. erreur de conception - ?

Il me semble déjà distinguer plusieurs parties :

  • La définition des fonctionnalités à implémenter - l'objectif étant de rendre aisée l'implémentation future d'autres fonctionnalités
  • L'organisation globale : comme ça
  • L'organisation globale détaillée : les échanges précis entre les fichiers, comme ça
  • L'organisation de chaque fichier : quelles classes, méthodes…

Merci !

Édité par Vayel

+0 -0

NB : ce message s'applique pour des projets personnels. Si tu travailles dans une entreprise (ou dans un groupe quelconque), vois quelle est la procédure habituelle de ton entreprise/ton groupe.


Pour la conception, il n'y a malheureusement pas de recette magique. Pourrais-tu nous en dire un peu plus sur ton projet ? On pourrait regarder sa conception ensemble, rien ne vaut un bon exemple pour apprendre ! :)

Leslie Lamport a donné une conférence très intéressante dans laquelle il explique son point de vue sur la conception d'un programme. Imagine que tu vas construire une maison : tu sais à quoi ressemble une maison, pourtant tu ne vas pas commencer par empiler des briques au hasard. Tu vas d'abord faire un plan. Il y a différents types de plans : si ta maison est une cabane dans un arbre, un simple croquis suffira ; si tu te lances dans un gratte-ciel, tu ferais mieux d'avoir un plan technique précis au millimètre.

Pour les programmes, c'est un peu la même chose. Si tu te lances dans un pong, un schéma général suffira. Si tu veux faire un moteur 3D en partant de zéro, tu auras sans doute besoin de faire des diagrammes très détaillés.

En outre, le genre de plan que tu fais dépend aussi du genre de programme que tu codes. Par exemple, le plan d'un compilateur ne va pas ressembler au plan d'un jeu vidéo. Pour le compilo, tu vas plutôt décrire les différents langages intermédiaires, ainsi que les transformations pour passer de l'un à l'autre. Pour le jeu vidéo, tu vas plutôt faire un diagramme qui recense les différents éléments que comporte ton jeu et la façon dont ils interagissent.

Bref, ne te focalise pas sur une méthode ou une « recette » trop tôt. Commence par faire un « croquis » de ton programme, en utilisant la forme que tu préfères (texte, dessin…). Ensuite, tu peux formaliser ça progressivement en utilisant la méthode qui te paraît adaptée à ton projet (de l'UML à l'écriture d'équations, en passant par des automates finis…). Augmente ainsi la précision de ton plan, jusqu'à ce que tu sois assez sûr de toi pour coder.

En espérant que mon message t'ait aidé,

GuilOooo

Canis Lupus pour vous servir

+1 -0
Auteur du sujet

Merci beaucoup pour cette réponse. =)

Le projet, c'est ça et il y a plus d'informations ici et .

La partie "Cartographie" me semble superflue pour l'instant, du moins l'interface graphique : on pourra toujours générer le JSON a la main. Du coup, je pensais commencer du côté de la partie "Contrôle" à propos de laquelle je me pose déjà quelques questions.

Une petite question préliminaire : quel est l'intérêt de concevoir un programme ? Est-ce que ça permet considérablement de l'améliorer - plus clair, plus simple à maintenir, plus simple à étendre… - ?

Merci beaucoup !

+0 -0

Merci beaucoup pour cette réponse. =)

Je t'en prie. :)

Une petite question préliminaire : quel est l'intérêt de concevoir un programme ? Est-ce que ça permet considérablement de l'améliorer - plus clair, plus simple à maintenir, plus simple à étendre… - ?

Eh bien, qu'obtiens-tu à écrire le plan d'une dissertation avant de la rédiger ? À dessiner le croquis d'une maquette avant de la construire ?

En réfléchissant préalablement à ton programme, tu peux résoudre un certain nombre de problèmes qui ne dépendent pas directement du codage : quelles fonctionnalités implémenter (ou non) ? Comment découper ton programme ? Comment les différentes parties vont interagir ? Quelles structures de données choisir ? Quels algorithmes choisir ?

Toutes ces questions sont à la fois importantes et difficiles, d'autant plus difficiles que ton projet est ambitieux. Tu as besoin d'une vision d'ensemble de ton logiciel pour y répondre efficacement. Lorsque tu programmes, tu es concentré sur le bout de code que tu es en train d'écrire maintenant, tu n'as pas l'intégralité des sources en tête. Il est donc très difficile (voire impossible) de répondre à ces interrogations cruciales pendant l'implémentation.

À l'inverse, si tu t'occupes de toute la partie « découpage/choix des structures de données/choix des algorithmes » avant de programmer, tu n'as plus à y réfléchir au moment où tu tapes le code. Tu as donc plus « d'énergie mentale » à consacrer à l'implémentation (code propre, écriture des tests, écriture de la doc, etc.).

Au final, tu obtiens un code source de meilleure qualité, plus simple, clair et lisible, avec probablement une meilleure maintenabilité et extensibilité (si tu as fait attention à ces points lors de la conception). Ça peut donc valoir le coup de s'y pencher, oui. :)


Concernant la conception, ma méthode perso est la suivante : j'imagine que je doive expliquer le logiciel à un ami. L'idée, c'est que mon ami va devoir écrire le code de A à Z, sans que je puisse l'aider. Je dois donc lui donner tous les détails importants pour que le résultat final corresponde à mon souhait de départ.

J'ai lu les liens que tu as postés et j'ai essayé de m'imaginer devoir coder le logiciel. En premier lieu, ton objectif me paraît bien expliqué, on voit bien où l'on va. Le découpage en modules est également clair, il semble bien adapté à la résolution du problème que tu te poses. Jusque là, je dirais que c'est un bon début.

Maintenant, imagine que tu diriges 7 programmeurs et que chacun d'entre eux doive implémenter l'un des 7 modules. Que leur expliquerais-tu ? Il faudrait commencer par définir précisément le but de chaque module, éventuellement en donnant une API publique (avec force de commentaires). En suite, tu peux expliquer les grandes lignes de l'implémentation, notamment les bibliothèques, structures de données et algorithmes utilisés. Pas besoin d'aller jusqu'au pseudo-code ni jusqu'au diagramme de classes pour le moment, fais au feeling pour le niveau de détails. Garde juste à l'esprit que tu t'adresses (pour l'exercice) à un autre programmeur, pas à toi. :)

N'hésite pas à nous (j'ose espérer ne pas être seul à répondre à ce topic :-) ) faire part de tes difficultés, les points où tu n'es pas sûr de toi, etc. :)

Canis Lupus pour vous servir

+0 -0
Auteur du sujet

Merci !

Pour ce qui est des objectifs de chaque module, j'ai commencé ici - les lettres et chiffres correspondent à img/plan.png. Comme ce n'est pas terminé, je vais poursuivre avant de détailler les technologies et l'organisation du code.

Par contre, je ne comprends pas trop ce que tu entends par "éventuellement en donnant une API publique (avec force de commentaires)". ^^

Sinon, y a-t-il des questions universelles à se poser lors de la définition du but de chaque module ? J'avoue être un peu dépassé et avoir du mal à concevoir mon programme théoriquement. Avant, je pensais la structure globale puis j'attaquais un module, sans penser aux autres - i.e. sans les avoir pensés précisément - et je me basais principalement sur les erreurs rencontrées pour corriger tout ça. Ici, je me sers de mon expérience - pas très volumineuse - mais je peine à anticiper - ou alors peut-être cherché-je à trop anticiper, craignant qu'une erreur de conception casse tout le projet.

Si on récapitule, il faudrait faire dans l'ordre :

  • Définir l'objectif global du projet
  • Définir l'organisation globale du projet : le découpage en modules
  • Définir le rôle exact de chaque module
  • Définir le contenu de chaque module : l'organisation du code du module

Encore merci ! :P

+0 -0

Par contre, je ne comprends pas trop ce que tu entends par "éventuellement en donnant une API publique (avec force de commentaires)". ^^

Dans chaque module, quelles sont les fonctions publiques (qui pourront être appelées par d'autres modules) ? Quels sont les arguments pris par ces fonctions et que renvoient-elles ? Peux-tu écrire un petit commentaire pour expliquer comment se servir de chacune de ces fonctions ?

Sinon, y a-t-il des questions universelles à se poser lors de la définition du but de chaque module ?

À quoi sert-il ? (dans ton cas, déjà répondu)

Comment s'en sert-on ? (cf. la première partie de ce message, où je t'explique ce qu'est l'API publique)

Comment marche-t-il, en gros ? (quelles sont les structures de données et les fonctions principales, y compris non-publiques (i.e. internes au module), et comment interagissent-elles ?)

Si on récapitule, il faudrait faire dans l'ordre : […]

J'insiste sur le fait qu'il n'y a pas de recette miracle et que la conception dépend fortement du type de projet que tu conduis.

Dans ton cas, comme tu avais déjà fait un découpage en modules, je t'ai conseillé de continuer en ce sens, et de baser ta conception sur ce découpage. Tu avais un bon début et ça semblait bien coller au projet. Mais si un jour tu fais un autre logiciel, complètement différent, il y a d'autres façons de s'y prendre. :)

Canis Lupus pour vous servir

+0 -0
Auteur du sujet

Pour ceux qui se posent la question et ceux qui veulent réagir à cela, on m'a conseillé de ne pas tout coder directement mais d'avancer par paliers, en citant "Le mythe de l'homme-mois" de F. Brooks.

+0 -0

Si je me souviens bien, l'idée est d'arriver le plus tôt possible à un programme utilisable, qui fasse quelque chose, même s'il manque encore les trois quarts des fonctionnalités. C'est très motivant de travailler sur un logiciel que tu peux utiliser (même très partiellement) et que tu améliores au fur et à mesure. Idéalement, il faut donc éviter de bosser des semaines entières dans le brouillard, sans voir de résultats concrets.

Il me semble (j'émets une grosse réserve ici, que les spécialistes me corrigent) que le mythe de l'homme-mois a été écrit en réaction au fait que de nombreuses entreprises de l'époque utilisaient des méthodologies extrêmement rigides et formelles pour développer leurs logiciels. Ces méthodologies imposaient de faire l'ensemble de la conception, puis l'ensemble de l'implémentation, puis l'ensemble des tests, en interdisant tout retour en arrière.

À l'inverse, le mythe de l'homme-mois recommande de faire des allers retours entre conception et implémentation, à mesure que les difficultés sont découvertes ou que le cahier des charges change. Plus les cycles sont courts, plus l'équipe de développement est réactive. En pratique, il existe de nombreuses méthodologies suivant ce principe, décrites dans divers livres et séminaires. Il n'existe pas vraiment de recette miracle et chaque équipe doit adapter sa technique en fonction du projet.

Le risque d'une approche à cycles courts est la perte de la vision d'ensemble du projet. Certains composants du logiciel, programmés lors des premiers cycles du développement, peuvent se révéler inadaptés et requérir beaucoup de travail pour être corrigés. Une planification plus avancée peut parfois (mais pas toujours, notamment en cas de changement du cahier des charges) pallier à ce problème.


Si tu es seul (ou en binôme), je ne suis pas certain que toutes ces considérations soient pertinentes pour ton projet. Toutes ces techniques servent à organiser des équipes de développement, pas à guider un programmeur solo. Toutefois, c'est bien de garder les concepts de base en tête.

À ta place, je me contenterais de fixer des objectifs réalistes, atteignables en 1 ou 2 semaines, puis de travailler par cycles de 1 ou 2 semaines. Que ce soit pour la conception ou l'implémentation, commence par définir ce que tu veux faire (idéalement quelque chose qui donne un résultat concret), puis fais-le. Garde-toi la possibilité de revenir en arrière (ce qui a été conçu ou implémenté peut toujours être modifié), mais évite de faire trop d'allers-retours.

Canis Lupus pour vous servir

+0 -0
Auteur du sujet

Hello!

Je me demandais : existe-t-il des outils pour faire des schémas résumant les interactions entre les modules ? Pour l'instant, j'utilise GIMP mais c'est un peu laborieux. ^^

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

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