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

Humour Informatique Discussion :

Coder rapidement ou écrire du code de qualité ? Les deux approches ne servent à rien

  1. #1
    Expert éminent sénior
    Avatar de Idelways
    Homme Profil pro
    Développeur Ruby on Rails / iOS
    Inscrit en
    Juin 2010
    Messages
    1 374
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Développeur Ruby on Rails / iOS

    Informations forums :
    Inscription : Juin 2010
    Messages : 1 374
    Points : 68 548
    Points
    68 548
    Par défaut Coder rapidement ou écrire du code de qualité ? Les deux approches ne servent à rien
    Coder rapidement ou écrire du code de qualité ?
    Les deux approches reviennent au même, selon un célèbre web-bédéiste



    XKCD est une célèbre bande-dessinée créée et publiée par Randall Munroe, un ancien consultant à la NASA, qui la définit comme un webcomic sarcastique qui parle de romance, de maths et de langage.

    Une planche publiée récemment sous forme d'organigramme algorithmique n'a d'autre prétention que celle de résumer, d'une manière extrêmement pessimiste, le métier de développeur.

    Les développeurs seraient, selon Munroe, éternellement confronté au dilemme : coder rapidement ou coder correctement.

    Ceux qui prennent la décision de "coder correctement" sont selon Munroe toujours dépassés par les événements, et quand leur travail arrive enfin à terme, les spécifications auront déjà changé. Les malheureux doivent donc tout jeter et reprendre depuis le début.

    Les autres (ceux qui choisissent de coder vite) finiraient, eux, immanquablement par produire une masse de « bidouilles et de code spaghetti ». Résultat, leur code subirait le même triste sort que celui de leurs confrères : être jeté et repris depuis le début.



    Bien entendu, cette planche exclut toute possibilité de juste milieu entre ces deux extrêmes.

    Il existe bien entendu des développeurs qui arrivent à produire du bon code dans les délais, sinon nous ne serions pas là pour en parler.


    Mais d'après vous ?

    Comment trouver le juste milieu pour développer vite tout en produisant du code correct ?
    Comment faire des concessions tout en étant consciencieux ?
    Y arrivez-vous plus avec l'expérience ? Ou pas du tout ?


    Source : XKCD.com

  2. #2
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Points : 16 081
    Points
    16 081
    Par défaut Mon mantra
    "Make It Work, Make It Right, Make It Fast", Kent Beck.

    1. "Make It Work" : Coder quelque chose qui est fonctionnel (implement)

    2. "Make It Right" : Reprendre le code pour le rendre clair (refactor)

    3. "Make It Fast" : Reprendre le code pour le rendre rapide (optimize)

    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  3. #3
    Membre confirmé
    Profil pro
    Développeur indépendant
    Inscrit en
    Août 2004
    Messages
    372
    Détails du profil
    Informations personnelles :
    Âge : 55
    Localisation : France

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : Transports

    Informations forums :
    Inscription : Août 2004
    Messages : 372
    Points : 512
    Points
    512
    Par défaut coder vite, et bien.
    simple, faire en sorte que les spécifications de l'appli ne changent pas toutes les 5 minutes..

  4. #4
    Membre émérite
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 448
    Points : 2 284
    Points
    2 284
    Par défaut
    Citation Envoyé par eomer212 Voir le message
    simple, faire en sorte que les spécifications de l'appli ne changent pas toutes les 5 minutes..
    pure folie ou folie pure ? = )

    Sion j’avais pensé au triple D en lisant la news
    Do it yourself,
    Do it fast,
    Do not test

    On peut même rajouter
    Do it once again =)

    a+

  5. #5
    Rédacteur

    Homme Profil pro
    Comme retraité, des masses
    Inscrit en
    Avril 2007
    Messages
    2 978
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 83
    Localisation : Suisse

    Informations professionnelles :
    Activité : Comme retraité, des masses
    Secteur : Industrie

    Informations forums :
    Inscription : Avril 2007
    Messages : 2 978
    Points : 5 179
    Points
    5 179
    Par défaut
    Bonjour à tous!

    Mon expérience professionnelle est la suivante: dans l'immense majorité des cas, celui (client, supérieur hiérarchique ou autre) qui vous confie une tâche de développement informatique n'a aucune idée de ce qu'il veut, et encore moins de ce qu'il est possible de réaliser. Il convient donc de procéder en deux étapes:
    1. Commencer par écrire un programme de manière raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manière, est totalement incohérent.
    2. Lorsque c'est terminé, faire preuve d'un sens psychologique extrême pour persuader le client que c'est exactement ce qu'il a commandé.

    Vous pouvez me croire ou non, mais, dans la plupart des cas, ça marche. On pourrait évidemment envisager un cas critique, à savoir que le client soit compétent, mais c'est plutôt rare; de plus, dans ce cas, il aurait écrit son programme lui-même.

    Jean-Marc Blanc
    Calcul numérique de processus industriels
    Formation, conseil, développement

    Point n'est besoin d'espérer pour entreprendre, ni de réussir pour persévérer. (Guillaume le Taiseux)

  6. #6
    Membre émérite
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 448
    Points : 2 284
    Points
    2 284
    Par défaut
    Citation Envoyé par FR119492 Voir le message
    Bonjour à tous!

    Mon expérience professionnelle est la suivante: dans l'immense majorité des cas, celui (client, supérieur hiérarchique ou autre) qui vous confie une tâche de développement informatique n'a aucune idée de ce qu'il veut, et encore moins de ce qu'il est possible de réaliser. Il convient donc de procéder en deux étapes:
    1. Commencer par écrire un programme de manière raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manière, est totalement incohérent.
    2. Lorsque c'est terminé, faire preuve d'un sens psychologique extrême pour persuader le client que c'est exactement ce qu'il a commandé.

    Vous pouvez me croire ou non, mais, dans la plupart des cas, ça marche. On pourrait évidemment envisager un cas critique, à savoir que le client soit compétent, mais c'est plutôt rare; de plus, dans ce cas, il aurait écrit son programme lui-même.

    Jean-Marc Blanc
    La méthode Gérard majax !

    Un classique de l'incompétent informaticien, ou du trop expérimenté,
    c'est selon ; )

    a+

  7. #7
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Points : 16 081
    Points
    16 081
    Par défaut
    Citation Envoyé par kaymak Voir le message
    La méthode Gérard majax !


    Une variante du Reality distortion field.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  8. #8
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2006
    Messages
    519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 519
    Points : 1 104
    Points
    1 104
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    "Make It Work, Make It Right, Make It Fast", Kent Beck.

    1. "Make It Work" : Coder quelque chose qui est fonctionnel (implement)

    2. "Make It Right" : Reprendre le code pour le rendre clair (refactor)

    3. "Make It Fast" : Reprendre le code pour le rendre rapide (optimize)

    Il ne me semble pas qu’il soit question du même "fast", ici : celui de la bande dessinée semble plutôt s’appliquer au développement qu’au programme résultant.

  9. #9
    Membre régulier
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2007
    Messages : 91
    Points : 114
    Points
    114
    Par défaut
    Des besoins clients qui n'évoluent pas, c'est un voeux pieux, donc autant se dire que cela n'existe pas. Et pas de projets sans clients, donc autant intégrer la fluctuation des besoins comme une contrainte de départ.

    Je vous conseille de passer un peu de temps à étudier les méthodes agiles. Ce n'est pas uniquement parce qu'on est un développeur "agile" que le code est produit rapidement et proprement, mais si le client et/ou MOA sont impliqués dans le processus, cela augmente les chances de se rapprocher du Graal: vite et bien.

    Il est certain que lorsqu'un donneur d'ordre espère que 100% du travail soit réalisé dans 70% du temps imparti avec des exigences fonctionnelles différentes encours de projet, il y a peu de chances que la MOE livre du travail de qualité dans les délais!

  10. #10
    Membre expérimenté
    Avatar de Patriarch24
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2003
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

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

    Informations forums :
    Inscription : Septembre 2003
    Messages : 1 047
    Points : 1 640
    Points
    1 640
    Par défaut
    Citation Envoyé par pseudocode
    "Make It Work, Make It Right, Make It Fast", Kent Beck.
    +1.

    Les développeurs seraient, selon Munroe, éternellement confronté au dilemme : coder rapidement ou coder correctement.

    Ceux qui prennent la décision de "coder correctement" sont selon Munroe toujours dépassés par les événements, et quand leur travail arrive enfin à terme, les spécifications auront déjà changé. Les malheureux doivent donc tout jeter et reprendre depuis le début.

    Les autres (ceux qui choisissent de coder vite) finiraient, eux, immanquablement par produire une masse de « bidouilles et de code spaghetti ». Résultat, leur code subirait le même triste sort que celui de leurs confrères : être jeté et repris depuis le début.
    Il existe des méthodes de gestion de projet pour éviter ces désagréments. XP (Scrum, etc) permettent de significativement réduire le risque que ce genre de mésaventures se produisent (même si elles ne l'annihilent pas). Pour moi, c'est une ânerie.
    En premier lieu, utilisez un moteur de recherche.
    En second lieu, postez sur le forum adéquat !

  11. #11
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 484
    Points : 5 277
    Points
    5 277
    Par défaut
    Je pense que la meilleure méthode reste celle là :



    C'est la méthodologie de la RACHE à découvrir ici : http://www.risacher.com/la-rache/ et qui est utilisée dans de très nombreux projets.
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  12. #12
    Expert éminent sénior
    Avatar de rawsrc
    Homme Profil pro
    Dev indep
    Inscrit en
    Mars 2004
    Messages
    6 142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev indep

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 142
    Points : 16 545
    Points
    16 545
    Billets dans le blog
    12
    Par défaut
    Bonjour

    dans l'immense majorité des cas, celui (client, supérieur hiérarchique ou autre) qui vous confie une tâche de développement informatique n'a aucune idée de ce qu'il veut
    je dirais +1000. A tel point parfois qu'il arrive que cela soit le prestatire qui doive écrire le cahier des charges qu'il devra respecter. Véridique, cela a été le cas de mon dernier contrat. Enfin comme il me l'a dit : "c'est pas mon problème" et que "c'était à moi de faire mon boulot en lui détaillant ses besoins".
    A la question posée je dirais qu'il faut juste coder proprement en prévision des futures modifications, de manière à ce que la reprise du code soit la moins fastidieuse possible.

  13. #13
    Membre éclairé
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    614
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 614
    Points : 713
    Points
    713
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    "Make It Work, Make It Right, Make It Fast", Kent Beck.

    1. "Make It Work" : Coder quelque chose qui est fonctionnel (implement)

    2. "Make It Right" : Reprendre le code pour le rendre clair (refactor)

    3. "Make It Fast" : Reprendre le code pour le rendre rapide (optimize)

    Ça, c'est une jolie théorie, mais elle a le défaut que si elle n'est pas appliquée par le gestionnaire de projet (peu importe à quel niveau) plus accroché à ses graphs, elle ne dépasse pas l'étape 1. Après tout, pourquoi continuer à imputer sur quelque chose qui est fonctionnel. C'est fonctionnel, bien, c'est plié et on passe à la tache suivante. Au niveau du gestionnaire, ça avance (fast), au niveau du code, on génère du spaghetti à la bolognaise qui tâche...

  14. #14
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Points : 16 081
    Points
    16 081
    Par défaut
    Citation Envoyé par martopioche Voir le message
    Après tout, pourquoi continuer à imputer sur quelque chose qui est fonctionnel. C'est fonctionnel, bien, c'est plié et on passe à la tache suivante. Au niveau du gestionnaire, ça avance (fast), au niveau du code, on génère du spaghetti à la bolognaise qui tâche...
    Ca avance vite... au debut seulement. Ca s'enlise au fur et à mesure, et les itérations deviennent de plus en plus longues et risquées.

    Au point souvent d'établir comme règle de "toucher au minimum" le code existant... et finir par n'avoir que deux choix possibles : "Ne plus rien toucher" ou "Tout jeter et refaire".
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  15. #15
    Membre émérite
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 448
    Points : 2 284
    Points
    2 284
    Par défaut
    Citation Envoyé par pseudocode Voir le message


    Une variante du Reality distortion field.
    ouaw excellent !

    Mythe ou réalité ?
    A en juger par les records d'apple, réalité :O

    ....


    Citation Envoyé par Barsy Voir le message
    Je pense que la meilleure méthode reste celle là :



    C'est la méthodologie de la RACHE à découvrir ici : http://www.risacher.com/la-rache/ et qui est utilisée dans de très nombreux projets.
    Muhahahahahah Il est toujours aussi tordant ce schéma !!


    Ca avance vite... au debut seulement. Ca s'enlise au fur et à mesure, et les itérations deviennent de plus en plus longues et risquées.

    Au point souvent d'établir comme règle de "toucher au minimum" le code existant... et finir par n'avoir que deux choix possibles : "Ne plus rien toucher" ou "Tout jeter et refaire".
    Oui je confirme. Je rajouterais un truc qui n'est pas mentionné jusqu'ici, la documentation.
    Avec le turn over, la rapidité des développements mal contrôlés, on ne fait pas de doc, ou de test, du coup lorsqu'il s'agit de corriger un bug en phase de TMA, on ne sait plus quel était l'objectif de départ du développement, le développeur fais des modifs mais n'est pas capable de s'assurer,
    - que c'est toujours concordant avec le dév initial
    - qu'il n'à pas introduit d'effet de bord

    Et lorsqu'il s'agit d'expliquer à un nouveau collègue le "but de ce truc",
    bah tu prends tes spaghettis et t'organises une partie de mikado avec lui pour dénouer le bordel =)



    A +

  16. #16
    Membre éclairé
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    614
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 614
    Points : 713
    Points
    713
    Par défaut
    Citation Envoyé par kaymak Voir le message
    Oui je confirme. Je rajouterais un truc qui n'est pas mentionné jusqu'ici, la documentation.
    Avec le turn over, la rapidité des développements mal contrôlés, on ne fait pas de doc,
    Oui mais aujourd'hui, c'est normal. On fait de l'Agile, on favorise la communication orale afin que les équipes communiquent plus vite, et le code parle de lui même. Alors la doc...

    ...


  17. #17
    Membre habitué

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    125
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 125
    Points : 175
    Points
    175
    Par défaut
    Citation Envoyé par Barsy Voir le message
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"
    Indiana Jones ?

  18. #18
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 484
    Points : 5 277
    Points
    5 277
    Par défaut
    Citation Envoyé par ymajoros Voir le message
    Indiana Jones ?
    perdu
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  19. #19
    Membre averti Avatar de Tellen
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    150
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Octobre 2006
    Messages : 150
    Points : 407
    Points
    407
    Par défaut
    Citation Envoyé par ymajoros Voir le message
    Indiana Jones ?

    Mais non !!! Mac Gyver. ça fait 2 fois (ok pas sur la même discussion).
    Y a quant même l'avatar qui donne un indice.

  20. #20
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 484
    Points : 5 277
    Points
    5 277
    Par défaut
    Citation Envoyé par Tellen Voir le message
    Mais non !!! ...
    T'aurais pu laisser les gens essayer de deviner un peu...
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

Discussions similaires

  1. Réponses: 2
    Dernier message: 22/01/2010, 19h07
  2. Réponses: 1
    Dernier message: 17/04/2007, 14h07
  3. Façon d'écrire votre code
    Par reptils dans le forum C
    Réponses: 6
    Dernier message: 03/03/2007, 18h20
  4. Réponses: 3
    Dernier message: 17/08/2006, 05h11
  5. [VBA Excel] Comment écrire un code dans le ThisWorkBook ?
    Par WebPac dans le forum Macros et VBA Excel
    Réponses: 3
    Dernier message: 03/05/2005, 16h03

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