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. #481
    Membre à l'essai
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mai 2017
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mai 2017
    Messages : 4
    Points : 12
    Points
    12
    Par défaut
    Citation Envoyé par Bousk Voir le message
    Énormes projets de 20 personnes, merci de me faire rire de bon matin
    ouais et bien apres tu peux avoir 100 personne je doute quelle ne travaille toute sur la meme partie, et la je ne parlais que des dev, il y a les architecte, les fonctionnels, etc

    C'etait surtout pour répondre "la programmation spontané c'est quand on est tous seul ou sur un projet perso", et bien non, c'est aussi dans le milieu professionel.

  2. #482
    Membre confirmé
    Avatar de APL-AML
    Homme Profil pro
    Développeur Gestion (Retraité)
    Inscrit en
    juin 2020
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Développeur Gestion (Retraité)
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : juin 2020
    Messages : 3
    Points : 519
    Points
    519
    Billets dans le blog
    60
    Par défaut Synthèse de la discussion
    Citation Envoyé par Invité Voir le message
    09/02/2008, 19h46

    Je pensais faire une synthèse mais je ne suis pas certain que ça vaille le coup.
    Chacun a ses vérités sur ce sujet. L'informatique étant multiple, il faut accepter la diversité qui permet de s'enrichir.
    C’est ce que j’avais posté en février 2008. Finalement, je n’ai mis que 13 ans pour rédiger cette synthèse. Ma spontanéité s’est un peu émoussée ! Structurée en 6 billets, ma synthèse oppose les Adeptes de la programmation spontanée à leurs Détracteurs.

    À cette synthèse, j’ai ajouté un billet Adeptes VS Détracteurs.

    ■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■

    • Avant-propos
    • Adeptes VS Détracteurs
      1. Développeur VS Programmeur
      2. Programmation spontanée VS Programmation improvisée
      3. Logigramme VS Algorigramme
      4. Adeptes pondérés VS Détracteurs spontanés
      5. Traitements (Mode plan) VS Conditions (Mode street)
      6. Mise en page VS Commentaires
    • Conclusion
    Extrait :

    Vous savez quoi ? Dans son premier message, Doloop faisait référence à l'auteur d'un livre paru dans les années 80, qui annonçait qu'il n'y aurait que 10 % des programmeurs en capacité de se passer de dessiner un algorithme pour faire un programme.

    J’ai recensé le nombre d’intervenants dans cette discussion et identifié parmi ceux-ci les adeptes auto-déclarés ou potentiellement adeptes de la programmation spontanée… en capacité donc, de se passer de dessiner un algorithme pour faire un programme :

    • Nombre d’intervenants : 153
    • Nombre d’adeptes : entre 15 et 20

    Étonnamment, le nombre d’adeptes est proche des 10% prévus il y a quarante ans par l’auteur Zaks Rodnay.

    Les détracteurs de la démarche ont tous de bonnes raisons personnelles de critiquer le concept de programmation spontanée. Toutefois, il en est une commune à tous : celle de ne pas pratiquer la démarche et donc in fine d’en ignorer toute la réalité. Persuadés qu’ils détiennent la vérité inoculée par l’enseignement formel, chaque détracteur imagine le concept en l’assimilant à tort à la programmation improvisée des bidouilleurs.

    Alors que valent toutes leurs diatribes virulentes, acerbes, ironiques ? Rien !

    En lire plus…



    Mon blog DVP titré de mon pseudo APL-AML est constitué de deux blogs logiques :

    1. APL-AML
    2. FORUMS

    Les adeptes trouveront ma synthèse de cette discussion sur mon 2ème blog logique « FORUMS ».

    Pour y accéder, ouvrir mon billet : SOMMAIRE « Synthèses de discussions »

    Voici le sommaire de ma synthèse de cette discussion :

    1. [Discussion] Qui pratique la programmation spontanée ?

      1. Doloop

        • Qui pratique la programmation spontanée ?
        • Qu’est ce que l'on peut apprendre lorsque l'on est obligé de tout faire !
        • La programmation spontanée se vit, mais ne s'explique pas fondamentalement, elle fait partie de nous.
        • 10% des programmeurs sont capables d'écrire un programme sans ordinogramme.
        • Programme bien pensé fonctionnement assuré. Programme mal pensé est à recommencer.
        • L'eXtreme Programming.

      2. Adeptes VS Détracteurs

        • Développeur VS Programmeur
        • Programmation spontanée VS programmation improvisée
        • Logigramme VS Algorigramme
        • Traitement (Mode plan) VS Conditions (Mode street)
        • Mise en page VS Commentaires

      3. Adeptes

        • Avant-propos
          • L’appropriation
          • Processus créatif
          • Citations sur la créativité

        • Adeptes
          • Envoyé par ErwanVDF
          • Envoyé par epeios
          • Envoyé par sequentaire
          • Envoyé par cedricgirard
          • Envoyé par Swoög
          • Envoyé par barjy
          • Envoyé par zecreator
          • Envoyé par 2Eurocents
          • Envoyés par d’autres adeptes glanés sur la discussion

      4. Détracteurs

        • Détracteurs
        • Diatribes

      5. LadyWasy

        • La méthode "Académique" ou non, on en a AB-SO-LU-MENT rien à faire !
        • C'est à la fin du bal que l'on compte les musiciens
        • Conception mentale d’un algorithme
        • Trois profils de codeurs
        • Certaines idées préconçues ont vraiment la vie dure
        • Documenter : comment, avec quels outils ?
        • Deux définitions du terme « spontané »
        • Formalisme "conventionnel" ou "personnel"
        • Incrédules et obtus !
        • Quelques règles élémentaires

      6. APL-AML

        • Programmation à main levée et Sophrologie
        • Une application « tout-de-suite »
        • Structurer l’inconnu
        • Méthode d'investigation
        • Marcher sans se tenir à son trotteur
        • La programmation mentale



    PS : Chaque membre ne dispose que d’un seul blog DVP identifié par son pseudo. Cependant, rien n’empêche un blogueur de partitionner son blog DVP en plusieurs blogs logiques.

    Bien que mon blog DVP et mon 1er blog logique aient le même titre, c’est-à-dire mon pseudo APL-AML, ils ne recouvrent pas la même réalité. Dans un premier temps, je n'avais aucune raison de les distinguer. Le concept de blogs logiques ne s’est imposé que lorsque l’ensemble des billets de mon blog DVP est devenu une entité distincte ayant la forme d’un tutoriel abouti et quasi immuable. Continuer à bloguer tout en préservant l’intégrité de cette entité, donc sans lui ajouter de billets, m’a inspiré le concept de blogs logiques.

    Constitué d’une cinquantaine de billets, mon 1er blog logique APL-AML (Au Pied Levé – À Main Levée) est une monographie qui axiomatise une approche du développement 100% ascendante (bottom-up).

    • Pour les adeptes de la programmation spontanée, ma monographie peut-être vue comme un tutoriel sur le développement spontané d’application.

      Une application de gestion, c’est plusieurs fonctionnalités. Il suffit d’une première fonctionnalité opérationnelle pour la faire exister. Une fonctionnalité n’existe pas ? Les gestionnaires s’en passent jusqu’à ce qu’elle existe. Le matin, elle n’est encore qu’à l’état de besoin en train d’infuser dans le cerveau du développeur, l’après-midi, sa programmation spontanée la fait exister et les gestionnaires l’utilisent comme si elle avait toujours existé.

    • Pour les gestionnaires, leur application existe vraiment dès le premier jour. Ils-elles disposent déjà d’un embryon de menu et d’au moins une première fonctionnalité opérationnelle, généralement une saisie simplifiée. L’application n’est jamais complète bien sûr, mais cela n’a aucune importance, les gestionnaires ne le savent pas, ils-elles n’utilisent que les fonctionnalités dont ils-elles ont besoin sur le moment ; les prochaines s’implémenteront le moment venu. Ce n’est pas plus compliqué que ça. Il faut juste oser et avoir confiance en soi.

    • Pour les détracteurs corsetés dans leur conformisme, c’est clairement un texte subversif. Cependant, ils pourront constater que la programmation spontanée n’a rien à voir avec la perception qu’ils en ont. Ils y retrouveront quelques grands principes évoqués dans mon billet Adeptes VS Détracteurs :

      • Appropriation,
      • Engagement,
      • Programmation mentale,
      • Hiérarchisation par traitement,
      • Nommage significatif,
      • Lisibilité et simplicité du codage,
      • Mise en page de la programmation.

    • Pour les blogueurs, c’est un blog logique et un tutoriel sous forme de billets de blog.

      Il y a trois façons de définir un blog logique :

      • Via la Description du blog
      • Via les Catégories de l’utilisateur
      • Via un billet Sommaire

      Mais je m’éloigne du sujet…

    La situation étant désespérée, tout est maintenant possible. John Cage

  3. #483
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 514
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 514
    Points : 30 487
    Points
    30 487
    Par défaut
    Bonjour.

    Je suis en train de lire. Remarques en vrac, au fil de la lecture.

    [0] Ce n'est pas de l'informatique, c'est de la sociologie. J'adore la sociologie. C'est aussi de la psychologie, et j'aime bien aussi. Il me semble que tu as aussi bien cerné les détracteurs - qu'on rencontre dans tous les domaines. Si tu sors des clous, tu te fais flinguer. Par principe. Ils ne comprennent pas

    [1] exemple en COBOL. Tu sais me parler. Par contre, je ne suis pas d'accord avec les commentaires. Les commentaires sont utiles quand bien utilisés. Quand ils disent le pourquoi de la chose (et surtout pas le comment). Si je fais un code clair du genre

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     IF Type-Payement-TIP AND Montant-A-Payer GREATER OR EQUAL THAN 1000000
         SET Type-Payement-Cheque TO TRUE
     END IF
    Je sais parfaitement ce que fait mon code (forcer le payement à chèque au lieu de TIP, même si on a le payement paramétrer à TIP). C'est du sexycodage, c'est bien, c'est bon. Mais quand tu reviens dessus des décennies après, tu te demandes, "mais pourquoi diable forcer le payement par chèque quand le montant atteint un million?????". Réponse avec le commentaire :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    *Les préimprimés TIP n'ont que 6 caractères avant la virgule. Mr Machin justifie, dans son mail du 14/08/1995, le forçage à payement par chèque dans ce cas rare.
     IF Type-Payement-TIP AND Montant-A-Payer GREATER OR EQUAL THAN 1000000
         SET Type-Payement-Cheque TO TRUE
     END IF
    Et là, on sait pourquoi.

    Je ne suis pas non plus convaincu par l'absence de PERFORM. Un PERFORM bien conçu fait gagner du temps. Par contre, il doit être parlant, et correctement agencé.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    PERFORM INITIALISATION
    PERFORM TRAITEMENT
    PERFORM FINALISATION
    n'apporte rien. Autant faire un programme direct et ne pas se faire chier avec cet entête.

    Par contre,
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    PERFORM INITIALISATION
    PERFORM TRAITEMENT
      UNTIL CONDITION-SORTIE
    PERFORM FINALISATION
    apporte beaucoup : on sait soudain que le début et la fin sont fait une seule fois, par contre le milieu est itératif. Et au plus la condition de sortie sera explicite, au plus l'ensemble sera lisible par le pauvre malheureux qui doit se farcir l'analyse de 800 programmes en trois mois (moi, en 2014).

    [2] Mettre en page ses programmes. là, 100% d'accord. C'est encore du sexycodage. Oui, on doit comprendre tout ce que fait le programme d'un simple coup d'œil. Ca n'élimine pas le besoin de commentaires à mon sens. Mais les commentaires doivent être un plus, pas un mal nécessaire. Un plus à long terme, qui donnent le pourquoi, et surtout pas le quoi ou le comment (si on ne devine pas le quoi ou le comment du premier coup d'œil, alors ce n'est pas sexy. donc c'est mal). Le pourquoi n'a pas à apparaitre dans le code lui-même - d'où sa présence dans le commentaire.

    [3] J'aime beaucoup ta théorie sur l'imprégnation. Ca revient à Joel Spolsky qui cherchait des développeurs capables de penser à plusieurs niveaux d'abstraction simultanée. Capables de penser l'algorithme et son implémentation, mais aussi le contexte plus global (application entière, utilisation, contexte économique.....)
    Citation Envoyé par le fondateur de stack overflow, de trello, qui a ausi écrit les specs de VBA pour EXCEL, excusez du peu
    You need training to think of things at multiple levels of abstraction simultaneously
    On retrouve ça dans ta théorie sur l'imprégnation. Il faut penser à plusieurs niveaux d'abstraction pour s'imprégner de l'ensemble. Sans celà, on est obligé de suivre les rails. d'où la réaction violente des détracteurs. Peut-être pas tous, mais beaucoup, n'ont pas cette capacité. Ca leur fait peur. Que d'autres aient cette capacité est effrayant. La violence - mais aussi la spontanéité - de leur réaction, s'expliquent par cette peur de l'inconnu. Si ils ne peuvent pas, alors personne ne doit pouvoir.

    Et ça explique aussi l'enseignement : on veut faire un grand nombre de programmeurs, donc on sélectionne large, donc on prend des gens qui n'ont pas cette capacité, donc on doit les guider pas à pas tout au long du projet. J'anticipe sur tes citations de l'excellent zecreator un peu plus loin, mais quand il dit que les petites structures ne peuvent pas se permettre, c'est exactement ça. J'ai fait une remarque en Janvier comme quoi nos tests automatiques d'interface ne couvraient pas la nouvelle version de telle fonctionnalité. A la mi mars, mon chef m'a dit "c'est ta nouvelle priorité". Et je dois me demerder. Alors que nos experts sont surbookés, je dois établir un plan complet , trouver tout ce qui mérite d'être couvert, mettre en place un urbanisme global, une architecture technique, réaliser, tester, adapter en fonction des surprises trouvées, valider, et mettre en production les scripts. Seul.

    Je ne vais pas me faire chier à tout mettre au propre. J'ai craché 6 ligne sur papier au début pour m'aider à réfléchir. Depuis, je code, je fais propre, et je progresse. Tout est dans ma tête. Je suis à l'image de ce que décris DoLoop. Et je dois aller vite et faire bien. Et les autres membres de l'équipe, au passé bien moins technique que le mien, doivent arriver à me lire.

    J'ajoute encore qu'il m'est arrivé de passer par l'étape papier., de manière plus importante. Simplement parce que j'avais atteint les limites de ce que mon cerveau peut charger en mémoire, et soudain, une bon schéma papier devient indispensable. Une fois, j'avais une page de schéma. Un schéma avec plein de boites et plein de traits. Il le fallait. En plus, ça m'a aidé à communiquer sur ce quoi je bossais. Mais le contenu des boites était fort complexe, et je ne me suis pas fait chier à le ressortir. Il y avait une boite "calcul des adresses clients", une boite "calcul des données assurance automobile", et ça suffisait.

    [4] J'adore la créativité. Rien à ajouter sur cette partie.

    [5] La partie détracteurs est fort rigolote. elle colle avec ce que j'ai dit au point [0]

    [6] LadyWasky amène le point important de la documentation. Pour mois, il faut le strict minimum qui permet de retrouver. J'ai fait un gros projet de refonte, ou les gens en aval m'avaient donné une spec du format qu'ils attendait, avec toutes els données nécessaires. J'ai rendu 2 docs. La première était le dessin de chaine (indispensable pour passer en prod). Le deuxième était la spec des gens en aval, complétée par le nom du composant ou la donnée était calculée. C'est tout. Si les programmes sont propres, on cherche à maintenir la taxe d'assurance automobile, on voit que c'est dans le "calcul des données assurance automobile", on regarde le programme, et on a la vérité.

    Si j'avais fait une spec décrivant l'algo de calcul de la taxe d'assurances automobile, il aurait été très vite obsolète. donc faux. Le programme, lui, dit la vérité de ce qui est (ce qui doit être, c'est autre chose, mais la spec que j'aurais écrite moi aurait été obsolète encore plus vite que le code).

    [7] Aaaaah, en fait tu est IFA2377, l'informaticien fonctionnaire. Ca explique quelques petits trucs. Notamment que tu as toujours travaillé en électron libre. Je n'ai jamais eu ce luxe. D'où sans doute nos dissensions sur les commentaires. J'aime ton gout du risque, on m'a, en ses lieux, beaucoup reproché le mien.

    Au final, ce que tu dis sur les détracteurs me fait penser à Carlos Tinoco.



    Il parle de "surdoués" Mais ce qu'il dit des surdoués eux-mêmes n'est pas important. Ce qu'il dit, en creux, sur le groupe opposé, les "typiques" est bien plus intéressant. Et je dirais que ce qu'il dit des typiques concerne bien moins que les "non-surdoués". Des non typiques, on en croise à toutes les échelles de QI. Les "typiques" tels qu'il les décrit ne font sans doute que 50 ou 70% de la population, pas les 97.7% des gens dont le QI est en dessous de 130 (définition habituelle des surdoués). Mais ils sont majoritaires. Et leur mode de fonctionnement principal, c'est la soumission au récit collectif. Ce n'est même pas qu'ils sont moins intelligents (je déteste cette distinction surdoués / non-surdoués). C'est juste qu'ils ont un mode de fonctionnement ou chacun va suivre le rôle qui lui est prédéfini. Et que la seule improvisation qu'ils permettent, chez eux comme chez les autres, c'est les manœuvres pour atteindre un rôle plus prestigieux. Tout le reste doit suivre scrupuleusement la partition écrite à l'avance.

    Donc quand toi, "surdoué" ou pas, tu présentes un mode de fonctionnement qui ne leur est pas accessible, eh bien du entres dans la zone de ce qu'ils ne permettent pas. Et tout sera bon pour te faire taire. Avec violence. Parce que le simple fait que tu existes, que tu leur fasse entrevoir des choses que leur beau récit collectif ne prévoit pas, les plonge dans des abîmes d'angoisse. On ne tape jamais aussi fort que quand on a peur.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  4. #484
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 198
    Points : 5 089
    Points
    5 089
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Les commentaires sont utiles quand bien utilisés. Quand ils disent le pourquoi de la chose (et surtout pas le comment).
    Je nuancerais ce point. Les commentaires doivent généralement expliquer le pourquoi, rarement le comment.

    Voici une version altérée d'un commentaire que j'ai écrit dans un de mes algorithmes, à mon boulot :
    Explication de l'algorithme dans le cas où il y a 3 ensembles A, B et C :

    Le but est de récupérer tous les éléments des tuples (x, y, z) tels que :
    • x appartient à A,
    • y appartient à B,
    • z appartient à C et
    • x <= y <= z.

    Pour cela, l'algorithme ne cherche pas directement les tuples (x, y, z). Il fait quelque chose de plus performant :
    • Chercher min_A, le plus petit élément dans A.
    • Chercher min_B, le plus petit élément >= min_A dans B.
    • Chercher min_C, le plus petit élément >= min_B dans C.
    • Si l'une des étapes précédentes échoue, retourner un résultat vide.
    • Chercher max_C, le plus grand élément dans C.
    • Chercher max_B, le plus grand élément <= max_C dans B.
    • Chercher max_A, le plus grand élément <= max_B dans A.
    • Récupérer :
      • les éléments de A dans [min_A, max_A],
      • les éléments de B dans [min_B, max_B] et
      • les éléments de C dans [min_C, max_C].

    Le vrai algorithme fonctionne pour un nombre quelconque d'ensembles.
    Le code qui suit mon commentaire travaille directement avec un nombre quelconque d'ensembles, donc est légèrement plus abstrait que le cas particulier décrit dans mon commentaire. Ici, mon commentaire a un but pédagogique : il permet au lecteur de comprendre un cas particulier avant de comprendre le cas général au lieu de s'attaquer directement à la compréhension du cas général.
    Néanmoins, je suis d'accord pour dire qu'il s'agit de cas assez rares en informatique de gestion.

    Citation Envoyé par el_slapper Voir le message
    Au final, ce que tu dis sur les détracteurs me fait penser à Carlos Tinoco.

    Citation Envoyé par el_slapper Voir le message
    Donc quand toi, "surdoué" ou pas, tu présentes un mode de fonctionnement qui ne leur est pas accessible, eh bien du entres dans la zone de ce qu'ils ne permettent pas. Et tout sera bon pour te faire taire. Avec violence. Parce que le simple fait que tu existes, que tu leur fasse entrevoir des choses que leur beau récit collectif ne prévoit pas, les plonge dans des abîmes d'angoisse. On ne tape jamais aussi fort que quand on a peur.
    De mon côté, quand j'avais lu le fil présent, j'avais une analyse différente du comportement des détracteurs de Doloop.

    Dans la vidéo que tu cites, Carlos Tinoco parle de contradictions chez les gens normaux entre les paroles et le comportement.

    Dans le fil présent, Doloop ne donne pas d'exemple de code. Donc les intervenants extrapolent. Vraisemblablement, les détracteurs ont projeté leurs propres capacités et celles de certains de leurs collègues en se disant "si moi ou tel collègue code avec la démarche de Doloop, alors le code sera mauvais, donc le code de Doloop est sûrement mauvais". En vrai, peut-être que le code de Doloop est largement plus maintenable que celui d'un développeur moyen, mais il n'y avait pas d'exemple pour pouvoir juger.

  5. #485
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 675
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 6 675
    Points : 30 458
    Points
    30 458
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Dans le fil présent, Doloop ne donne pas d'exemple de code. Donc les intervenants extrapolent. Vraisemblablement, les détracteurs ont projeté leurs propres capacités et celles de certains de leurs collègues en se disant "si moi ou tel collègue code avec la démarche de Doloop, alors le code sera mauvais, donc le code de Doloop est sûrement mauvais". En vrai, peut-être que le code de Doloop est largement plus maintenable que celui d'un développeur moyen, mais il n'y avait pas d'exemple pour pouvoir juger.
    This.
    Mon équipe ne fait pas de fioritures, et encore moins d'étape de conception ou autres trucs pompeux. On prend la demande du designer, puis on implémente ce qu'il faut dans l'engin pour le supporter.
    Au mieux si on a un doute on va discuter un peu (où placer ça ? a-t-on déjà ceci qui aiderait ? ce machin ressemble, on peut l'améliorer ou c'est spécifique pour autre chose ?), mais 95% du temps c'est juste de l'implémentation directe. KISS puis tu itères.
    À côté j'ai vu des équipes avec des designs super (trop) précis qui détaillent tout et dont les programmeurs sont incapables d'écrire un code correct et surtout facilement maintenable ou évolutif. Leur point commun c'est des personnes qui n'en sont pas conscientes et croient écrire du bon code ou gérer quelque chose de difficile (alors que la difficulté réside uniquement sur la chaise et le résultat est simplement over-complexe pour rien, parce que telle notion du langage, moteur ou projet n'est pas connu ou ignoré).
    La différence c'est l'expérience de chacun. Et à défaut, je ne fais pas confiance. Mais tu remarques normalement vite qui tu peux laisser faire et qui tu dois surveiller.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  6. #486
    Futur Membre du Club Avatar de vivid
    Profil pro
    Inscrit en
    février 2006
    Messages
    115
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 115
    Points : 6
    Points
    6
    Par défaut
    Ce fil me fait penser a pote qui voulait faire du vélo, mais tourner autour du pot sur des choix, ici d'équipement. Donc FAIT et réajuste après le tir suivant des objectifs.

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