Concevoir un programme de A à Z - Page 1

yop,


C'est pas nouveau que mes lacunes en programmation sont importantes, et dûes, à mon sens, à mon manque de méthode. Je crois que la conception d'un logiciel fait partie de cette science qu'on appelle Ingéniérie Logicielle. Et comme je n'y connait rien, je me plante dans mes projets après un certain avancement... J'en ai donc marre, je ne peut rien mener à bout de cette manière...

Extrait d'une conversation avec flan de ce matin :

[12:54:17] <flan> Alors, est-ce que tu t'es mis à l'UML avant de te lancer dans le code ?[13:35:44] <Folco> non
[13:35:49] <flan>
[13:35:52] <flan> pas sérieux
[13:35:58] <Folco> Pourtant, t'as raison, 1000 fois raison sûrement...
[13:36:11] <flan> perso, je suis en train de m'y mettre
[13:36:15] <Folco> Mais j'ai trouvé ça compliqué :/
[13:36:33] <flan> qu'il y a-t-il de compliqué ?
[13:36:41] <Folco> Et j'aborde trop de trucs que je ne maitrise pas à la fois, en fait je ne sais pas par quel bout tirer sur les ficelles pour faire ça avec méthode...
[13:36:57] <flan> ah oui, par contre, c'est un bon argument
[13:37:10] <Folco> Je comprends pas où l'UML veut me faire arriver, parce que c'est fait pour aider à designer, mais __je ne sais pas__ designer...
[13:37:26] <flan> tu crois que je sais ?
[13:37:43] <flan> là, c'est plutôt pour avoir sur le même schéma l'ensemble de mes classes
[13:37:51] <Folco> Attends, t'as cent fois plus de hauteur de vue (et d'xp en plus) dans ton approche que moi
[13:38:00] <flan> pour mon prochain site web, je risque d'avoir besoin d'une bonne quarantaine de classes ^^
[13:38:16] <flan> je préfère avoir une bonne vision globale
[13:39:06] <Folco> Je peux quoter ce bout de convrsation ? J'aimerais demander comment m'y prendre (tutos, bouquins) pour connaitre un minimum l'ingéniérie logiecielle (je crois que c'est ce sujet dont on parle)
[13:39:15] <flan> bien sûr ^^
[13:39:17] <Folco> Merci
[13:39:24] <flan> de rien ^^
[13:39:52] <flan> en gros, tu veux savoir quels sont les étapes pour un bon logiciel, et quels sont les outils à chaque étape ?
[13:40:19] <Folco> Voilà ! Par où commencer ? Ecrire ! Mais quoi ? etc...
[13:40:28] <flan> oui, je comprends
[13:40:46] <Folco> Ecrire des specs, mais pas encore du code, mais les specs de quoi ? De l'affichage d'un sprite ? Osef au début, alors il faut s'arrêter où ? [13:41:08] <Folco> Visiblement, on descend en approfondissant à chaque fois. Mais comment définir ces barières d'analyse etc... mystère...

(les timestamps on deux heures d'avance ^^)

Donc, quand je veux réaliser un projet, je ne sais pas par quel bout attaquer. Je crois qu'il faut écrire des specs, mais de quelle manière, s'arrêter où dans l'approfondissement ? Du reste, que spécifier ? Des classes, quoi ? Je n'en sais rien. Quand rentrer dans l'impémentation, quand faire intervenir les softs ou libs sur lesquels on va s'appuyer ? Je n'en sais toujours rien.
L'UML, j'avais regardé un moment, mais c'est un outil, je ne sais pas quand l'utiliser, vu que je ne sais même pas où je veux aboutir...

Donc si vous avez des conseils, des cours, des tutos, ou des bouquins même, je suis prêt à en acheter un bon, je vous remercie de m'en faire part.

Merci d'avance pour votre temps et votre aide.

Il n’y pas de recette miracle, mais il y a des bouquins là-dessus ça pourra peut-être te guider (je n’en ai pas encore lu donc je ne peux pas t’en conseiller un en particulier).

Sinon moi aussi je me plante assez souvent, et je crois que c’est toujours très difficile de coder d’une traite une application un peu complexe sans s’apercevoir de certains détails qui tâchent et qui remettent un peu en question l’architecture initiale.

Globalement voici comment je procède :

— Quelles sont les fonctionnalités que je veux proposer dans mon application ?
 — Quelles sont les données nécessaires au fonctionnement de l’appli ?

La première question est assez facile, elle sert à mettre un cadre, à dessiner les limites de l’application.

La seconde question est plus difficile, il y a des choix importants à faire, qu’est-ce qui doit être modélisé, qu’est-ce qui est superflu, comment relier les entités entre elles, etc. ? L’objectif est de concevoir une architecture logicielle qui permet de répondre aux besoins émis dans la réponse à la première question.

Des axes dans lequels il est, à mon avis, intéressant de regarder:
* l'historique du développement du génie logiciel, les cycles de vie utilisés au fil du temps, leurs avantages et inconvénients (code-and-fix, cascade, V, les différentes variantes d'itératif, les méthodes agiles de plus en plus utilisées car les clients savent de moins en moins ce qu'ils veulent - sans oublier les méta-cycles, du type spirale, où à chaque étape, on regarde quel est le cycle de développement le plus adapté)
* le groupe des "patterns" et anti-patterns, de design comme d'implémentation. C'est à dire, des solutions un peu générales, validées par l'expérience, bien adaptées à un groupe de problèmes donnés.

Quand j'étais à la fac il y a quelques années, on en a vu un certain nombre en cours de génie logiciel, mais je n'ai pas les références de bons bouquins sur le sujet...

À propos des design patterns, il y a un bouquin que je ne recommande pas : « Design Patterns pour Java — Les 23 modèles de conception », qui est trop superficiel. Le GOF est pas mal, il semble qu’il n’ait pas trop vieilli, sinon un des plus populaires sur Amazon est « Design Pattern la tête la première ».

Oki, merci bien. Mais si je ne me trompe pas, les design pattern sont justement des modèles préconçus à adapter à ses besoins. Mais j'aimerais faire cette conception moi-même : rélféchir sur mes besoins, et concevoir les outils dont j'aurai besoin pour réaliser ce que je veux. si je pars des design pattern, j'aurai déjà toute une couche préfaite, au moins dans les grandes lignes, et j'ai pas trop envie. Je préfère apprendre à faire.

Folco : il n'y a pas UNE méthode pour concevoir un programme (cf. Lionel Debroux qui te parle des différentes méthodes).

Du haut de mon très très peu d'expérience et de cours de génie logiciel, je dirais que, peu importe ce que tu choisis comme méthode, ce qui compte avant tout c'est que tu sois convaincue de son bien-fondé et que tu restes organisé.

En simplifiant, en général on distingue plusieurs phases plus ou moins successives dans la création d'un projet (mais je précise que je n'y connais vraiment pas grand chose, donc j'espère ne pas raconter trop de la merde )

1) Décider ce que l'on veut d'un point de vue non technique (ie. je veux une application qui fait ça, ça et ça, mais je ne sais pas encore COMMENT je vais l'implémenter ou le designer). Un truc qui peut t'aider (ou pas), c'est d'être assez organiser et de créer une liste de "use cases" (chaque activité différente que tu veux qu'un utilisateur puisse faire : effectuer un paiement, créer un nouveau profil, etc.). Et pour chacun de ces "use cases", ça peut aider d'avoir une description assez précise mais pas technique encore une fois et sans choix de design

2) A partir des spécifications que tu as déterminé, arrive la phase d'analyse, où en gros tu vas commencer à définir un ensemble de classes, puis leurs attributs et méthodes et les relations entre elles (en très gros, tu peux identifier les classes qui sont généralement les NOMS utilisés dans ta spécification -- sauf si ces noms désignent des utilisateurs, bien entendu)

3) Le design, qui est un peu plus poussé et comprend l'architecture du logiciel et tout un tas de trucs plus complexes que tu n'avais pas identifiés avant. Et pour le coup, les Design Patterns te seront d'une certaine aide parfois, vu qu'ils abordent des problèmes qui ont déjà été posés et résolus (donc ça t'évite de réinventer la roue à chaque fois ou d'être trop cafouilleux)

4) Et ensuite tu implémentes et tu testes

5) Puis tu intègres si c'est nécessaire


Mais bon, ça c'est l'idée générale. Mais bien souvent, même si cet ordre est à peu près respecté, il y a beaucoup d'allers-retours entre les différentes étapes (par exemple, pendant l'implémentations tu remarqueras sans doute des trucs que tu n'avais pas vus et tu changeras le design)

Sachant que ce sont des projets persos (si je ne me trompe pas ?), je te conseille de lire les livres d'ingénierie logicielle avec beaucoup d'esprit critique, parce que certains te diront de faire des centaines de diagrammes et de produire des centaines de pages de spécifications, mais c'est entre autres parce qu'il est nécessaire de communiquer avec d'autres personnes ou sur des gros projets, mais ça ne te sera pas forcément adapté (mais ça je suppose que tu le sais ).


Pour ce qui est d'UML, tu n'as pas besoin de tout apprendre. Personnellement, ce que je trouve le plus utile c'est les diagrammes de classes, car ça permet de représenter les relations entre les classes de façon claire et très concise, et c'est très visuel et c'est bien pour avoir une vision d'ensemble quand ton projet prend de la taille (je n'utilise pas toutes les charactéristiques, par exemple je n'utilise aucun nombre parce que c'est relou )


PS: j'ai mon exam d'ingénierie logicielle la semaine prochaine. Si tu veux je pourrai t'envoyer mes notes/fiches une fois que ce sera fini (par contre je ne traiterai pas la partie design du cours ) C'est en anglais par contre, je sais pas si c'est un problème...

Merci !

Et pas de souci pour tes fiches en anglais, si tu as le temps, j'apprécirai beaucoup

Et oui, ce ne sont que des projets persos, et sur lesquels je suis le seul à bosser.

Argh j'écris vraiment comme une noisette quand je tape

Ok, pas de problème

Un design pattern que j'ai trouvé extrêmement utile (sinon je n'y comprends pas grand chose malheureusement ) c'est celui de la transition entre états. Ca te donne deux méthodes possibles (en utilisant un tableau ou bien des classes) pour gérer les changements d'état du système (par exemple, "machin validé", "machin envoyé", "machin en attente de confirmation", "machin allant à la pêche", ...) C'est typiquement un truc assez complexe pour lequel il peut être utile de jeter un oeil aux design patterns (mais c'est tout à fait louable de vouloir découvrir toi-même tes propres techniques )

Ok, merci bien pour le tip. En effet, ça doit être un problème retourné et connu sous toutes les coutures. ^^

Souane (./8) :
Argh j'écris vraiment comme une noisette quand je tape

Oui, j'ai essayé de faire taper les miennes, une vraie galère


Au fait, je me pose une question à propos de la conception :
Faut-il partir par le haut ou par le bas ? Je m'explique.

Je peux dire :
- mon jeu va afficher sur un écran principal
-> J'afficherai différents plans (clippés) sur cet écran
-> J'afficherai des objets sur ces plans
-> Les objets seront par exemple des icones (avec callback, effet de hoover etc...), des sprites animés, des sprites simples et des textes

Ou encore :
- je veux afficher des textes, des icones, des sprites animés et des sprites simples
-> je vais réunir ces objets dans différents plans (hud, partie principale (terrain), barre de vie etc...)
-> je vais utiliser des plans pour grouper ces objets
-> j'afficherai ces plans dans la fenêtre principale

D'un côté, je conçois des petits objets élémentaires que je vais agglomérer dans des structures englobantes.
De l'autre, je conçois des objets généralistes que je vais remplir avec des objets de plus en plus détaillés.

Quelle est la meilleure solution (s'il y en a une) ? Quelles sont les avantages et inconvénients des deux méthodes ?

Les design patterns sont des solutions à des problèmes récurrents en dev logiciel, te conduisant généralement à découpler au maximum les différents composants (assumant chacun différentes responsabilités) impliqués dans ton logiciel (typiquement, découpler l’interface utilisateur du cœur du système peut être une bonne chose).

Je pense que c’est une bonne chose d’avoir déjà de l’expérience dans le développement pour vraiment saisir l’utilité de ces patterns, mais il me semble que c’est ton cas, vu toutes les années de dév TI que tu as derrière toi…

Sinon, comme la question de ton premier post est très générale, c’est difficile de te répondre, peut-être que tu peux préciser ce qui te pose problème, quels sont les situations concrètes que tu as rencontrées qui t’ont mené à la conclusion que ton architecture logicielle était inappropriée ? Est-ce que les idées que nous avons soulevées dans nos réponses te parlent ?

[cross]

Je ne pense pas que ça importe beaucoup (encore une fois, du haut de mon expérience inexistante). J'aurais tendance à dire que la meilleure méthode c'est celle qui te convient le mieux (c'est à la fois une question de goût et de degré d'organisation dont tu as besoin). Personnellement je préfère aller du général au particulier, parce que je trouve ça plus facile à suivre, mais c'est juste une préférence

Un truc qui peut être utile si tu as une interface assez sophistiquée, c'est de séparer la description de l'interface de la description des fonctionnalités (je dirais que c'est nécessaire pour ne pas trop te perdre...). Soit en le mettant dans une autre partie, soit en l'intégrant au texte mais d'une autre couleur, enfin bref.
D'ailleurs, dans ton programme final, c'est bien d'avoir différents paquets de classes (si tu fais de la prog O-O évidemment), et typiquement tout ce qui est graphique sera séparé de tout ce qui est données. Les paquets de classes (packages), je ne sais pas si c'est quelque chose que tu utilises, mais encore une fois c'est un truc qui change la vie (j'exagère peut-être un peu quand même ) dès que tu as plus d'une dizaine de classes (en particulier si tu utilises un IDE qui t'affiche la liste des classes quelques part).

Désolée si je te dis des trucs qui te paraissent évident. Je n'ai aucune idée de ce que tu fais ou de ce que tu sais déjà

./9 Ça m’intéresse bien d’avoir les témoignages d’autres personnes.

Voici le mien :

L’approche bottom-up est intéressante car elle te conduit généralement à développer des petits composants réutilisables, indépendant du reste de l’application : tu vas par exemple développer une routine chargée d’afficher un sprite, une autre chargée de réaliser une autre tâche, etc. Au final chaque fonction fera une seule chose et le fera bien. Cependant, une telle approche peut te conduire à te disperser : tu risques de développer plein de petits composants éparpillés et ça peut être compliqué à assembler, ou simplement faire trop de choses par rapport à tes besoins.

C’est là que l’approche top-down est intéressante : elle te conduit à dessiner les grandes lignes de ton programme, sans te préoccuper de certains détails qui pourront être affinés ultérieurement, et permet d’obtenir un code assez concis, rapidement testable. L’inconvénient c’est qu’en procédant de la sorte tu risques d’introduire du couplage entre tes composants, ce qui pourra poser des problèmes si ton architecture change à un moment ou un autre.

En fait, les deux approches ont des qualités et des inconvénients, tout dépend de ce que tu veux faire, d’où tu en es par rapport à tes objectifs, etc.

Sasume (./12) :
C'est là que l'approche top-down est intéressante : elle te conduit à dessiner les grandes lignes de ton programme, sans te préoccuper de certains détails qui pourront être affinés ultérieurement, et permet d'obtenir un code assez concis, rapidement testable. L'inconvénient c'est qu'en procédant de la sorte tu risques d'introduire du couplage entre tes composants, ce qui pourra poser des problèmes si ton architecture change à un moment ou un autre.

Est-ce que tu aurais un exemple ? Pourquoi l'approche bottom-up introduit davantage de couplage ?

Ok, merci Sasume. Perso je serais tenté de partir en up-bottom mais en restant relativement général (écran, plan, objets sur les plans), puis de recommencer bottom-up pour le détaillage. Je ne sais pas ce que ça vaut.

Souane (./11) :
Désolée si je te dis des trucs qui te paraissent évident. Je n'ai aucune idée de ce que tu fais ou de ce que tu sais déjà

Non, je suis plutôt à la limite de rien comprendre
=>

Souane (./11) :
Les paquets de classes (packages), je ne sais pas si c'est quelque chose que tu utilises

Je ne sais pas ce que c'est, je vais googler une explication potable.

Souane (./11) :
typiquement tout ce qui est graphique sera séparé de tout ce qui est données

Je ne sais pas faire, du moins c'est typiquement le genre de problème que je ne sais par où attaquer.

Souane (./13) :
Est-ce que tu aurais un exemple ? Pourquoi l'approche bottom-up introduit davantage de couplage ?

Peut-être qu'en bottom-up tu designes sans savoir à quoi va être rattaché ce que tu fais, donc tu restes généraliste et sans contrainte ? En sens inverse, tu connais déjà parfaitement ce que tu as fait une couche au-dessus, ce que tu vas faire va chercher à s'y adapter un maximum ?

Sasume (./10) :
Sinon, comme la question de ton premier post est très générale, c’est difficile de te répondre, peut-être que tu peux préciser ce qui te pose problème, quels sont les situations concrètes que tu as rencontrées qui t’ont mené à la conclusion que ton architecture logicielle était inappropriée ? Est-ce que les idées que nous avons soulevées dans nos réponses te parlent ?

Les packages, c'est pas très compliqué. Si tu utilises un languages orienté objet avec des classes, tu mets peux rassembler ces classes dans des espèces de dossiers appelés packages pour t'y retrouver. C'est le seul intérêt. Et ensuite, si tu veux appeler une classe qui est dans un autre package, tu dois indiquer "import [nom_du_package];" au début de la classe (en tout cas en java).

Sasume en a déjà parlé, mais un truc qui est super important (idem, tu en es sans doute un minimum conscient mais bon) c'est que chaque classe et chaque méthode ait un rôle le plus limité possible et n'agisse pas (la plupart du temps) sur les autres classes ou méthodes. Est-ce quelque chose que tu fais ? Au début, je ne le faisais pas par flemme, mais au final ça te fait gagner du temps parce que ça t'évite de recopier du code inutilement, et SURTOUT ça te permet de modifier ton code plus efficacement et de réduire la dépendance entre des choses qui n'ont rien à voir. De plus, c'est au final beaucoup plus clair et ça t'évite de t'emmêler trop les pinceaux

Tu travailles avec quel(s) langage(s) ?

Souane (./13) :

Sasume (./12) :
C'est là que l'approche top-down est intéressante : elle te conduit à dessiner les grandes lignes de ton programme, sans te préoccuper de certains détails qui pourront être affinés ultérieurement, et permet d'obtenir un code assez concis, rapidement testable. L'inconvénient c'est qu'en procédant de la sorte tu risques d'introduire du couplage entre tes composants, ce qui pourra poser des problèmes si ton architecture change à un moment ou un autre.

Est-ce que tu aurais un exemple ? Pourquoi l'approche bottom-up introduit davantage de couplage ?

Non non, c’est l’approche top-down qui peut créer plus de couplage que l’approche bottom-up.
Parce que les sous-composants vont être conçus pour fonctionner avec ceux qui sont au-dessus. Alors qu’en faisant du bottom-up, justement, les sous-composants sont conçus de manière indépendante. (cf la réponse de Martial aussi)

Folco (./14) :
Ok, merci Sasume. Perso je serais tenté de partir en up-bottom mais en restant relativement général (écran, plan, objets sur les plans), puis de recommencer bottom-up pour le détaillage. Je ne sais pas ce que ça vaut.

C’est ce que je fais en général.

Sasume (./16) :
C’est ce que je fais en général.

Yep ! Ca a dû faire ses preuves alors, cool.

Sasume (./16) :
Non non, c’est l’approche top-down qui peut créer plus de couplage que l’approche bottom-up.
Parce que les sous-composants vont être conçus pour fonctionner avec ceux qui sont au-dessus. Alors qu’en faisant du bottom-up, justement, les sous-composants sont conçus de manière indépendante. (cf la réponse de Martial aussi)

Euh oui, j'avais mal compris la question de Souane, en tout cas je l'avais rectifiée machinalement, et j'y ai répondu dans le même sens que toi du coup (c'est à dire dans le bon)

Souane (./15) :
Tu travailles avec quel(s) langage(s) ?

C++ (+SDL)

Souane (./15) :
Sasume en a déjà parlé, mais un truc qui est super important (idem, tu en es sans doute un minimum conscient mais bon) c'est que chaque classe et chaque méthode ait un rôle le plus limité possible et n'agisse pas (la plupart du temps) sur les autres classes ou méthodes. Est-ce quelque chose que tu fais ?

Ca me semble évident, mais sans savoir pourquoi et sans pouvoir l'expliquer... Mais il y a quand même un minimum de dépendances, non ?
Je m'explique... Mes sprites, leur méthode d'affichage va bien devoir faire référence à une SDL_Surface* (un plan se dessiner quoi), donc les classes qui utiliseront les sprites devront fournir cette interface, sans quoi je pourrai jamais afficher mes plans.
Mais le but c'est que ça reste minimaliste c'est ça ?

Oui. Moins on en sait sur les objets qu’on manipule, mieux c’est.

Oups, je voulais dire top-bottom ^^

Oui, voilà Folco. Bien sûr que dans tes classes tu vas créer des objets d'autres classes et appeler leurs méthodes. C'est tout à fait normal. Par contre (en java, mais en C++ je ne sais pas comment ça marche vu que c'est un langage hybride) il ne faut pas que tu manipules DIRECTEMENT ces objets d'autres classes et leurs variables (à la place, justement, tu vas utiliser des méthodes). Toi, tu sais seulement le RÉSULTAT que tu veux, mais tu n'as pas à savoir l'algorithme qui se cache en dessous (enfin bien sûr, si c'est toi qui programmes tout tu le sais en fait, mais l'idée c'est que tu n'en as pas besoin). Ca évite entre autre les effets de bord

Sasume (./12) :

L’approche bottom-up est intéressante car elle te conduit généralement à développer des petits composants réutilisables, indépendant du reste de l’application : tu vas par exemple développer une routine chargée d’afficher un sprite, une autre chargée de réaliser une autre tâche, etc. Au final chaque fonction fera une seule chose et le fera bien. Cependant, une telle approche peut te conduire à te disperser : tu risques de développer plein de petits composants éparpillés et ça peut être compliqué à assembler, ou simplement faire trop de choses par rapport à tes besoins.
C’est là que l’approche top-down est intéressante : elle te conduit à dessiner les grandes lignes de ton programme, sans te préoccuper de certains détails qui pourront être affinés ultérieurement, et permet d’obtenir un code assez concis, rapidement testable. L’inconvénient c’est qu’en procédant de la sorte tu risques d’introduire du couplage entre tes composants, ce qui pourra poser des problèmes si ton architecture change à un moment ou un autre.

Tiens, c'est marrant, pendant mes études on m'a "éduqué" à ces deux méthodes, mais sans me les nommer.
Cela dit, personnellement, je cumule un peu ces deux approches : je fais d'abord un top-down au moment de l'analyse avec les demandeurs (qui veulent souvent un prototype réalisé à l'arrache - fonctionnel ou pas, d'ailleurs ; ça se résume souvent à une IHM ayant le rendu final - pour tester et demander de nouvelles fonctionnalités), puis je fais du bottom-up en effectuant une réécriture totale (ou presque) très modulaire (c'était la méthode préférée de notre prof d'algo - qui était aussi et surtout prof de maths - parce que ça nous permettait en tant qu'étudiants de réaliser que les gros problèmes ont souvent besoin d'être découpés en petits problèmes qui, au final, sont assez triviaux).

Je dirais que le top-down permet d'avoir plus d'échanges avec les demandeurs (les clients, quoi, mais dans mon cas ça n'en sont pas), alors que le bottom-up est ce qui me permet d'avoir un code modulaire, réutilisable et plus facilement évolutif.

Bon, dans la réalité des faits, mon bottom-up est (malheureusement) toujours un peu bâclé faute de temps

Souane (./6) :
Du haut de mon très très peu d'expérience et de cours de génie logiciel, je dirais que, peu importe ce que tu choisis comme méthode, ce qui compte avant tout c'est que tu sois convaincue de son bien-fondé et que tu restes organisé.

L'objectif du programme est aussi très important... en particulier, ces points qui (à mon sens) sont cruciaux :
- quelle est la durée de vie du programme ? (il m'arrive d'avoir à écrire des applications - plutôt petites - dont la durée de vie ne sera que d'un an, voire moins, parce qu'on sait que les règles du jeu vont changer suite à des directives ministérielles ou autres...)
- quel est le niveau d'évolutivité potentiel du programme ? (est-ce que l'histoire nous dit que les processus en liens avec l'application évoluent souvent ou pas ?)
- qui peut avoir à retravailler le code de l'application ?

Dans le cas où l'application va pas mal évoluer et sur une longue durée, on a intérêt à utiliser des méthodologies assez classiques qui permettront à n'importe quel informaticien de reprendre le travail.
Si la durée de vie est courte (deux à trois ans) je pense personnellement qu'on peut se permettre d'employer des méthodes plus libres et plus souples.

(Bon, mon expérience est aussi assez limitée : je n'ai pas ou peu travaillé sur de très très gros projets avec de grosses équipes de développeurs, donc ça joue aussi sur ma façon de faire).

Nil (./20) :

Souane (./6) :
Du haut de mon très très peu d'expérience et de cours de génie logiciel, je dirais que, peu importe ce que tu choisis comme méthode, ce qui compte avant tout c'est que tu sois convaincue de son bien-fondé et que tu restes organisé.

L'objectif du programme est aussi très important... en particulier, ces points qui (à mon sens) sont cruciaux :
- quelle est la durée de vie du programme ? (il m'arrive d'avoir à écrire des applications - plutôt petites - dont la durée de vie ne sera que d'un an, voire moins, parce qu'on sait que les règles du jeu vont changer suite à des directives ministérielles ou autres...)
- quel est le niveau d'évolutivité potentiel du programme ? (est-ce que l'histoire nous dit que les processus en liens avec l'application évoluent souvent ou pas ?) - qui peut avoir à retravailler le code de l'application ?

Et aussi, peut-être : - est-ce que tu veux pouvoir réutiliser tout ou partie de ton programme à l'avenir, non ?

Oui, j'ai failli le mettre, mais j'avais la flemme (et du boulot en cours)

Enchantée de l'avoir mis pour toi, alors

Sinon, perso en dev Web (HTML/CSS, quel que soit le langage côté serveur — Java, Python ou PHP) je remarque que je mets 5 fois plus de temps à développer que pour une application classique (en Python + Qt par exemple).

C’est normal à votre avis ?

Souane (./19) :
il ne faut pas que tu manipules DIRECTEMENT ces objets d'autres classes et leurs variables (à la place, justement, tu vas utiliser des méthodes). Toi, tu sais seulement le RÉSULTAT que tu veux, mais tu n'as pas à savoir l'algorithme qui se cache en dessous (enfin bien sûr, si c'est toi qui programmes tout tu le sais en fait, mais l'idée c'est que tu n'en as pas besoin). Ca évite entre autre les effets de bord

On est bien d'accord, ça me semble le B.A. BA de la POO. D'ailleurs, même en C et en asm je m'y prend comme ça. J'écris des accesseurs (dont je pourrais très bien me passer en soi) pour accéder à mes données dès qu'elles dépassent quelques ocets. Ca a une côté artificiel et pas optimal, mais c'est génial côté clarification et maintenance (modification de structure, ré-écriture de deux ou trois accesseurs et c'est tout).

Ca fait bien longtemps que je n'ai pas développé pour autre chose que pour le Web, mais je pense que ça vient de plusieurs points :

[ul][li]Du temps passé à s'occuper du rendu
[ul][li]Pas d'outil de design WYSIWYG vraiment efficace
[li]Besoin d'utiliser plusieurs compétences (le langage de programmation, le HTML côté rendu, le xml s'il y a des données à faire transiter, le javascript...) qui ont toutes des niveaux de debug, de logique et de subtilité différents
[li]Même pour une application "toute bête", le client a besoin que le look soit soigné parce que ça sera "comme un site web"
[/ul][li]Du temps passé à s'occuper de la sécurité
[li]Du temps passé à s'occuper des échanges de données entre les pages (là où, dans une application normale, un objet vit toute la durée du programme, il faut s'occuper de le faire transiter de page en page)[/ul]
Par contre, il faut avouer que pour tout ce qui est échange de données en réseau, ça permet ne faire abstraction de toute la partie système qui est gérée par le serveur Web.

Folco : ok Comme dit plus haut 1) Je ne sais pas comment tu programmes (je lis pas trop ce forum et en plus le design ne transparaît pas toujours sur la fonctionnalité donc même savoir que tu programmes des trucs qui marchent ne prouve pas que tu designes correctement derrière ) ; 2) Tu ne nous as pas encore dit quel genre de problèmes tu rencontrais, histoire qu'on puisse t'aiguiller sur les concepts qui te seraient le plus utiles

Souane (./27) :
le design ne transparaît pas toujours sur la fonctionnalité donc même savoir que tu programmes des trucs qui marchent ne prouve pas que tu designes correctement derrière

Ah mais je te l'accorde à 200%, j'écris du code, mais sûrement mal, pu***n ça fait suer
Pour information, je suis toujours en admiration devant le code des autres (de softs finis on va dire, et spécialement des softs de PpHd que j'ai pu lire (asm, C), mais aussi GCC4TI, Code::Blocks etc...). Je trouve ça super bien foutu par rapport à ce que je fais. Ca en dit long...

Souane (./27) :
2) Tu ne nous as pas encore dit quel genre de problèmes tu rencontrais, histoire qu'on puisse t'aiguiller sur les concepts qui te seraient le plus utiles

Merde, Sasume aussi a demandé et j'ai zappé.

Bon concrètement, j'ai vraiment un problème de "j'attaque par où ?" Je vais donc essayer de vous expliquer, mais comme précisément c'est la mouise dans ma tête à ce niveau, ça risque de donner méchamment. Vous allez voir l'étendue des dégats remarque

J'ai donc parlé d'écran d'affichage, de plan et d'objets graphiques de base.

Ok ! Spécifions. On part des plans. Ok, il vont donc contenir une surface. Mais faut l'afficher qqpart. Donc il faut des coordonnées dans l'objet pour savoir où afficher le plan ... non ? A moins que ce soit à la partie du programme qui va afficher ce plan de lui dire (paramètres) ? J'en sais rien...
Puis sur ce plan, je veux des icones, alors je fais comment ? Un tableau dans l'objet plan pour mettre des pointeurs vers tous les objets ? Ou les objets directement ? Donc faut que je gère moi-même le dimensionnement du tableau dynamiquement ? et raaah faut que je remette le nez dans la syntaxe de new d'ailleurs... ah ben oué, faudra que je stocke un pointeur vers tout ce que je vais ouvrir Mais où stoquer pour désallouer proprement en sortant de cette partie du programme ?!? zerajzkleghrazljkth vfeizkrgtybmzn ijgùamz'l ij,bç PUTAIN!!!!!!!!

dès que j'essaye d'avancer, je me paume au bout de deux minutes de réflexion, je ne sais pas quels sont les bons choix à faire. Je ne sais surtout pas comment avancer et fixer mes choix après m'être dit : "je choisis ça parce que ça sera la meilleure chose à faire dans mon cas, ou du moins, un choix qui fera que j'y arriverai au final".
En fait, j'ai l'impression que je n'arrive pas à m'arrêter à des concepts généralistes, et que j'essaye d'envisager directement l'implémentation alors que je ne devrais pas.

Mais où mettre cette limite à l'analyse ? Par exemple, en top-down, je veux une esquisse de mon écran (physique) jusqu'à mes objets (sprites & co). Je m'arrête où ? A "icone" "sprite" "plan", ou à "attribut virtuel de la classe dérivée du sous-objet de mes deux du pixel tranparent quand ya ça qui se passe" ?

[13:40:46] <Folco> Ecrire des specs, mais pas encore du code, mais les specs de quoi ? De l'affichage d'un sprite ? Osef au début, alors il faut s'arrêter où ?[13:41:08] <Folco> Visiblement, on descend en approfondissant à chaque fois. Mais comment définir ces barières d'analyse etc... mystère...

Mais peut-être n'est-ce même pas la bonne question à poser ? J'en sais rien...

et comme je n'y connait rien, je me plante dans mes projets après un certain avancement... J'en ai donc marre, je ne peut rien mener à bout de cette manière...

Un conseil qui m'aurait été utile quand je suis passé de la TI au PC et qui pourrait peut être t'être utile, c'est de t'en foutre totalement des performances. Mais vraiment quoi.
Moi, même en savant que faire des optimisations prématurément c'était mal, j'avais un pincement au coeur quand je faisais un truc pas optimisé. Peut être que toi aussi inconsciemment ça te bloque et t'empêche de prendre de la hauteur.

Un autre truc qui pourrait t'aider à release, c'est le proverbe "la perfection est l'ennemi du bien" . Il ne faut pas chercher à release un truc parfait (au niveau du code ou des features), sinon tu release rien (à part des tuto...).

Pour le coup, c'est là où ma compétence s'arrête... Je pense que j'ai à peu près tendance à me poser les mêmes questions que toi (sauf que j'aime bien coder ce qu'il est possible de coder et ensuite aviser, histoire de repousser ces questions à plus tard ) Typiquement, j'aime bien commencer par définir puis coder les classes du "Modèle" (ie. les classes qui s'occupent des données au coeur du programme et non de l'interface graphique ou des trucs compliqués) et ensuite je construis plus ou moins au feeling petit à petit (mais je ne fais jamais des applis complexes par contre )