Design de projet - Page 2

JackosKing (./28) :
Je pense que tu n'as jamais évolué dans un projet a forte inspiration XP. L'intégration continue rien qu'elle est fantastique.

J'aurais dit utopique. Je viens de bosser sur un projet qui fait intervenir des tas d'équipes fonctionnelles, de développement, de test, d'intégration, qui ne sont géographiquement pas aux mêmes endroits pour des raisons qui ne dépendent pas de nous. Appliquer XP dans ce cas là ? Ok, alors il faudrait jeter les 9/10e les plus intéressants de la méthode pour se plier à nos contraintes : aucun intérêt.

Il est possible de faire de l'XP sur des grosses equipes qui a des fuseaux horraires différents, mais après ca s'adapte pas du jour au lendemain (je l'ai vu en action sur un projet de dimension européenne)
De toute arriver à faire changer les methodes dans une entreprise rien qu'aun sein d'un petit projet est de l'ordre de l'exploit et cela passer par des sacrifice personnel... c'est sur que si les responsables ne souhaitent pas évoluer, on pourra rien faire lol

Folco (./32) :
Merci à tous pour votre temps et votre aide, je vais creuser ça, en tout cas c'est clair, pour mon assembleur, je vais "poser le clavier" après avoir fini ma table (ça c'est que des données), et écrire comment tout devra se passer : ce qu'il me faudra pour traiter les inclusions de fichiers, les macros, les exports, les relogements et autre. Merci encore !

Il faut faire attention a ne pas sur-spécifier ton projet qui dans ce cas là sera une perte de temps

[cross] Oui mais le but n'est pas de passer à XP pour passer à XP, encore faut-il que ça présente un intérêt. Dans le cas du projet que je prenais en exemple, qui existe depuis 7 ans et continue chaque année à prouver la qualité de ses méthodes de développement, je ne vois pas ce qu'XP pourrait apporter de bénéfique.

Un des problèmes de trop "se prendre la tête" quand on travaille seul et sans autre motivation que sa bonne volonté, c'est qu'on a parfois envie/besoin de voir ce qui marche. Et quand on travaille sur des modules indépendants mais qui ne servent à rien tout seuls, on peut être rapidement frustré et laisser tomber. Pour éviter ça, tu peux avoir un squelette de programme qui s'adapte à tes tests. Mettons que tu aies 4 processus qui se suivent (a priori, tu n'auras rien à gérer en parallèle, mais ça revient au même). Pour éviter d'avoir à écrire le contenu de tous les modules propres à chaque processus mais avoir un résultat, tu peux faire retourner directement la valeur voulue. Ainsi, même si ton processus n°1 n'est pas opérationnel, tu triches en faisant retourner à ton bout de code "ce que tu veux" (et non ce qu'il a calculé). Je ne sais pas si c'est clair. Disons que ton squelette, au début, retournera le résultat escompté en "trichant", avec du précalculé et des fonctions "vides". Et tu remplis les trous petit à petit.

Zephyr (./35) :
[cross] Oui mais le but n'est pas de passer à XP pour passer à XP, encore faut-il que ça présente un intérêt. Dans le cas du projet que je prenais en exemple, qui existe depuis 7 ans et continue chaque année à prouver la qualité de ses méthodes de développement, je ne vois pas ce qu'XP pourrait apporter de bénéfique.

Et puis (je vais faire bondir Jackos, mais tant pis ^^) à un projet est aussi associé des méthodes de travail qui ont été spécifiées en amont. Toutes les équipes sont calées sur un rythme donné, qui n'est pas forcément optimal quand on a du recul, mais qu'il serait extrêmement couteux en temps, en coût-homme et en motivation, de modifier fondamentalement. Alors en effet, si toutes les équipes étaient au top de la méthodologie, ça ne serait pas un problème ; mais il faut compter avec l'existant. Ce qui ne veut pas dire laisser de côté tout ce qui a été mis en place au fil du temps, mais peut-être le réserver pour les nouveaux projets, pensés ainsi dès le début. Sinon, c'est un coup à passer son temps à modifier la méthodologie pour être optimal mais, au final, ne rien produire parce qu'on s'est trompé de combat.

Il faut aussi faire avec un problème (qui existe dans toutes les branches, mais qui explose avec les nouvelles technologies) et qui est le décalage générationnel. Quand je vois la façon dont j'ai abordé la POO en Java (JDK 1.2 à l'époque) en 2000-2001 et la façon dont mon frangin l'a abordée deux ans plus tard (JDK 1.5 je crois, mais surtout beaucoup plus de recul sur les méthodes), je n'ose imaginer le décalage avec quelqu'un qui est rentré dans l'info 20 ans avant (enfin, j'y suis confronté tous les jours ; dans mon équipe, on n'est que deux à avoir suivi une "vraie" formation informatique, les autres sont issus de la finance, de l'électronique, il y a un MBA, et un génie-civil (si, si ).

Pour compléter le ./36, c'est d'ailleurs quelque chose qui se fait aussi très souvent dans les gros projets où tous les modules sont éclatés entre plusieurs développeurs / équipes / sous-projets : on fait des "bouchons" qui permettent de tester chaque module séparément sans dépendre des autres (et donc sans avoir besoin d'attendre les autres équipes, par exemple).

Réaliser un bouchon est facile à partir du moment où on a identifié en amont les fonctionnalités auxquelles doit répondre le module qu'il remplace (on a la liste de ce que le module doit pouvoir faire, on peut donc faire un bouchon qui "simule" tout ça en envoyant des résultats bidon, comme vient d'expliquer Nil).

je confirme

C'est vrai que le coup d'utiliser des « bouchons », ça aide pas mal à avoir un truc qui tourne un peu, et ça, c'est tout de même bien agréable

Sinon, pour des gros projets, c'est souvent bien plus profitable d'avoir un code propre bien découpé en sous-fonctions que d'avoir un code super optimisé (à part éventuellement pour les quelques routines critiques).
Quand je me suis lancé dans des « gros » projets (quelques dizaines de milliers de lignes de code), j'ai toujours essayé de faire pas mal de fichiers sources (chacun regroupant les fonctions sur un même thème), éventuellement eux-même regroupés dans des dossiers. Et après avoir fait ce découpage, j'écris les définitions des premières fonctions avec leurs entrées et leurs sorties.

(évidemment, avant tout, je réfléchis longuement à ce que je veux obtenir et à la structure générale du code, en notant tout ce que je veux faire)

Zephyr (./38) :
Réaliser un bouchon est facile à partir du moment où on a identifié en amont les fonctionnalités auxquelles doit répondre le module qu'il remplace (on a la liste de ce que le module doit pouvoir faire, on peut donc faire un bouchon qui "simule" tout ça en envoyant des résultats bidon, comme vient d'expliquer Nil).

L'interet aussi de pouvoir mettre et faire des bouchons, c'est qu'on peu tester facilement toutes les parties du code, juste en transformant les dits bouchons en modules de tests

Bon, je connais pas les méthodes de dév logiciel étant donné que je me suis surtout formé sur le tas, donc il se peut que je raconte des conneries, mais y'a quelque chose que je voudrais souligner :

Je trouve que beaucoup de 'méthodes' abusent du "top-down", en faisant croire que la réflexion/planification préalable c'est 99% du boulot et qu'une fois que c'est fait, la prog se fait toute seule ou presque. Je ne dis pas qu'il ne faut pas réfléchir avant de coder, c'est indispensable au contraire, mais je pense aussi qu'il est dangereux de trop s'abstraire de l'implémentation :

- commencer à implémenter (en partie) assez tôt, ça permet de vérifier la viabilité des choix
- et surtout, ne raisonner que sur papier, c'est un excellent moyen de faire un système formidable sur papier, mais "surconçu", lourd, lent, voire irréalisable en pratique.

Avec la puissance des machines actuelles, on a pas mal de marge de manœuvre, mais sur des plateformes limitées comme une TI (ou pire, des systèmes embarqués à faible coût), il est illusoire de séparer planification et implémentation : faut avoir en tête les contraintes matérielles dès le début, à partir du moment où on écrit le cahier des charges. Savoir ce qu'on veut c'est bien, savoir ce qu'on peut faire c'est essentiel.

(oui, ceci est indirectement un coup de gueule déguisé contre les soi-disant profs d'algo qui commencent leur cour par "on va supposer qu'on a une machine avec une mémoire illimitée", ceux qui prétendent "n'importe qui peut coder, y'a que le design qui compte", et les supérieurs qui te disent "au fait j'ai promis ça, ça et ça comme features au client, je sais pas comment faire mais je suis sûr que tu vas trouver un moyen pour l'implémenter". 3,2,1, flammez )

Zerosquare (./42) :
mais sur des plateformes limitées comme une TI (ou pire, des systèmes embarqués à faible coût),

Heu, je crois que les TIs sont bien pire que des systems embarqué faible coup ^^ (meme si on peut avoir des choses droles sur ce genre de machines ^^ (genre 8Ko de RAM accessible par le CPU, et 128Mo de SDRAM accessible que via une liaison série )

Je ne vais pas répéter ce qui a été dit mais Martial, si tu veux, je pense que le mieux serait de poser ici les éléments de ton projet, qu'on puisse te donner un retour critique sur sa gestion (et pas sur le projet lui même hein)

Zerosquare (./42) :
- commencer à implémenter (en partie) assez tôt, ça permet de vérifier la viabilité des choix

C'est entièrement vrai, et c'est une étape qui est souvent obligatoire aussi dans le cadre de gros projets : on parle de prototypes de faisabilité. Tous les algorithmes un peu complexes que tu as identifié lors de ta conception peuvent faire l'objet d'un prototype qui implémente juste l'algo de façon minimale, pour vérifier qu'il tourne bien et avec les performances attendues. Tant qu'à faire, on essaie de le coder de façon à pouvoir l'intégrer directement au projet par la suite (sous forme de lib par exemple) histoire de ne pas avoir à le réécrire lors de son intégration au programme complet.

Pour l'anecdote, c'est au même moment qu'on fait aussi des maquettes IHM, c'est à dire une démarche un peu comparable au niveau des "écrans" (formulaires, interface, etc) de l'application : on réalise des écrans sans code derrière, juste avec les boutons et un aspect visuel proche de celui de l'appli finale, pour permette au client de s'exprimer le plus tôt possible si ça ne lui convient pas. Dans un projet en solo, ça devient nettement moins utile mais ça peut permettre de s'éclaircir un peu les idées en s'obligeant à présenter le programme par un autre bout (l'aspect "utilisateur", à mettre en parallèle avec toutes les fonctionnalités auxquelles il est censé avoir accès).

Avec la puissance des machines actuelles, on a pas mal de marge de manœuvre, mais sur des plateformes limitées comme une TI (ou pire, des systèmes embarqués à faible coût), il est illusoire de séparer planification et implémentation : faut avoir en tête les contraintes matérielles dès le début, à partir du moment où on écrit le cahier des charges. Savoir ce qu'on veut c'est bien, savoir ce qu'on peut faire c'est essentiel.

Moui... on surestime parfois la puissance des plateformes, mais c'est une erreur très facile à éviter à mon avis. Je ne vois aucun problème à prendre en compte la faible puissance d'une Ti lors d'une conception, quitte à faire quelques prototypes pour les points vraiment critiques.

Zephyr (./45) :
Pour l'anecdote, c'est au même moment qu'on fait aussi des maquettes IHM, c'est à dire une démarche un peu comparable au niveau des "écrans" (formulaires, interface, etc) de l'application : on réalise des écrans sans code derrière, juste avec les boutons et un aspect visuel proche de celui de l'appli finale, pour permette au client de s'exprimer le plus tôt possible si ça ne lui convient pas. Dans un projet en solo, ça devient nettement moins utile mais ça peut permettre de s'éclaircir un peu les idées en s'obligeant à présenter le programme par un autre bout (l'aspect "utilisateur", à mettre en parallèle avec toutes les fonctionnalités auxquelles il est censé avoir accès).

Dans une relation client/développeur, c'est d'ailleurs les maquettes de l'IHM qui servent à exprimer énormément de besoins qui vont au-delà de l'interface, principalement parce que ça "parle" plus au client que tout le reste. Je connais même des équipes qui intègrent le développement de l'IHM à l'étape d'analyse (en dernière partie) pour être certain de n'avoir rien oublié de crucial au niveau de la logique de l'application. Mais bon, l'IHM d'un compilateur, hem...

Personnellement, quand je code, mon invariant est que le code doit rester compilable, et c'est valable autant quand je code au départ que quand je fais de grosses modifications: évidemment il va se retrouver non-compilable pour de courtes périodes, mais j'essaie de minimiser ces périodes à tout prix.

Pour la conception de départ, ça veut dire que si je code top-down, ce n'est pas du top-down pur (qui fonctionne comme un breadth-first search), mais du depth-first: dès que j'ai besoin d'une fonction, je code d'abord la fonction dont j'ai besoin pour ensuite revenir à la fonction appelante (au pire, un bouchon qui ne fait rien, mais normalement j'essaie de coder la fonction tout de suite). Sinon, je code en bottom-up.

Pour les grosses modifications, ça veut souvent dire écrire des wrappeurs temporaires qui seront jetés quand la réorganisation sera complète.

Même si c'est parfois une contrainte (par exemple des wrappeurs inutiles à long terme, ou l'impossibilité de faire du top-down pur), ça a le gros avantage qu'on trouve tout de suite les erreurs détectables par le compilateur (erreurs de syntaxe etc.) qui seraient sinon cachées par d'autres erreurs, et que souvent on peut même tester le code (alors que du code non-compilable est essentiellement impossible à tester). Dans le cas des modifications, des wrappeurs de compatibilité bien écrits peuvent même garder le code entièrement fonctionnel même quand il est en pleine migration.

tu ne développes jamais en un langage interpreté?

Pareil que KK, sauf que mon critère est le test unitaire

onur (./48) :
tu ne développes jamais en un langage interpreté?

Rarement. Ces langages sont moins efficaces, et puis justement, ça me dérange que des erreurs puissent passer inobservés seulement parce que le code n'a jamais été exécuté, c'est beaucoup plus pratique quand on a un compilateur qui reporte les erreurs immédiatement.

Oui enfin compilation != de code qui marche hein
C'est pour cela que les tests sont indispensables

Kevin Kofler (./50) :
ça me dérange que des erreurs puissent passer inobservés seulement parce que le code n'a jamais été exécuté

Au passage, c'est pas vrai pour tous les langages interprétés : certains vérifient avant de lancer l'exécution, voire directement au cours de la frappe.

Folco (./53) :
Marrant, je suis du genre à laisser pisser dans un premier temps, finir le reste de ce que j'écris, et revenir dessus même longtemps après. C'est une erreur, une faute de discipline quand on code ?

C'est une technique de programmation différente.

Kevin Kofler (./47) :
top-down

Je vous vois souvent avec ce mot, c'est pas ce qu'on appelle l'analyse descendante ? ie j'écris un bout de code qui a besoin de trier une liste, j'écris tout simplement "call TtriList(list)", puis je passe à la suite sans avoir écrit TriList ?

Oui.

Il faut au moins designer TriList quand même, non ?

Ben, il faut avoir une idée de ce que ça va faire, oui.

Kevin Kofler (./47) :
ça a le gros avantage qu'on trouve tout de suite les erreurs détectables par le compilateur (erreurs de syntaxe etc.) qui seraient sinon cachées par d'autres erreurs

Je dirais qu'en assembleur, surtout que je suis très très peu utilisaetur de macros, je ne rencontre pas ce problème.

Oui, tu te tapes des plantages en temps d'exécution à la place. Pas de type-safety, numéros de registres (facile de se tromper, suffit d'une faute de frappe ou d'inattention), tailles des opérandes à spécifier manuellement (idem), mauvais offset de restauration sur la pile etc., tout ça, ça crée des erreurs qui soit ne se produisent pas, soit sont détectées par le compilateur en C.

Folco (./53) :
Marrant, je suis du genre à laisser pisser dans un premier temps, finir le reste de ce que j'écris, et revenir dessus même longtemps après. C'est une erreur, une faute de discipline quand on code ?

Je ne pense pas. Mais mon avis n'est pas celui d'un informaticien qui a plusieurs années de métier... Je ne développe que des petits trucs, sur mon temps libre, comme toi en fait
En ce qui me concerne, tout dépend du contexte, mais j'essaie de ne pas garder trop longtemps des sources qui ne compilent pas, donc je bouche les trous assez vite quand même, et pour les gros truc, j'implémente une fonction vide (ou presque vide).

Kevin Kofler (./47) :
top-down

Je vous vois souvent avec ce mot, c'est pas ce qu'on appelle l'analyse descendante ?

Oui, c'est un peu ça Sauf qu'en fait quand on parle d'analyse descendante, on commence vraiment loin du code, comme ce qu'a décrit Vertyos, pour finir dans les détails d'implémentations.

ie j'écris un bout de code qui a besoin de trier une liste, j'écris tout simplement "call TtriList(list)", puis je passe à la suite sans avoir écrit TriList ? Il faut au moins designer TriList quand même, non ?

Qu'appelles-tu "designer" ?

Je veux donc, en vrac :- assembler plusieurs sources

C'est-à-dire ? Assembler plusieurs fichiers .asm et les coller bout à bout au moment de l'édition de liens ? Ou bien gérer l'inclusion de fichiers ? Au fait, tu ne comptes pas séparer l'assemblage de l'édition des liens ?

- créer des relogements au format kernel et AMS-native- produire du kernel, du nostub, voire de la chaine exec (bonus, sachant que c'est fait pour PedroM : on peut classer ça à l'état de lubie).

Ces deux points se rejoignent non ? Je les aurais écrits sur la même ligne Sinon, tu n'as pas parlé de lib, mais j'imagine que tu y songeais aussi non ?

Comment je compte m'y prendre ? ...Je dispose déjà d'un handle où sont écrits tous les pointeurs vers les sources ouverts

Ouch, à mon avis tu pars très vite dans un détail qui ne devrait te préoccuper que dans un moment... Et tout le reste de ton post ne porte que sur des détails d'implémentation qui à mon avis sont un peu prématurés (mais je ne me rends pas bien compte du recul que tu as sur ton projet).

Quelques questions/suggestions :
Tu veux transformer un (ou plusieurs) fichier texte en exécutable ;
Pour cela il faut lire le contenu du premier fichier source, et identifier les mots qui y sont inscrits. Quels types de mots peux-tu rencontrer (instructions, labels, opérandes, directives préprocesseur, etc.) ? Tu rencontreras aussi des expressions mathématiques, genre move.w #2*(label2-label1), d0, comment gérer toutes les entrées possible sans écrire un code trop spaghetti ? Surtout que, en outre, tu devras être capable de détecter et gérer les erreurs de syntaxe ! Ensuite, dans tout ce que tu liras, tu trouveras des appels de macro, des labels, des références à des labels non connus, etc. Pour simplifier les choses tu peux faire plusieurs passes sur chaque fichier source : une première où tu fais tout le travail du préprocesseur (inclusion de fichier, substitution des equ et des macros), une deuxième où tu références toutes les déclarations de labels, et une dernière où tu peux lire tout le fichier source et l'assembler en étant sûr de ne rencontrer aucun symbole inconnu. Mais tu peux aussi tout faire en une seule passe, mais ça implique quelques limitations : le programmeur ne pourra pas faire d'appel de macro sans avoir défini la macro auparavant, idem pour les equ, etc. À toi de peser le pour et le contre, de voir si toutes les features que tu veux seront respectées ou non si tu choisis l'une ou l'autre méthode, si tu estimes que ça va être le bordel à coder ou non, si tu estimes que tu vas gagner un sacré temps d'exécution, etc.

On pourrait décomposer l'analyse du texte en deux phases : une première qui permet d'identifier la nature des mots (ou caractères) que tu rencontres (genre ce fichier source contient une directive include, suivie d'une chaîne contenant preos.h, suivie d'un retour à la ligne, suivi d'un identificateur (un nom) ayant pour valeur main, suivi de deux points, suivi d'un retour à la ligne, suivi d'une tabulation, suivi d'un nom d'instruction, suivie d'un point, suivie d'une taille d'opérande correspondant à byte, suivie du signe dièse, suivi d'un nombre, suivi d'une virgule, suivie d'un nom de registre, etc. un peu comme si dans une phrase en français tu décortiquais la nature de mots utilisés et de la ponctuation), et une deuxième phase qui analyserait le sens des mots précédemment reconnus (est-ce qu'ils forment une phrase correcte ?) et te permettrait d'obtenir une information du genre : déclaration d'un label main, instruction move opérant sur des bytes, dont le premier opérande est une valeur immédiate et le second est le registre de données d0. La première phase s'appelle l'analyse lexicale et la seconde s'appelle l'analyse syntaxique (sur Internet tu pourras trouver des ressources là-dessus). Une fois que tu as toutes ces informations, tu peux aisément générer le code correspondant, tu te retrouveras avec un fichier contenant des suites d'opcodes correspondant aux instructions écrites dans le fichier source. Il te restera encore à ajouter les headers qui vont bien avant pour correspondre au format kernel (par exemple), si cela a été spécifié dans le source, par une directive d'assemblage (puisque c'est comme ça que fonctionne a68k si mes souvenirs sont bons, et que tu veux être compatible avec a68k).

Résumons, tu aurais donc 4 étapes :
- Analyse lexicale ;
- Analyse syntaxique ;
- Génération du code ;
- Édition des liens.

On peut reprendre ces étapes, une par une et essayer de les décomposer en processus plus simples, en vérifiant toujours qu'on reste compatible avec les features que tu veux. Par exemple, lors de l'analyse lexicale tu auras à gérer les directives du préprocesseur (include, macro, etc.), tu ne te limiteras pas à reconnaître les différents "mots" (ou caractères) écrits par le programmeur. Ainsi, quand tu rencontreras une directive include, tu devras probablement, plutôt que de l'extraire comme je l'ai écrit plus haut, directement ouvrir le fichier en question (s'il existe...) et aller y lire le prochain lexème (c'est comme ça qu'on appelle les différents mot ou caractères qui ont un sens différent pour ton assembleur (les identificateurs, les nombres, les opérateurs, etc.)) de telle sorte que pour l'analyseur syntaxique tout ça soit complètement transparent. Comment gérer les equ ? Comment gérer les macros ? Au final, tu vas te retrouver avec tout un tas de symboles définis par le programmeur qui auront des sens différents (des noms de labels, des noms de macros, des equ, etc.). Il serait judicieux de les ranger dans une table, au fur et à mesure où tu les rencontres, et où tu notes toutes les infos que tu as sur eux (par exemple quand tu rencontre le texte SIZE equ 12, tu dois stocker dans ta table de symboles que l'identificateur SIZE correspond à un equ et a pour valeur le texte "12" (ou bien tu le stockes comme un lexème, c'est-à-dire que tu stockes le fait que c'est un nombre qui vaut 12. Ensuite, quand tu rencontreras ce symbole plus tard dans le texte du fichier source, tu regarderas dans ta table et tu verras qu'il s'agit d'un equ de valeur 12.

Voilà ma démarche à moi

Folco (./56) :
Le problème vient des programmeurs gore qui foutent du code dans les headers.

Pourquoi pas interdire ça tout simplement, si ton assembleur ne sera de toute façon pas compatible GNU as?

Folco (./58) :
Parce que pour assembler du code de Flanker, même si ça me répugne, il faut pouvoir.

C'est à Flanker de s'adapter à ton assembleur s'il compte l'utiliser. Il serait temps que quelqu'un force les programmeurs à abandonner ce style de programmation obsolète!