Concevoir un programme de A à Z - Page 4

Sasume :

Il commence par comparer le design planifié et le design évolutif.
Design planifié = on décide du désign à l'avance et ensuite on code
Design évolutif = on code, et au fur et à mesure le design apparaît de lui-même

Selon lui, dans un monde idéal ou tu as des designers qui pensent à tout et des clients qui ne changent pas d'avis au cours d'un projet, le design planifié est une très bonne chose. L'inconvénient, c'est que si les besoins changent en cours de route, il est énormément difficile de tout changer avec un mauvais design au départ.

De l'autre côté, il y a le design évolutif, qui a en général tendance à être le vrai bordel, avec le problème que plus le projet grossit, plus c'est dur à débugger et plus ça devient chaotique.

Cependant, selon lui XP (extreme programming, une méthode de développement agile pas mal à la mode ces dernières années) rend le design évolutif plausible, rentable et même intéressant. Pour plus de détails sur XP : http://en.wikipedia.org/wiki/Extreme_Programming

Par exemple, XP est basée sur deux philosophies : toujours viser un code le plus simple possible, et ne rien implémenter à l'avance pour une fonctionnalité dont on aura plus tard. En combinant également ça à des tests permanents, beaucoup de prototypage et tout un tas d'autres trucs, ça semble marcher.

Il ajoute cependant des idées un peu moins conventionnellement rattachées à XP : par exemple qu'utiliser, même avec XP, des design patterns peut être utile, ainsi qu'une documentation UML minimaliste, voire de réfléchir à certaines choses concernant design à l'avance (surtout quand ne pas le faire pose de gros risques pour plus tard). Donc, son interprétation d'XP, c'est surtout que, même si tu peux (et dois) faire du design, tu ne le considères surtout pas comme statique et n'hésites pas à tout changer si nécessaire Donc en gros il combine la *philosophie* d'XP avec des techniques plus traditionnelles (mais également celles d'XP)

Kevin Kofler (./85) :
si le projet n'a pas une décomposition en modules évidente dès le départ

Bah donc tu ne commences pas à coder immédiatement, tu es obligé de faire un travail préalable...

Kevin Kofler (./85) :
Si. On implémente une charge à la fois de manière incrémentelle

Idem, ça veut dire que tu as fais un travail de segmentation et de modularisation, avec affectation des tâches au préalable... les développeurs ne vont pas deviner par magie ce sur quoi travaillent les autres, ni le degré de modularisation accepté par chacun d'entre eux...

Kevin Kofler (./85) :
Pourtant il y a plusieurs de mes projets codés comme ça qui ont plusieurs années, et j'arrive toujours à les maintenir.

Parce que tu es seul dessus, et que tu ne vis que pour le développement... tu n'as pas d'autres activités, une famille, des repas équilibrés...

Kevin Kofler (./85) :

Nil (./83) :
Ca ne peut pas marcher en équipe

Si, il y a bien moyen de coder de manière purement incrémentelle en équipe, du moins dans beaucoup de cas. Évidemment, si l'équipe n'a pas l'habitude de travailler ensemble, si tous les développeurs codent en même temps, si le projet n'a pas une décomposition en modules évidente dès le départ (ou si l'interaction entre les modules est trop forte) et si les outils utilisés pour coder ne permettent pas de merges efficaces, ça va être le désastre. Mais il y a plusieurs moyens de s'en sortir.

Ça fait quand même beaucoup de conditions à réunir, je trouve

Par exemple développer en paire avec une personne qui code le jour et une la nuit (déjà essayé, par exemple sur ld-tigcc (même si ce n'était pas forcément un projet "conçu en codant" et même si Sebastian l'avait commencé seul, donc ce n'est pas forcément un bon exemple): d'habitude, Sebastian codait le jour et moi la nuit et on s'échangeait les patches par mail, il n'y avait presque pas de conflits entre les patches parce que chacun travaillait à son tour).

Et si vous êtes 12 sur le projet, vous codez 2 heures par jour ? #efficace#

Pourtant il y a plusieurs de mes projets codés comme ça qui ont plusieurs années, et j'arrive toujours à les maintenir. (Il y a un seul projet que je n'arrive plus à maintenir, c'est Tokens89: un bordel infame de bidouillages fragiles parce que je n'y connaissais rien au parsing à l'époque, du code qui dépend d'à peu près toutes les propriétés tordues du VB5 (langage propriétaire et obsolète), bref faudrait tout réécrire. Ce n'est pas du tout un problème d'organisation du code.)

je pense que Nil parlait de projets un peu plus gros que Backgammon, hein

Kevin Kofler (./85) :
si l'équipe n'a pas l'habitude de travailler ensemble

à peu près toujours, non ?

Kevin Kofler (./85) :
si tous les développeurs codent en même temps

là aussi, à peu près toujours ^^ si on met plusieurs développeurs sur un projet, c'est pour qu'il avance plus vite ; pas pour étaler dans le temps

Kevin Kofler (./85) :
si le projet n'a pas une décomposition en modules évidente dès le départ

hélas

Kevin Kofler (./85) :
si l'interaction entre les modules est trop forte

hélas² ²

Kevin Kofler (./85) :
si les outils utilisés pour coder ne permettent pas de merges efficaces

ergh

Kevin Kofler (./85) :
ça va être le désastre

oh oui

Kevin Kofler (./85) :
développer en paire avec une personne qui code le jour et une la nuit

mouarf dans le monde du travail, c'est pas tous les "jours" que ça arrive, ça ^^
serait marrant, cela dit ^^ veux bien être dans l'équipe de nuit, des fois, si ça paye plus ^^

Kevin Kofler (./85) :
Quand les charges exactes ne sont pas connues dès le départ, c'est tout de suite beaucoup plus difficile

hélas^3 ^^

Bon, je peux revenir au topic svp ?

Je me dis que puisque mon gestionnaire de tâches est un objet qui lance différent objets correspondant aux différentes "étapes" du jeu, tout mon code sera dans des méthodes. C'est grave docteur ? J'y suis pas habitué en fait. Mais c'est pas ça qui fait la puissance d'un langage objet, pouvoir utiliser partout la puissance des classes & cie justement ?

Ben tu veux qu'il soit où ton code à part dans des méthodes ? Dans main? (désolée si c'est une question de noob)

N'ayant jamais pensé à mettre la gestion des process dans des objets, je voyait les choses autrement : du code style C faisant appel à des objets pour les dessins et quelques trucs. Donc oui, beaucoup de code en-dehors des méthodes. Là, à part l'initialisation et la clôture de la SDL, je n'ai pas de code hors-méthode. Rah j'en suis tout chose

Souane (./91) :
Cependant, selon lui XP (extreme programming, une méthode de développement agile pas mal à la mode ces dernières années) rend le design évolutif plausible, rentable et même intéressant. Pour plus de détails sur XP : http://en.wikipedia.org/wiki/Extreme_Programming

Bah, ça reste très organisé et contraignant, mon courant c'est plutôt http://en.wikipedia.org/wiki/Cowboy_coding. Il y a quelques idées de l'Extreme Programming avec lesquelles je suis d'accord (par exemple qu'il faut s'attendre à ce que les exigences puissent changer, on ne peut pas tout prévoir d'avance), d'autres qui sont bonnes, mais à mon avis pas indispensables (programmer en paires et faire des revues du code de l'autre, ça permet effectivement de trouver des erreurs assez rapidement (avec Sebastian, il a souvent trouvé mes erreurs et moi les siennes; avec Romain, ça a été plus à sens unique, je trouvais d'innombrables d'erreurs dans ce qu'il pondait), mais quand on est tout seul, on arrive quand-même à produire quelque chose) et d'autres encore que je ne partage pas du tout (unit tests, pour moi c'est une pure perte de temps).

Nil (./92) :

Kevin Kofler (./85) :
si le projet n'a pas une décomposition en modules évidente dès le départ

Bah donc tu ne commences pas à coder immédiatement, tu es obligé de faire un travail préalable...

"Travail" d'une minute si la décomposition est vraiment évidente. Sinon, ben c'est que le projet n'a pas une décomposition évidente, justement.

Kevin Kofler (./85) :
Si. On implémente une charge à la fois de manière incrémentelle

Idem, ça veut dire que tu as fais un travail de segmentation et de modularisation, avec affectation des tâches au préalable... les développeurs ne vont pas deviner par magie ce sur quoi travaillent les autres, ni le degré de modularisation accepté par chacun d'entre eux...

Le cahier de charges, c'est le client qui le prépare. Ensuite, bah, dans une équipe qui fonctionne bien, le développeur dit sur IRC (voire gueule dans la salle si l'équipe est sur place) "je suis en train de me plonger sur la charge nº14" et il commence à coder, les autres savent sur quoi il travaille et qu'il vaut mieux ne pas y toucher. (C'est comme ça qu'est coordonné le travail de packaging de KDE sous Fedora par exemple, #fedora-kde est très pratique pour ça.) Pas besoin de segmenter à l'avance. Et pour que les autres voient ce qui est en train de se passer, la solution s'appelle "commit early, commit often" (dont je suis un fervent défenseur).

Flanker (./93) :
Ça fait quand même beaucoup de conditions à réunir, je trouve

Beaucoup de conditions pour un échec. Même le contraire d'une ou deux de ces propositions peut suffire pour faire fonctionner le développement incrémentel.

Et si vous êtes 12 sur le projet, vous codez 2 heures par jour ? #efficace#

Non, au maximum on peut segmenter la journée en 3 ou 4, mais diviser le risque de conflits par (par exemple, en prenant des tours de 8 heures) 3²=9 (le risque de conflits entre n développeurs codant en même temps étant de O(n²)) peut déjà être très utile.

Et il y a aussi d'autres cas où fonctionner par tours peut être utile, par exemple quand l'embouteillage n'est pas le développement, mais la compilation. On a eu nos compilations de paquetages KDE pour Fedora pendant plus d'une journée où Than Ngo, Lukáš Tinkl et Jaroslav Řezník ont travaillé le long de la journée européenne et Rex Dieter (aux USA) et moi pendant la nuit européenne, ça permettait de garder le build system occupé.

je pense que Nil parlait de projets un peu plus gros que Backgammon, hein

KTIGCC, c'est petit? Il y a un fichier source de 6306 lignes (et plusieurs autres, plus petits)!

squale92 (./94) :

Kevin Kofler (./85) :
si l'équipe n'a pas l'habitude de travailler ensemble

à peu près toujours, non ?

Bah, c'est le problème de l'entreprise si elle refait de nouvelles équipes sans arrêt. Il faut laisser le temps aux équipes de se connaître, ça augmente de loin la productivité (sauf si on tombe sur une "équipe" de genre Lionel et moi ).

Kevin Kofler (./85) :
si tous les développeurs codent en même temps

là aussi, à peu près toujours ^^ si on met plusieurs développeurs sur un projet, c'est pour qu'il avance plus vite ; pas pour étaler dans le temps

Tes développeurs ne dorment jamais? Ça permet déjà de segmenter le temps. Et comme déjà dit, il peut être avantageux d'avoir des équipes à 2 endroits du globe, pour exploiter les fuseaux horaires. (Cela dit, il doit bien y avoir des codeurs qui préfèrent coder la nuit, j'en fais partie. )

Kevin Kofler (./85) :
si les outils utilisés pour coder ne permettent pas de merges efficaces

ergh

=> faut utiliser de meilleurs outils…

Kevin Kofler (./85) :
Quand les charges exactes ne sont pas connues dès le départ, c'est tout de suite beaucoup plus difficile

hélas^3 ^^

Donc exit le planning à l'avance, c'est ce que j'ai dit tout le long.

Folco (./95) :
Je me dis que puisque mon gestionnaire de tâches est un objet qui lance différent objets correspondant aux différentes "étapes" du jeu, tout mon code sera dans des méthodes. C'est grave docteur ? J'y suis pas habitué en fait. Mais c'est pas ça qui fait la puissance d'un langage objet, pouvoir utiliser partout la puissance des classes & cie justement ?

Dans la logique OO, c'est tout à fait normal, en OO pur, tout le code est dans des méthodes, pas dans des procédures.

Folco (./97) :
N'ayant jamais pensé à mettre la gestion des process dans des objets, je voyait les choses autrement : du code style C faisant appel à des objets pour les dessins et quelques trucs. Donc oui, beaucoup de code en-dehors des méthodes.

C'est plus mon style, ça. Je pense de manière très procédurale et j'utilise peu les objets, sauf ceux qui sont déjà là (Qt/KDE ).

Là, à part l'initialisation et la clôture de la SDL, je n'ai pas de code hors-méthode. Rah j'en suis tout chose

Très OO ça. Les puristes seront fiers de toi (alors qu'ils risqueraient l'attaque cardiaque devant mon code ).

Ok, cool

sauf si on tombe sur une "équipe" de genre Lionel et moi

Bah ça ressemble plus à deux boxeurs sur un ring oué ^^

Kevin Kofler (./98) :
et Jaroslav Řezník ont travaillé le long de la journée européenne

AAAAAHHHHH qu'apprends-je ?!?!? En fait le yAro il bosse avec Kevin sur Fedora, pu*ain comment il nous l'avait caché

Kevin Kofler (./98) :
KTIGCC, c'est petit? Il y a un fichier source de 6306 lignes (et plusieurs autres, plus petits)!

c'est carrément tout petit ! (je m'attendais à beaucoup plus pour KTIGCC)
Je considère que je travaille sur de tout petits projets, et ils font tous au moins 8000 lignes de code.
Je prends l'exemple de l'application de gestion du personnel qu'on utilise ; c'est une application qui a 15 ans... je ne sais pas combien de lignes de codes ça représente, mais en terme de structure, c'est plus de 750 tables (j'en avais déjà parlé dans un autre topic, et j'ai réussi à trouver le SRE ! c'est un roman )... je te laisse imaginer le travail qu'il y a eu derrière avant de commencer à écrire la première ligne de code...

il parle d'1 seul fichier qui fait 6k lignes, et ça c'est vraiment gros. Au passage, c'est mal d'avoir de aussi gros fichiers, ne serait-ce que du point de vu de temps de compilation (tu change une ligne => tu recompile tout le fichier)

Dites, comment est-ce que je pourrais compter la somme des nombres de lignes des fichiers qui sont dans une arborescence donnée ?
wc ne traverse pas récursivement l’arborescence, cat non plus

wc `find * | grep -E ".c$"` ?

Oui mais il semble dire qu'il n'y a que ce fichier plus quelques uns bien moindres... et on parlait de taille de projet, pas de fichier...
Et je te rejoins totalement sur l'usage de gros fichiers...

edit: double cross

Sasume (./103) :
Dites, comment est-ce que je pourrais compter la somme des nombres de lignes des fichiers qui sont dans une arborescence donnée ?
wc ne traverse pas récursivement l’arborescence, cat non plus

Moi je fais:

find . "(" -name "*.m" -or -name "*.mm" -or -name "*.py" -or -name "*.lua" -or -name "*.h" -or -name "*.cpp" ")" -print | xargs wc -l

Autre solution : t'ouvre tous les fichiers concernés dans le projet d'un IDE qui te répond dans les "propriétés du projet" ^^

./103: je ferais comme ./106, `find ... | xargs wc -l`.

Je me pose une question de conception (encore une fois, et c'est sûrement pas fini).

J'ai une classe Screen (là où est logé l'écran physique géré par SDL) et une classe Plane (dans laquelle écrivent les modules du jeu, en faisant s'y afficher les objets).

Donc :
- Si je délègue l'affichage d'un Plane à Screen, ça veut dire que Plane doit fournir des données genre largeur, hauteur (SDL_Rect*), adresse de l'image. Les données comme largeur et hauteur de Plane me semblent un peu trop "perso" pour que Screen doive se débrouiller avec pour y arriver. Même avec des accesseurs, ça lui en fait savoir beaucoup sur une autre classe, c'est pas très "hermétique".
- Si je fais qu'un Plane sait s'afficher tout seul dans un Screen, il doit alors connaitre l'adresse du dit Screen (via un accesseur de screen) et son type (SDL_Surface*). Pour le coup, je trouve que Plane a besoin de renseignement très typés pour pouvoir s'afficher, ça veut dire que mes planes ne sont capables de s'afficher que par SDL etc... Encore une fois, je trouve que ça fait partager beaucoup de données d'une autre classe.

On fait comment quand c'est comme ça ? Ca serait possible, utile et pas trop lourd de s'amuser à séparer complètement le moteur de jeu de SDL (abstraction totale entre le moteur de rendu et l'affichage physique) ? Ou est-ce que ça devient vraiment s'embêter pour rien par purisme ?

Je pense que c’est pas mal de donner la possibilité à ton Plane de s’afficher tout seul, en utilisant le Screen. D’ailleurs tu pourrais avoir une classe GraphicComponent qui fournit au moins une opération (virtuelle pure) : paint(Screen) qui réalise son propre affichage dans le screen qui lui est fourni. Et tous tes composants graphiques (ta classe Plane, mais peut-être aussi ta classe Icon ou autre) dériveraient de cette classe, en implémentant à chaque fois leur façon de s’afficher.
C’est une façon de faire que l’on retrouve souvent dans les bibliothèques graphiques (comme Qt ou Swing).

Tes objets ne seront pas forcément dépendants de SDL, ils seront seulement dépendant de Screen. Après, c’est à toi de voir ce que tu exposes dans Screen pour ne pas créer d’autres dépendances…

En fait, je propose cette solution, mais l’autre (Screen se charge d’afficher les objets) peut être envisagée aussi, si tu n’as pas trop d’objets différents et que tu as vraiment la flemme d’écrire ta couche d’abstraction de SDL (ce que l’on peut comprendre, quoique tu dois avoir besoin de quelques primitives comme drawImage et drawText, pas beaucoup plus, si ?).

Sasume (./111) :
tu dois avoir besoin de quelques primitives comme drawImage et drawText, pas beaucoup plus, si ?

C'est tout en effet. Je réfléchis à ta solution, le coup du GraphicComponent me parait pas mal.

C’est une bonne idée en générale de définir des interfaces minimalistes. Je dis interfaces au sens Java, ce qui correspond aux classes ne contenant que des méthodes virtuelles pures en C++. Elles définissent une sorte de contrat : tout objet qui implémente cette interface (qui hérite de cette classe abstraite, en C++) devra fournir les services correspondant aux opérations de l’interface.

Là, ton interface GraphicComponent pourrait très bien n’avoir qu’une opération : paint(Screen).
Et tous les objets qui sont capables de se dessiner hériteront de cette classe abstraite et implémenteront ses opérations.

De l’autre côté, quand tu dois afficher des objets, manipule les à travers l’interface GraphicComponent (GraphicComponent *plane = new Plane(); plane->paint(screen); ), ça permet de contraindre vraiment leur utilisation à ce qu’elle devrait être.

(je suis désolé il est tard pour moi et j’ai la flemme de mieux expliquer mais normalement ce que je viens de dire est assez important)

J'en ai l'impression, et tu abordes quelque chose dont j'ai lu la théorie sans en concevoir l'intérêt : les classes abstraites et les fonctions virtuelles. Ce n'est sûrement pas là pour les chiens, mais je ne sais pas ce que ça peut m'apporter... A réfléchir.

hmm la virtualisation a à voir avec l'héritage (il n'aime pas que j'hérite d'une classe dont le destructeur n'est pas virtuel... faut vraiment que je reprenne le bouquin à ce sujet).

Les classes abstraites : l'intérêt c'est que certaines méthodes ne sont pas implémentées mais elles imposent aux sous-classes concrètes de les implémenter.

L'interface c'est la même chose sauf qu'aucune méthode n'est implémentée et qu'il n'y a pas de variable non plus (attributs). En Java, contrairement aux classes abstraites, une classe peut implémenter plusieurs interfaces (alors qu'une classe ne peut descendre que d'une seule super classe... je crois que ce n'est pas le cas en C++ par contre).

Un exemple de classe abstraite que j'ai utilisée dans un projet : Shape. Elle a comme sous-classe Circle, Square et d'autres, qui ont plein d'opérations en commun mais qui sont souvent implémentées totalement différemment (par exemple, on ne dessine pas du tout un carré comme un cercle, on ne calcule pas son aire de la même façon, etc.) Pour autant, c'est utile d'avoir une superclasse abstraite, d'une part pour être sûr que Circle et Square respectent leur contrat de base (avoir une méthode pour les dessiner et une méthode pour calculer leur aire), et d'autre part parce que le fait d'avoir une superclasse est pratique si tu veux appliquer quelque chose à un objet Shape peu importe la forme spécifique (ça commence à devenir pratique quand tu as 100 différentes sous-classes, et tu ne vas pas t'amuser à faire des trucs du genre "if (object == (Object) Shape1 OR object == (Object) Shape2 OR ... OR object == (Object) Shape100 )

Les interfaces sont souvent utilisées pour des fonctionnalités moins spécifiques à une seule catégorie d'objets. Par exemple, en java, l'interface Comparable, qui permet de définir quand une instance d'une classe est plus grande qu'une autre, peut être utilisée par à peu près n'importe quel type d'objet (d'où l'intérêt que ce soit une interface), et est aussi très limitée (typiquement une seule méthode) Utiliser une interface permet en particulier de l'appliquer à plusieurs classes sans s'emmêler les pinceaux (encore une fois, ça va t'*obliger* à implémenter certaines méthodes).

Sasume (./103) :
Dites, comment est-ce que je pourrais compter la somme des nombres de lignes des fichiers qui sont dans une arborescence donnée ?
wc ne traverse pas récursivement l’arborescence, cat non plus

Pour KTIGCC, c'est facile, il n'y a pas de sous-dossiers (sauf un sous-dossier images qui ne contient évidemment pas de code, et des sous-dossiers fedora et mingw pour compilation/packaging).

Il y a 15408 lignes de code dans KTIGCC 1 et 17184 dans KTIGCC 2 (et je n'ai pas compté les sorties de uic et moc là).

Souane (./115) :
L'interface c'est la même chose sauf qu'aucune méthode n'est implémentée et qu'il n'y a pas de variable non plus (attributs). En Java, contrairement aux classes abstraites, une classe peut implémenter plusieurs interfaces (alors qu'une classe ne peut descendre que d'une seule super classe... je crois que ce n'est pas le cas en C++ par contre).

Effectivement, le C++ permet l'héritage multiple.

En revanche, on retrouve un fonctionnement similaire au Java avec QObject: un QObject peut hériter de plusieurs objets C++ "normaux" (ce qui comprend aussi les interfaces abstraites), mais d'un seul QObject (qui doit être le premier dans la liste, en gros parce que le C++ ne distingue pas extends et implements, la raison technique précise est plutôt longue à expliquer).

(ça commence à devenir pratique quand tu as 100 différentes sous-classes, et tu ne vas pas t'amuser à faire des trucs du genre "if (object == (Object) Shape1 OR object == (Object) Shape2 OR ... OR object == (Object) Shape100 )

En revanche, if (object instanceof Circle) marche plutôt bien. (En C++, on utiliserait qobject_cast ou dynamic_cast.) Il y a des fois où c'est plus adapté que les méthodes virtuelles. Mais c'est moins "objet".

Kevin Kofler (./117) :

(ça commence à devenir pratique quand tu as 100 différentes sous-classes, et tu ne vas pas t'amuser à faire des trucs du genre "if (object == (Object) Shape1 OR object == (Object) Shape2 OR ... OR object == (Object) Shape100 )

En revanche, if (object instanceof Circle) marche plutôt bien. (En C++, on utiliserait qobject_cast ou dynamic_cast.) Il y a des fois où c'est plus adapté que les méthodes virtuelles. Mais c'est moins "objet".

Certes, certes Mais je voulais plutôt mettre en avant le fait qu'en utilisant une superclasse (abstraite ou non, d'ailleurs) tu n'as pas besoin de mentionner explicitement chacune des sous-classe. Ce qui est quand même mieux (après, en effet, instanceof marche très bien aussi )

À ce propos, j’ai toujours eu le sentiment qu’utiliser instanceof était tricher : si le design est bien fait je ne devrais pas avoir à me préoccuper de savoir si une instance est telle ou telle sous-classe de la classe mère.

Par ailleurs, dans les langages fonctionnels (Caml, Haskell, Scala, etc.) le pattern matching est très utilisé et est même indispensable je pense, pourtant ça ressemble à « instanceof ».

Pensez-vous qu’utiliser instanceof est mal ? Pensez-vous qu’utiliser du pattern matching est mal (de toute façon c’est quasi indispensable) ?

Je ne sais pas si c'était bien ou mal, mais en Java, j'ai déjà utilisé pas mal "instanceof" pour traiter, suivant le type des éléments, des arbres abstraits de syntaxe. C'était clairement le plus pratique à écrire.