IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Qui pratique la programmation spontanée ?


Sujet :

Débats sur le développement - Le Best Of

  1. #281
    Membre actif
    Inscrit en
    août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 307
    Points : 255
    Points
    255
    Par défaut
    Citation Envoyé par Nip
    Ben voila on peut faire la conception apres le code, puisque la phase de conception ne sert a rien, tout est logique jusque la, j'arrive a suivre...
    .
    j'avais oublié ça. Je precise bien, je n'ai pas dit que la conception ne sert à rien. On concoit d'abord dans la tête. Ensuite il faut exprimer sa conception. Si c'est possible de l'exprimer directement dans un langage de programmation, c'est pas la peine de passer par UML ou d'autre doc.

  2. #282
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 190
    Points
    1 190
    Par défaut
    Citation Envoyé par kisitomomotene
    Le langage naturel bien structuré est suffisant
    Le but du formalisme est de réduire l'ambiguité liée au langage naturel.

    Citation Envoyé par kisitomomotene
    Tout faux. S'il faut communiquer entre developpeur un code source qui a été ecrit dans l'objectif d'être bien interpreté aussi bien par la machine que par un lecteur Humain peut suffire largement (et c'est possible même si le code à 1 500 000 lignes). Je trouve que UML est plus utile pour communiquer avec des non informaticiens qui font parti d'un projet.
    Hum... j'espère que tu es bien payé si tu es capable de faire ça dans un délai raisonnable
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  3. #283
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 190
    Points
    1 190
    Par défaut
    Citation Envoyé par Nip
    Il y a pas mal de gens qui remettent ca en question, notamment du cote de l'XP, ypicot en parle sur ce post: http://developpez.net/forums/showthread.php?t=217313, c'est assez interessant de regarder ce qui se dit la dessus.
    Oui, je suis d'accord sur le principe d'auto-documentation du code.
    Mais c'est toujours agréable d'avoir une ou deux lignes en haut d'une classe ou d'une fonction pour expliquer à quoi elle sert... Surtout si elle est mal codée
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  4. #284
    Membre actif
    Inscrit en
    août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 307
    Points : 255
    Points
    255
    Par défaut
    Citation Envoyé par zooro
    Hum... j'espère que tu es bien payé si tu es capable de faire ça dans un délai raisonnable
    Je crois que l'objectif des docs et consort c'est de faciliter la maintenance et l'extensibilité d'un soft. Pour corriger un Bug dans un soft ou pour y ajouter/modifier une fonctionnalité, on n'est pas obliger de comprendre le fonctionnement du soft entièrement. On n'est pas obligé de lire les 1 500 000 lignes de codes que ce soft pourrait avoir. Si le soft est programmer "proprement" et si on utilise un IDE riche, franchement je ne vois pas comment des docs supplémentaires et autres UML diagramme pourraient simplifier la correction d'un bug ou la modification d'une fonctionnalité

  5. #285
    Membre expert
    Avatar de LadyWasky
    Femme Profil pro
    Inscrit en
    juin 2004
    Messages
    2 932
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 51
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : juin 2004
    Messages : 2 932
    Points : 3 504
    Points
    3 504
    Par défaut
    En général, pour ce qui es de la documentation du code lui même, même si je suis capable de m'y retrouver dans un code sans commentaires, quelque soit le nombre de lignes de celui-ci, même si le code est un peu tordu, je suis tout de même assez pointilleux sur ces quelques règles élémentaires :
    - Un nom "parlant" pour chaque variable, procedure/fonction ou objet : au moins, on sait de quoi parle la variable, pas besoin de commenter à quoi elle sert si le nommage à été bien réfléchi.
    - sauf pour quelques noms de variables génériques :
    - i, j, k et index pour des compteurs entiers (utilisés pour des boucles);
    - a, b, c, d pour des coefficients dans une fonction mathématique,
    - e ou epsilon pour une tolérance
    - s : pour une chaîne de caractère fourre tout ou temporaire.
    - p pour un pointeur fourre tout ou temporaire
    - r pour un réel // // //
    - trouve : pour un booleen indiquant que l'on a trouvé ce que l'on cherchait
    - x,y,z pour des coordonnées 2D/3D ou u,v pour le résultat d'une projection ou un second système de repère
    - W pour une largeur (Width), H pour une Hauteur.
    - Commenter, même succintement un bloc de code, en particulier :
    - si le bloc représente un algorithme connu, le nom de cet algorithme
    (exemple : "tri à bulle", "tri de shell", "quicksort",
    "projection de Mercator", "distance de Levenshtein")
    - Si la description de la procedure ne tient pas en moins de 3 mots, ou si le nombre de paramètres >3.
    (par exemple, pas besoin de commenter ChargeFichier(),
    on sait à quoi ça sert.... )

    - éviter les blocs de codes qui font plus d'une page de lecture à l'écran, les subdiviser si possible en sous blocs.
    - séparer le code en plusieurs blocs de codes dons les buts sont différents : Interface utilisateur d'un côté, manipulation des données de fichiers d'un autre, acces aux base de données dans un autre, bibliothèque d'utilitaires ailleur, etc... ça évite de se mélanger les pinceaux ey du coup ont sait localiser assez facilement où apporter une évolution ou corriger un bug.

    La première chose dont je m'occupe quand je développe, c'est la structure des données (leur hiérarchies, qu'elles sont elles, les evolutions possibles de cette structure que ce soit pour un fichier binaire, texte ou une base de données), où les placer sur le disque dur, sous quelle forme.
    A partir de là, si cet aspect à été bien réfléchit, 50% du boulot est fait.... y'a plus qu'à. Personellement, je me passe de papier pour cette étape, parce qu'il y a toujours des ajustements à faire, mais dans un groupe j'admet qu'un certain formalisme, quitte à reboucler par la suite, est nécessaire pour que tout le monde parte sur la même base solide.
    Que la documentation soit faite avant ou après le projet, ce n'est pas la question, le tout est que la documentation soit faite à un moment donné ou à un autre, et BIEN faite : c'est à dire détaillée et reflétant ce qu'elles sont une fois le projet terminé.. Même dans des grosses boites où les formalismes officiels sont soit disant de rigueur (je cite carrément GFI ou Cap Gémini), j'ai vu des documentations merdiquement scandaleuses à ce niveau... Bref on se fout de la méthode, c'est ce avec quoi vous vous retrouvez entre les mains une fois le projet achevé qui compte : que ce soit fait avec telle ou telle méthode (UML par exemple), on s'en tape, ça doit être du français clair, net, précis, carré, assorti d'un gros schéma mettant en valeur les relations entre les différents fichiers ou tables si nécessaire, avec les noms exacts utilisés dans le code, point final.

    Puis c'est la question de comment y accéder (sécurité (login, mot de passe), cryptage, routines de chargement, de sauvegarde, de mise à jour),
    C'est une phase assez "relax"...

    Puis les routines qui décrivent l'interaction entre les différentes données, les algorithmes qui les manipulent, les procédures qui permettent au code de l'interface d'y accéder où aux données de renvoyer leur état (évènements).
    A partir de cette étape, on peut s'accorder le droit de retoucher les structures de données (première étape), sans oublier d'adapter le code de la seconde, ni (et surtout) de mettre à jour la doc de la première étape si elle à déjà été faite.
    C'est à l'issue de cette étape que je documente ma première étape, celà me permet de prendre du recul par rapport au projet en faisant un break dans le développement proprement dit. Une fois terminé, c'est "peanuts" pour la suite...
    - de là découle l'écriture des classes objets.
    A cette étape, je me fait mes propres composant réseau, graphiques, etc... j'évite comme la peste les composants tierce partie, même freeware ou Open-Source (à l'exception de quelques uns que j'ai testé en long en large et en travers). Ca demande du temps, mais on est jamais aussi bien servi que par soi-même : mon expérience me l'a démontré plus d'une fois --> au moins, si bug il y a, on sait d'où ça vient (et d'une), Un composant développé spécifiquement ne comporte pas 10.000 paramètres inutiles (et de deux), si il y a une évolution à faire sur le composant, il n'y a pas de problême de droit d'auteur, de boite qui à coulé, d'abandon de la boite qui l'a développé, etc...
    Ah, c'est sur, ça rallonge le cycle de développement, mais il faut savoir ce qu'on veut : vite fait mal fait, ou béton maison.

    - l'interface utilisateur est soignée et fignolée en dernier lieu en rebouclant avec les utilisateurs en leur demandant leur avis (certains préfèrent des gros boutons, d'autres de la couleur, des alertes). L'accent est mis ici sur la facilité de prise en main, pas la peine d'embarasser l'utilisateur avec une interface où les menus se déroulent au kilomètre : l'utilisateur DOIT pouvoir s'y retrouver sans se plonger dans une doc. Contre exemple dans mon administration : Lotus Notes, belle merde....

    Au final, il y a un CD d'installation, une doc utilisateur papier, une doc utilisateur électronique, la doc qui va bien pour reprendre le bébé derrière, les sources, (l'outil de dev qui à servi est conservé précieusement à cet effet...), et roule ma poule...

    Je vous garantie que cette approche permet un développement "au-fil de l'eau" vraiment efficace... Je ne m'embarasse effectivement pas de formalismes "officiels", mais j'ai quand même les miens, que je me suis forgé sur ma propre façon d'aboder le développement, ma personalité, mon tempérament, etc...

    Encore une fois, on s'en moque de savoir comment celà à été fait, ce qui compte c'est le résultat non ?
    TOUT formaliser sur le papier AVANT de se lancer peut en rassurer certains, tout le monde n'en a pas besoin... Moi je n'en ai pas besoin et j'ai une trentaine de logiciels (réseau, système, bases de données, graphismes, cartographie, scientifique, sécurité, etc...) qui tournent sans bugs, sans planter depuis, pour certaines, 12 ans ! Et pour la plus ancienne qui à tourné sur Win95, elle a été testé sur la béta de vista sans anicroche, on l'a juste recompilée avec 2-3 modifs pour pour avoir un look à la XP : 1 heure de boulot...

    Bonjour

    Dans ce thread, on retrouve souvent : "Je suis le seul dév (j'ai pas vu...), je n'ai pas besoin d'utiliser les formalismes (je rajoute "officiels" et je répond : vrai) et tout coucher sur papier. (avant de développer, ben non...)"

    Prions pour que le client ne redonne pas l'application, pour une évolution ou une migration, à un autre informaticien...ben voyons... comme si la qualité de la doc était conditionné par la méthode de dev utilisée : "si c'est pasun truc de "pro" officiel qu'on voit dans les bouquins de la FNAC ou exposé dans les amphis, c'est caca", bien sur, bien sur... n'importe quoi... )
    Citation Envoyé par duj
    Je connais 2 genres de programmeurs :

    1. ceux qui font de la "programmation spontanée" et qui rament pendant des jours dans un code merdique à creuver. Qui ne comprennent pas la moindre ligne du code qu'ils ont écrit le jour d'avant et dans lequel ils cherchent un bugs, bien évidemment.
    Ce sont les mêmes qui bien sûr commencent directement à taper, sans la moindre reflexion préalable (ben oui, ils sont en quelque sorte le programme).
    Finalement, ils abandonnent... (et demande à un mec de la catégorie 2 de les aider, et le mieux est de tout recommencer)

    2. Ceux qui prennent leur temps de tout plannifer et de concevoir avant de commencer à implémenter, qui connaissent déjà le noms de toutes les fonctions (methodes) et leurs spécifications. Bref, quand ils commencent à taper, ils n'ont aucun doute sur le fonctionnement final. Ils codent de manière claire et commentent le plus possible. Si parfois, il y a une erreur, ils la trouvent facilement : c'est souvent une faute d'inattention quelquepart où la fonction ne correspond pas à la spécification....

    Généralement, les gens de la catégorie 1 sont déjà au mileu de l'implémentation quand les gens de la catégorie 2 commencent...

    Il n'y a que des amateurs pour penser que la methode de la catégorie 1 est la meilleure! Ou des génis incompris...
    Assez binaire...
    Il y a aussi la catégorie 3, qui sait exactement où elle va et comment elle y va sant tout poser sur le papier avant, il n'y a pas besoin d'être un génie pour ça, c'est juste une histoire d'expérience et de rigueur...

    Et la catégorie 4, qui planifie tout (pas forcément bien, sans avoir une expérience des obstacles techniques qu'elle rencontrera lors du developpement) et qui derrière soit ne sait pas coder ou bien code "une chose" différente de ce qu'elle a planifié. J'ai déjà vu, merci pour le résultat...

    Bref, je suis un peu plus d'accord avec [B]Hachesse [/Bpour la remarque qu'il fait après, mais :
    Citation Envoyé par hachesse
    C'est pour cette raison qu'il existe des notations standardisées tel que UML pour que tout le monde puisse parler le meme langage
    D'accord aussi,
    pour les équipe >10 personnes : notations standardisées
    pour les équipe <=10 ça dépend si l'équipe est formée de gens qui se connaissent bien ou non... rien n'empèche d'utiliser des formalismes maison.
    pour un développeur seul : les formalismes "officiels", on en a rien à cirer..., en avoir oui, peut-être, si ça te chante.
    Des formalismes officieux, oui, au moins un : de la rigueur, être méthodique et ça suffit.
    Citation Envoyé par hachesse
    On ne palre pas forcement de correction de bug, mais simplement d'evolution du programme. Et quand il se passe plusieurs mois entre les 2 intervention, mois durant lesquels tu as travaillé sur d'autre projet, tu ne peu plus avoir le code en tete
    D'ailleurs, si c'est bien programmé, il n'y a pas de bugs...
    Mais sinon, si, même 2 mois après j'arrive à m'y retrouver, même six mois (quelle mémoire hein ?), mais de toute façon, c'est bien de commenter et de laisser une trace (même écrit à la main dans un classeur).
    Citation Envoyé par hachesse
    FAUX, dans ce cas, le moins ce sont les commentaires, celui qui arrive a comprendre un code sans commentaire (et personne ne le peu), c'est lui le plus)
    Si, moi j'y arrive, merci pour le plus...
    j'en ai retouché (recommentés, assainis, réindentés) des codes mal écrits et mal commentés : en général (pas toujours heureusement), ils sont truffés de bugs...
    Et j'admet avoir "lu" comme un bon bouquin des codes sans aucun commentaires mais tellement bien écrits, structurés, etc que ça a été un régal
    Par contre, c'est sur, tout le monde n'est pas capable de "lire" du code comme ça, il faut aussi penser à eux...
    Je me souvient d'une époque où certains pestaient contre le C en disant que le code était illisible, vraiment n'importe quoi : ça dépendait surtout de comment c'était structuré au niveau du code...

    Sinon je suis d'accord avec TOUT le reste de tes commentaires.

    Citation Envoyé par zooro
    Le but du formalisme est de réduire l'ambiguité liée au langage naturel.
    Pour moi, un formalisme, c'est une méthodologie, pas un outil de communication, donc rien à voir une histoire d'ambiguité du langage naturel, qui est effectivement plus que suffisant pour décrire quelque chose de façon clairre.

    Citation Envoyé par kisitomomotene
    Je crois que l'objectif des docs et consort c'est de faciliter la maintenance et l'extensibilité d'un soft. Pour corriger un Bug dans un soft ou pour y ajouter/modifier une fonctionnalité, on n'est pas obliger de comprendre le fonctionnement du soft entièrement. On n'est pas obligé de lire les 1 500 000 lignes de codes que ce soft pourrait avoir. Si le soft est programmer "proprement" et si on utilise un IDE riche, franchement je ne vois pas comment des docs supplémentaires et autres UML diagramme pourraient simplifier la correction d'un bug ou la modification d'une fonctionnalité
    Oui et non, plus ton code est clair moins tu as besoin de doc, mais de la doc c'est toujours utile, même si ton code est nickel, il faut l'admettre... (sans en
    sortir des tonnes inutiles, non plus).
    Pense aux développeurs qui ne savent pas lire le code, comme ça, comme nous quoi... C'est quand même abstrait un bout de code, comme une équation mathématique : si elle est très complexe, les matheux s'en sortiront haut la main et te dirons : "ha, ça ? c'est l'expression du noyau dans la chomologie non abélienne d'un groupe" , pour d'autres, sans commentaires, c'est du chinois... mais avec les commentaires, ça va mieux.

    Citation Envoyé par kisitomomotene
    j'avais oublié ça. Je precise bien, je n'ai pas dit que la conception ne sert à rien. On concoit d'abord dans la tête. Ensuite il faut exprimer sa conception. Si c'est possible de l'exprimer directement dans un langage de programmation, c'est pas la peine de passer par UML ou d'autre doc.
    Alors là, je suis COM-PLE-TE-MENT d'accord. Et au fond, par rapport au sujet, c'est surtout ce point là l'objet de la discorde.

    @Nip : on a pas dit que la phase conception était inutile, t'enfonces pas, on a dit qu'elle ne passait pas forcément par le papier...
    Par contre, à un moment donné ou à un autre, exprimer cette conception sur le papier est important : toi tu préfères cette étape avant de coder pour avoir un base documentaire, d'autres comme kisitomomotene ou moi-même préférons l'exprimer d'abord en lignes de code. Ca n'empêche pas de le faire après, ni de le faire bien.

    Et arrêtez d'être pointilleux sur chaque mot choisis par chacuns parce que je suis absolument sur de ceci :
    - Sur ce fil de discussion, vous êtes (j'ose pas dire nous, j'ai peur qu'on dise que je me prend pour un génie ou que j'ai les chevilles qui gonflent) tous des développeurs d'excellent niveau.
    - Chacun à sa ou ses méthodes de dev qui lui conviennent et conviennent à l'organisation pour laquelle on travaille (sinon on serais déjà chômeurs).
    - Nous avons au moins un point commun : le souci de bien faire (ça c'est important...)
    - Les formalismes, il en faut, de la doc aussi, mais en ce qui concerne les formalismes ils peuvent prendre des formes très variées : ça dépend d'un contexte (tout seul, en équipe), de l'expérience et du tempérament de chacun, ils peuvent passer par le papier, pas toujours.
    - c'est le résultat qui compte, il faut que ce soit impeccable, pour que n'importe qui, même 20 ans après, puisse reprendre le code sans s'y perdre.
    - l'XP en équipe, moi non plus, je n'y crois pas trop... pourtant mes méthodes s'y apparente, c'est dire.

    Conclusions :
    - le problême n'est pas l'utilisation ou non d'un formalisme "officiel" ou non, mais plûtot comment celui-ci est utilisé lors de la programmation : celui qui programme comme un pied, avec ou sans formalisme, avec ou sans phase de conception avant de se jeter dans la programmation proprement dite, n'arrivera à rien du tout.
    - le papier est un support de réfléxion pour certains, pas pour d'autres : ça n'empêche pas ces derniers de sortir des programmes monstrueux (par le volume de lignes de code et leur complexité), mais pourtant maintenable, évolutifs, etc...
    -il n'y a pas une façon de faire ou que les méthode officielles : je ne cherche pas à vous faire changer de méthode de dev, mais à vous faire admettre que ce qui n'est pas fait comme vous faites peut tout aussi bien être valable...
    avant qu'UML (par exemple) ne soit un formalisme officiel, était-il pour autant mauvais ?
    Bidouilleuse Delphi

  6. #286
    Membre expert

    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2006
    Messages
    1 352
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 352
    Points : 3 411
    Points
    3 411
    Par défaut
    Citation Envoyé par zooro
    Hum... Toi tu n'as pas du avoir l'occasion encore de travailler sur un soft de 1.300.000 lignes de code...
    J'ai l'impression que pour avoir le droit au titre de développeur faut avoir travaillé sur des projets de plus de 100 000 lignes ici.

    C'est pas la quantité qui prime, mais la qualité. Et que l'on vienne pas me faire croire que des codes aussi gros sont confiés à une seule personne, se serait de suicide...

    Maintenant, je pense que ceux qui on eu l'occasion de bosser sur des projets aussi gros, visent des secteurs d'activités bien précis et ne sont généralement pas seul face au projet (doit y avoir un paquet de copains derrière).

    Donc, il est facile de mettre en place une organisation de développement intégrant des formalismes quand on est 50 sur un projet, et que machine fait ci, un machine fait ça...

    Mais quand on est en équipe réduite, et que les délais sont les mêmes que pour une équipe étendue, on fait comment les champions ?
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  7. #287
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 190
    Points
    1 190
    Par défaut
    Citation Envoyé par zecreator
    J'ai l'impression que pour avoir le droit au titre de développeur faut avoir travaillé sur des projets de plus de 100 000 lignes ici.
    Non, ce n'est pas ce qu'on dit. C'est juste que quelqu'un qui explique qu'il est capable de comprendre (suffisamment pour connaître l'impact d'une modif majeure) un soft de plusieurs millions de lignes, et ce juste en lisant le code... Je trouve ça peu vraisemblable. Après, peut-être que c'est possible, je ne sais pas. Mais moi je n'en suis pas capable.

    Citation Envoyé par zecreator
    C'est pas la quantité qui prime, mais la qualité. Et que l'on vienne pas me faire croire que des codes aussi gros sont confiés à une seule personne, se serait de suicide...
    Personne ne l'a dit, tu as raison !

    Citation Envoyé par zecreator
    Maintenant, je pense que ceux qui on eu l'occasion de bosser sur des projets aussi gros, visent des secteurs d'activités bien précis et ne sont généralement pas seul face au projet (doit y avoir un paquet de copains derrière).
    Donc, il est facile de mettre en place une organisation de développement intégrant des formalismes quand on est 50 sur un projet, et que machine fait ci, un machine fait ça...
    Mais quand on est en équipe réduite, et que les délais sont les mêmes que pour une équipe étendue, on fait comment les champions ?
    Parfait ! Tu as résumé ce que tout le monde dit depuis le début !
    Dans une équipe importante, un minimum de documentation (UML ou autre) est indispensable pour la communication et la synchronisation des intervenants.
    Dans une équipe restreinte, une documentation minimale suffit, son but étant principalement ici de permettre à un intervenant ultérieur d'avoir une idée de l'organisation du code et/ou de la structure du soft.
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  8. #288
    Membre expérimenté Avatar de yann2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2004
    Messages
    897
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2004
    Messages : 897
    Points : 1 610
    Points
    1 610
    Par défaut
    @Waskol

    Je suis le thread depuis le début... ta mauvaise foi m'effraie...

    Les formalismes officiels ne sont pas là pour faire beau ou pour faire plaisir à un chef de projet...

    Tous les mecs de l'OMG perdent leur temps. D'ailleurs le MDA n'a aucun avenir car il s'appuie sur des formalismes officiels et nous n'en avons pas besoin parce que nous, on pratique la programmation spontanée...

    Pour moi, un formalisme, c'est une méthodologie, pas un outil de communication, donc rien à voir une histoire d'ambiguité du langage naturel, qui est effectivement plus que suffisant pour décrire quelque chose de façon clairre.
    Il me semble qu'UML est un formalisme mais certainnement pas une méthodologie.

    Citation:
    kisitomomotene a écrit :
    j'avais oublié ça. Je precise bien, je n'ai pas dit que la conception ne sert à rien. On concoit d'abord dans la tête. Ensuite il faut exprimer sa conception. Si c'est possible de l'exprimer directement dans un langage de programmation, c'est pas la peine de passer par UML ou d'autre doc.
    Alors là, je suis COM-PLE-TE-MENT d'accord. Et au fond, par rapport au sujet, c'est surtout ce point là l'objet de la discorde.
    Voir plus haut

    Bon courage

  9. #289
    Membre actif
    Inscrit en
    août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 307
    Points : 255
    Points
    255
    Par défaut
    Citation Envoyé par zooro
    Parfait ! Tu as résumé ce que tout le monde dit depuis le début !
    Dans une équipe importante, un minimum de documentation (UML ou autre) est indispensable pour la communication et la synchronisation des intervenants.
    Dans une équipe restreinte, une documentation minimale suffit, son but étant principalement ici de permettre à un intervenant ultérieur d'avoir une idée de l'organisation du code et/ou de la structure du soft.
    Je ne vois très bien pourquoi si on est plusieurs dans un projet, un code source ecrit "proprement" ne peut pas servir d'outil de communication. Je l'avais dejà dit, il existe des IDE qui ont de puissants outils de reverse ingenierie et d'isolation de code. Donc dans un code source, on tructure parfaitement et simplement le code, on y ajoute au besoins de commentaires de code, et des commentaires du style "javadoc", on crée dans le projet un fichier readme.txt pour donner l'orientation initail ( les principales classes "main" et d'autre unfo utiles pour une bonne introduction).
    Par la suite si quelqu'un veut comprendre ton soft, s'il tient tend à UML, il peut utiliser les outils reverse ingenierie pour avoir une vision globle de l'architecture de ton soft, il peut toujour utiliser l'IDE pour ne visualiser que la doc ( créer par les commentaire du style "javadoc"), s'il trouve superflu certain commentaire, il peut toujours les masquer dans l'IDE, pour se concentrer uniquement sur le code lui même. Bref comme je l'avais tjrs dis, si c'est possible d'aller directement dans le code source pour s'exprimer je trouve que c'est la façon la plus simple et la plus optimale.

  10. #290
    Membre expert
    Avatar de LadyWasky
    Femme Profil pro
    Inscrit en
    juin 2004
    Messages
    2 932
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 51
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : juin 2004
    Messages : 2 932
    Points : 3 504
    Points
    3 504
    Par défaut
    Citation Envoyé par yann2
    @Waskol
    Les formalismes officiels ne sont pas là pour faire beau ou pour faire plaisir à un chef de projet...
    Je n'ai jamais dit ça, tout au contraire même, merci pour la mauvaise foi...
    Des formalismes il en faut, mais le choix de tel ou tel formalisme et l'aspect qu'il prend dépend d'un contexte.
    Quand je bosse en équipe, ne t'inquiètes pas, j'utilise aussi des formalismes officiels : c'est souvent utile et indispensable dans ce cas (je n'ai pas dit que ça l'était toujours).
    Bref je n'ai pas dit qu'il fallait tout mettre à la poubelle, loin de la...

    Citation Envoyé par yann2
    Tous les mecs de l'OMG perdent leur temps. D'ailleurs le MDA n'a aucun avenir car il s'appuie sur des formalismes officiels et nous n'en avons pas besoin parce que nous, on pratique la programmation spontanée...
    Je ne dénigre en rien leur boulot que je respecte et que je trouve utile et même nécessaire : mais dans certain contextes (grosse équipe, ou petite équipe disséminée).

    sinon, avec davcha on est tombé d'accord sur tout plein de chose et on s'est surtout rendu compte que nos désaccords dépendaient de la définition que l'on donnait à ce terme : "la programmation spontanée". C'est cette expression qui est en fait le piège de tout le fil de discussion.
    C'est quoi pour toi "la programmation spontanée" ?
    Ne me dit pas que c'est développer sans avoir tout planifié ou sans avoir un but précis, parce si ça peut te rassurer c'est impossible de se lancer dans un programme si on a pas une idée de ce qu'on veut faire ni même d'aboutir à quelque chose de sérieux si on ne sait pas comment on va s'y prendre : que ce soit déjà écrit sur le papier ou non.
    Bidouilleuse Delphi

  11. #291
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 190
    Points
    1 190
    Par défaut
    Citation Envoyé par kisitomomotene
    Je ne vois très bien pourquoi si on est plusieurs dans un projet, un code source ecrit "proprement" ne peut pas servir d'outil de communication. Je l'avais dejà dit, il existe des IDE qui ont de puissants outils de reverse ingenierie et d'isolation de code. Donc dans un code source, on tructure parfaitement et simplement le code, on y ajoute au besoins de commentaires de code, et des commentaires du style "javadoc", on crée dans le projet un fichier readme.txt pour donner l'orientation initail ( les principales classes "main" et d'autre unfo utiles pour une bonne introduction).
    Par la suite si quelqu'un veut comprendre ton soft, s'il tient tend à UML, il peut utiliser les outils reverse ingenierie pour avoir une vision globle de l'architecture de ton soft, il peut toujour utiliser l'IDE pour ne visualiser que la doc ( créer par les commentaire du style "javadoc"), s'il trouve superflu certain commentaire, il peut toujours les masquer dans l'IDE, pour se concentrer uniquement sur le code lui même. Bref comme je l'avais tjrs dis, si c'est possible d'aller directement dans le code source pour s'exprimer je trouve que c'est la façon la plus simple et la plus optimale.
    Bon, apparemment, on s'exprime tous en langage naturel, mais on a quand même des problèmes de communication

    Je ne vois très bien pourquoi si on est plusieurs dans un projet, un code source ecrit "proprement" ne peut pas servir d'outil de communication
    On n'a pas dit que le code ne pouvait pas servir d'outil de communication, on a dit que dans certains cas, il n'était pas suffisant.
    Donc dans un code source, on tructure parfaitement et simplement le code, on y ajoute au besoins de commentaires de code, et des commentaires du style "javadoc", on crée dans le projet un fichier readme.txt pour donner l'orientation initail
    Donc tu créés une doc.
    Celà dit, comment tu fais pour que 50 personnes réussissent à "structurer parfaitement et simplement le code" sans s'être mis d'accord avant ? Il faut bien des docs qui expliquent à chacun comment le code doit être structuré, non ? Sinon tu peux être sûr qu'il y aura au moins un gars qui ne fera pas comme tout le monde !
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  12. #292
    Membre actif
    Inscrit en
    août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 307
    Points : 255
    Points
    255
    Par défaut
    Citation Envoyé par zooro
    .
    Celà dit, comment tu fais pour que 50 personnes réussissent à "structurer parfaitement et simplement le code" sans s'être mis d'accord avant ? Il faut bien des docs qui expliquent à chacun comment le code doit être structuré, non ? Sinon tu peux être sûr qu'il y aura au moins un gars qui ne fera pas comme tout le monde !
    On définit des guidelines que chacun doit suivre quand il programme, ah ça non chacun ne programme pas comme bon lui semble. Ce sont des procèdures internes de la maison, ou si tu veux c'est la doc de la boite et non la doc du soft qu'on est entrain d'écrire.

  13. #293
    Membre actif
    Inscrit en
    août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 307
    Points : 255
    Points
    255
    Par défaut
    Concernant l'ambiguïté qu'aurait le langage naturel. J'ai dejà vu des diagrammes UML vraiment ambigus. Si quelqu'un maitrise mal UML, son expression en UML serra aussi ambigu. Et je crois que c'est posible de s'exprimer un langage naturel, ou avec des schémas non conventionnel sans être ambigu et en se faisant parfaitement comprendre.

  14. #294
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 190
    Points
    1 190
    Par défaut
    Citation Envoyé par waskol
    on s'est surtout rendu compte que nos désaccord dépendait de la définition que l'on donnait à ce terme : "la programmation spontanée". C'est cette expression qui est en fait le piège de tout le fil de discussion.
    Effectivement, tout est problème de définition. C'est d'ailleurs de ça que je voulais parler en évoquant l'ambiguité du langage naturel.

    Citation Envoyé par waskol
    C'est quoi pour toi "la programmation spontanée" ?
    Ne me dit pas que c'est développer sans avoir tout planifié ou sans avoir un but précis, parce si ça peut te rassurer c'est impossible de se lancer dans un programme si on a pas une idée de ce qu'on veut faire ni même d'aboutir à quelque chose de sérieux si on ne sait pas comment on va s'y prendre : que ce soit déjà écrit sur le papier ou non.
    +1

    Pour moi, ça serait réfléchir à ce qu'on va faire, dans sa tête, peut-être en discuter avec un ou deux collègues qui bossent sur le même projet, puis se mettre à coder. Et c'est tout (rien avant, rien après).

    Je l'ai déjà fait sur de petits projets, mais uniquement pour des maquettes, ou des projets dont on savait qu'ils ne seraient jamais repris (durée de vie limitée à quelques jours, par exemple).
    Si de nombreuses personnes sont impliquées, ce n'est plus possible. Tout simplement parce que réfléchir et discuter ensemble (et surtout se comprendre) à plus de 50 personnes (éventuellement réparties géographiquement), sans utiliser de support physique, c'est presque impossible. Donc là, la "programmation spontanée", telle que je l'imagine, n'est plus applicable (sauf peut-être pour le petit bout de code dont je serais responsable).
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  15. #295
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 190
    Points
    1 190
    Par défaut
    Citation Envoyé par kisitomomotene
    Concernant l'ambiguïté qu'aurait le langage naturel. J'ai dejà vu des diagrammes UML vraiment ambigus. Si quelqu'un maitrise mal UML, son expression en UML serra aussi ambigu. Et je crois que c'est posible de s'exprimer un langage naturel, ou avec des schémas non conventionnel sans être ambigu et en se faisant parfaitement comprendre.
    La discussion en cours est la preuve que le langage naturel est ambigu. Un même mot sera compris de façons différentes selon la personne, en fonction de son expériences, de son vécu, du contexte, etc. L'objectif des documentations techniques, des langages formels, des schémas, et des spécifications en général est justement de réduire ces différences de compréhension en donnant plusieurs visions du problème de façon à s'assurer que tout le monde a compris la même chose. Et même comme ça, ce n'est pas forcément gagné !

    Après, personne ne dit qu'UML est idéal, surtout mal utilisé. On est tous d'accord pour dire que l'on peut faire des schémas ambigus si l'on veut. Et on est aussi tous d'accord pour dire qu'il est possible de s'exprimer clairement en langage naturel.

    Celà dit, allier des schémas clairs et un texte précis ne peut qu'améliorer la compréhension entre les intervenants.
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  16. #296
    Membre expert
    Avatar de LadyWasky
    Femme Profil pro
    Inscrit en
    juin 2004
    Messages
    2 932
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 51
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : juin 2004
    Messages : 2 932
    Points : 3 504
    Points
    3 504
    Par défaut
    Citation Envoyé par zooro
    Effectivement, tout est problème de définition. C'est d'ailleurs de ça que je voulais parler en évoquant l'ambiguité du langage naturel.
    Je comprend mieux ton point de vue vu sous cet angle.
    Citation Envoyé par zooro
    Pour moi, ça serait réfléchir à ce qu'on va faire, dans sa tête, peut-être en discuter avec un ou deux collègues qui bossent sur le même projet, puis se mettre à coder. Et c'est tout (rien avant, rien après).
    OK, comme ça par rapport à tout ce que tu as dit.
    dans ma démarche spontanée, donc seul ou en équipe restreinte, je rajoute systématiquement quelque chose après : la doc qui va bien, issue de cette réflexion et du code qui a été écrit.
    Du coup, par rapport à ta vision de la spontaneité, je ne suis plus dans la catégorie de ceux qui pratiquent la "programmation spontanée".
    sauf pour les "bricoles" que je fait pour moi-même.

    Citation Envoyé par zooro
    Je l'ai déjà fait sur de petits projets, mais uniquement pour des maquettes, ou des projets dont on savait qu'ils ne seraient jamais repris (durée de vie limitée à quelques jours, par exemple).
    c'est clair que pour ça, on peut s'affranchir de tout formalisme officiel et de doc. +1 aussi. Mais attention tout de même, j'ai déjà vu des maquettes ou des projets "temporaires" être repris ou perdurer : celà reste tout de même bon de laisser une trace, si minime soit-elle.
    Citation Envoyé par zooro
    Si de nombreuses personnes sont impliquées, ce n'est plus possible. Tout simplement parce que réfléchir et discuter ensemble (et surtout se comprendre) à plus de 50 personnes (éventuellement réparties géographiquement), sans utiliser de support physique, c'est presque impossible. Donc là, la "programmation spontanée", telle que je l'imagine, n'est plus applicable (sauf peut-être pour le petit bout de code dont je serais responsable).
    C'est aussi ce que j'ai déjà dis a maintes reprises, même avec la programmation spontanée "telle que je l'imagine, c'est-à- dire avec le "quelque chose" après.

    Celà dit, allier des schémas clairs et un texte précis ne peut qu'améliorer la compréhension entre les intervenants.
    +1 et pour moi, en équipe c'est ça le minimum vital; celà n'implique pas forcément de passer par des formalismes officiels (plus de 10 personne si, il faut que tout le monde parle le même langage), ce qui compte c'est d'ètre compris.

    @zooro :
    Pour ma gouverne : Yann me trouve de mauvaise fois, le suis-je à tes yeux ? rassures moi STP.
    Bidouilleuse Delphi

  17. #297
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 190
    Points
    1 190
    Par défaut
    Citation Envoyé par waskol
    @zooro :
    Pour ma gouverne : Yann me trouve de mauvaise fois, le suis-je à tes yeux ? rassures moi STP.
    Pas d'après ce que j'ai vu. Peut-être s'agit-il d'un problème de définition ?
    Rassuré ?
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  18. #298
    Membre expert
    Avatar de LadyWasky
    Femme Profil pro
    Inscrit en
    juin 2004
    Messages
    2 932
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 51
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : juin 2004
    Messages : 2 932
    Points : 3 504
    Points
    3 504
    Par défaut
    Citation Envoyé par zooro
    Pas d'après ce que j'ai vu. Peut-être s'agit-il d'un problème de définition ?
    Rassuré ?
    Ouf ! merci cher ami
    Bidouilleuse Delphi

  19. #299
    Membre expert

    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2006
    Messages
    1 352
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 352
    Points : 3 411
    Points
    3 411
    Par défaut Qules projet ?
    ... pour quel type de projet doit t-on intégrer une cinquantaine de personnes ? Pour le jeu vidéo OK, je comprend car il y a diverses spécialisation (3D, audio, vidéo, gameplay, test...), mais pour une application de gestion, là je vois pas l'utilité d'une si grande équipe...

    waskol a écrit :
    on s'est surtout rendu compte que nos désaccord dépendait de la définition que l'on donnait à ce terme : "la programmation spontanée". C'est cette expression qui est en fait le piège de tout le fil de discussion.
    Pour moi, le programmeur spontanée part d'une idée de base. Il visualise l'application finale, son utilisation et éventuellement pense déjà aux technologies qui seront utilisées.

    C'est quelqu'un qui n'aime pas être dépendant de méthodes, de contraintes (temps, techniques...) et qui n'applique que les siennes. C'est quelqu'un de créatif, qui possède une bonne expérience des NTIC et est un "touche-à-tout".

    Souvent étiquetté de "bidouilleur" ou de "pisseur de code", car ne suivant que très rarement les formalismes du métier, il en est pas moins productif et compétent.

    C'est aussi quelqu'un qui rencontre des difficultés à formuler les aspects d'un projet car il lui manque souvent du vocabulaire technique (quelque chose dont il ne trouve que rarement l'utilité).

    Voila ma définition en ce qui concerne la programmation spontanée et le profil que j'ai souvent rencontré par ceux qui la pratique.
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  20. #300
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 190
    Points
    1 190
    Par défaut
    Citation Envoyé par zecreator
    ... pour quel type de projet doit t-on intégrer une cinquantaine de personnes ? Pour le jeu vidéo OK, je comprend car il y a diverses spécialisation (3D, audio, vidéo, gameplay, test...), mais pour une application de gestion, là je vois pas l'utilité d'une si grande équipe...
    Eh bien... Je vois les applis télécom (pas toutes, mais si tu regardes un peu les standards 3GPP et autres protocoles télécom, tu te rendras compte que tout avoir dans la tête, même si on est "créatif", c'est impossible), des projets de refonte de SI dans les banques, des applis médicales, certains projets de la défense, des projets aéronautique (tu te vois coder tout seul tout le système informatique d'un Airbus ???)...
    Et je suppose que tout le monde a quelques exemples personnels à donner.
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

Discussions similaires

  1. Logiciel qui permet de programmer en Fortran ?
    Par lesvacances dans le forum Fortran
    Réponses: 2
    Dernier message: 05/11/2007, 21h53
  2. Tutorial bonne pratique du programmation avec JAVA
    Par menzlitsh dans le forum Langage
    Réponses: 10
    Dernier message: 02/07/2007, 11h56
  3. Script Shell qui lance un programme sur un ordi distant avec SSH
    Par bilibou dans le forum Shell et commandes GNU
    Réponses: 5
    Dernier message: 02/06/2007, 11h18
  4. Erreur qui bloque mon programme
    Par bugland dans le forum Langage
    Réponses: 6
    Dernier message: 21/12/2006, 22h32
  5. Réponses: 19
    Dernier message: 26/12/2005, 01h04

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo