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. #81
    Futur Membre du Club
    Salut à tous,

    Merci à tous et merci M. Cedric Girard de nous faire part de l'extreme programming, suite à la lecture du site, cela correspond exactement à ce qu'est la programmation que j'ai nommé spontanée.
    Il y a longtemps sans avoir de nom, j'avais déjà eu des échos sur des concours de programmation (tournois au USA) se passant sur plusieurs jours, comme ceux qui pratiquent les jeux en réseaux, ils étaient capables de réaliser des programmes sur mesures en un minimum de temps, ils en faisaient donc partie.

    Il serait même possible de la qualifier de programmation temps réel, du fait qu'elle ne se base que sur le résultat obtenu, et que l'algorithme du programme est conçu et optimisé, à chaque fois pour le mieux au moment de sa saisie et de son étude simultanées.

    C'est avant tout une question de méthode qui se base sur l'expérimentation, plus on programme, plus ça devient facile.
    Pour les algorithmes, il y a toujours plusieurs solutions, seule l'expérience nous fera choisir la plus adaptées pour le futur du programme.
    J'ai remarqué qu'au fils du temps on s'attache plus au coté technique, si l'on regarde bien dans un programme, il y a beaucoup de morceaux d'algorithme qui sont du déjà vus.

    Cela se base aussi sur l'anticipation, si l'on peut augmenter les possibilités d'un sous programme ou d'une fonction, on réalise la modification immédiatement, de cette façon il n'est plus utile de revenir dessus par la suite.
    (C'est sûr pour les entreprises qui vivent des mises à jours, ils se doivent de calmer leurs ardeurs. Ou bien leurs laisser réaliser la version entière et débrider des morceaux au fils des numéros.)

    Pour moi, la programmation remplace un jeu de stratégie ou de logique.
    Ce type de programmation arrive à me faire penser au mastermind, où à chaque départ de jeux on commence à découvrir à chaque fois au moins 4 couleurs bien placées sur les 5 (structure), dont il ne reste plus à découvrir la 5 eme (paramétrage).
    On ne se base que sur le résultat obtenu, c'est la recherche du principe logique à découvrir, on s'adapte sans cesse au fonctionnement du langage de programmation et de l'ordinateur, ainsi qu'à leurs caprices.
    Finalement, on passe très peu de temps sur le déboggage, qui s'avère sans difficulté apparente, et que je considère plutôt comme du paramétrage inévitable.

    Il arrive que des parties de programme fonctionnent parfaitement du premier coup, ce qui arrive à me surprendre, car je ne m'attends jamais à ce que cela fonctionne du premier coup, mais ce n'est pas une raison pour ne pas pousser les tests, ou bien tester une autre méthode, si l'on en voit une autre ensuite.

    C'est un type de programmation difficile à expliquer aux autres, même aux programmeurs expérimentés, on a une idée en tête qui va se réactualisée à chaque étapes, on la suit. Si cette idée était fausse, ça ne marcherait pas. Sinon il y aurait plus de chance de gagner au loto, que de réussir le moindre programme.
    Programme bien pensé fonctionnement assuré.
    Programme mal pensé est à recommencer.

    Avec l'expérience, on arrive à débogger par intuition, on parcourt le programme sans toujours savoir précisément ce que l'on recherche, dès que l'on est dessus on sait que c'est là, on réalise quelques tests de confirmation, une modification, le bogue est décelé et résolu.
    On isole mentalement chaques étapes du programme comme ceux qui élaborent l'algorithme sur papier, et on les réalise, il n'y a pas de sorcellerie, le programme ne se fait pas tout seul.
    Programmer sur papier ou non, ça n'empêchera pas qu'il faudra quand même passer devant l'ordinateur, de plus un algorithme concu sur papier de tient pas compte de tout, il y aura des modifications à la suite du programme.

    L'extreme programming est une méthode sûr, qui pour moi à déjà fait ses preuves et pas seulement en informatique. (ça doit être possible dans tout les métiers, l'informatique n'en est qu'un parmi tant d'autres)
    S'il fallait procéder autrement, je considérais cet acte comme une régression accompagnées d'une perte de temps. Pourquoi changer une méthode sûr qui marche à chaque fois ?

    Pour modifier un programme, on ne cherche pas à comprendre son fonctionnement, on part uniquement à la recherche de la partie que l'on souhaite modifier ou en rapport avec.
    Si l'on part du principe que le programme sur lequel on est fonctionne sans problème, il ne suffit que de lui apporter une modification au bon endroit, nul besoin de se préoccuper du reste.
    C'est sûr si l'on reprend des programmes d'autres personnes boggés à mort (algorithme mal pensé, illogique, ...), ce sera plus simple de tout recommencer à sa manière, que de corriger ou de masquer les erreurs de conceptions.

    Si je devais dessiner un algorithme, il me serait plus facile de réaliser le programme et de faire l'algorithme ensuite. Bien qu'il ait des programmes où je n'aurais pas envie de réaliser l'algorithme de par le temps que ça va prendre.
    Depuis que je programme, sur 8 ans je n'ai recommencé que 3 morceaux de programmes différents, non pas parce qu'ils ne marchaient pas, mais que j'avais découvert une méthode différente, plus technique à la suite de leurs réalisations.

    Chaque personne ne fonctionne pas pareil, sinon tout le monde aurait les même notes à l'école.
    Finalement, la programmation ce serait plus une question de logique que d'autres choses. De mauvaises notes à l'école ne feront pas forcément de mauvais programmeurs, ce n'est pas un argument à resservir pour en avoir non plus.

    Est-ce que tout le monde peut faire de l'extreme programming ?
    Quelles sont les qualités requises pour y parvenir ?
    Quel peut être le pourcentage des informaticiens qui la pratique ou qui en sont tout simplement capables ?
    Quels sont les points communs de ceux qui pratiquent l'extreme programming ?

    Merci de nous faire partager vos expériences.

    @ +

  2. #82
    Membre averti
    Alors là je précise une chose : XP n'a rien à voir avec la programmation spontannée. XP cherche le moyen le plus simple de résoudre un probleme, pas à prévoir un futur qui peut ne jamais avoir lieu. Surtout, XP ne préconise pas de partir sans un algo sur papier, sauf dans le cas du design émergent, pratique réservée à quelques érudits.

    XP cadre la programmation et cadre surtout le risque, alors que je n'ai pas l'impression que la gestion du risque, du bug, se fasse en programmation spontannée autrement qu'au feeling. En XP, on a des tests automatisés et répétables en quelques minutes, ce qui permet d'être sur de ne pas introduire de bugs. En plus XP ne se limite pas à la programmation, mais integre aussi la gestion de projet, le suivi du travail...

    Est-ce que tout le monde peut faire de l'extreme programming ?
    Quelles sont les qualités requises pour y parvenir ?
    Quel peut être le pourcentage des informaticiens qui la pratique ou qui en sont tout simplement capables ?
    Quels sont les points communs de ceux qui pratiquent l'extreme programming ?
    Contrairement à la PS, oui n'importe qui capable d'accepter les principes XP est capable de pratiquer pleinement XP.
    Qualités requises : communication (avec les collègues, les clients), courage (ne pas cacher un probleme), accepter l'abandon du cycle en V
    Tout le monde en est capable, et iul n'y a pas de chiffres sur le pourcentage de pratiquants.
    Les points communs : la programmation est un travail d'artisan, un travail profondemment communicant et interessant, le coté social est souvent pris en compte par les praticiens.

    Cordialement
    Cédric

  3. #83
    Membre émérite
    ma modeste contribution :

    la programation spontanée est liée a l'experience du developpeur. Pourquoi ? mon resonement est simple :

    la programation, qu'on se le dise, est quelque chose de redondant. Ils arrivent qu'on retrouve souvent les memes algo à ecrire avec des petites variations sans grosses impactes. Exemple :

    sujet : trie a bulle

    le debutant qui ecrit cette algo va l'étudier et ecrire le code qui va avec.

    la 2e fois qu'il devra l'ecrire, il va gribouiller un bout de code pour se le remémorer puis coder.

    la 3e fois il va attaquer le code des le debut.

    Je pense pas qu'il y ait de grosse révolution en terme d'architecture, modelisation et de codage pour qu'on ait besoins de reinventer la roue a chaque fois. La meilleur preuve à ca, c'est les design pattern, des modeles tout fait pour des cas tres généralistes.

    donc c'est principalement l'experience dans un domaine precis qui ammenera à une étude plus ou moins approfondit.

    C'est pour cela également qu'on fait appelle à des "experts" pour aller plus vite et pour se rassurer.
    il y a du linge sur la corde à linge

  4. #84
    Futur Membre du Club
    Merci M. Cedric Girard d'avoir apporter une précision sur la différence de la programmation spontanée et de l'extreme programming.
    Mais pour moi, la différence est très mince, mis à part les tests automatiques, j'ai reconnu beaucoup de propos qui m'ont laisser présumer que l'extreme programming était le terme Anglophone de programmation spontanée.
    L'objectif commun des tous les programmeurs est d'achever leurs programmes dans les meilleurs conditions.

    Les programmeurs XP ne debordent pas du cahier des charges, on peut le comprendre c'est essenciellement du sur mesure.
    Ils recherchent la simplicité, les PS aussi comme tout le monde, c'est plus rapide à faire et le déboggage est réduit.

    En PS des tests pour déceler des bogues sont effectués couramment pour s'adapter au résultat, c'est ce qui déterminera la direction à prendre.
    Des programmes de tests peuvent être réalisés, mais uniquement sur des points plus délicats (synchronisation fichiers, ...), c'est selon chacun.

    A chaque fois qu'un XP effectue une fonction ou un sous-programme, donc il crée un autre sous-programme spécifique pour les tester ou bien en utilise un déjà existant.
    Vous avez aussi des programmes pour tester le code source en vue de l'optimiser et de trouver tout erreur de saisie, ...
    Il faut reconnaître c'est une programmation très axée sur les bogues.

    Je l'ai déjà employé à mes débuts, c'est du déboggage rapide et ça marche sans problèmes, mais c'est la première fois que je le vois expliqué.

    La programmation en binôme est intéressante.

    L'extreme programming est une innovation dans le monde du travail et dans l'ensemble un bon concept.

    Comme dans tout les métiers plus ont pratique plus on y arrive facilement, mais si l'on se souvient de ses débuts en programmation, on se souvient de notre première rencontre insurmontable avec les bogues.
    Un programmeur qui débogue vite est un programmeur qui passe au plus vite à la suite.
    Avec du recule, on peut s'aperçevoir que les bogues sont du déjà vus, et à force d'en traiter, on arrive à deviner leurs origines.
    L'expérience sert à effectuer le meilleur choix selon les circonstances. Alors que lorsque qu'on début si l'on en voit un, c'est déjà bien.

    Il serait intéressant de connaître les méthodes de tous les autres programmeurs, en expliquant à leurs tours leurs méthodes de déboggages, ...
    On a tous à apprendre les uns des autres, à condition de savoir comment chacun fait.

    Merci de faire part de vos techniques.

    @ +

  5. #85
    Inactif  
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    #include<stdio.h>
    #include<time.h>
    #define S&#40;q&#41;B&#40;*e=0&#41;,q,p&#41;;
    #define W&#40;w&#41;if&#40;&#40;w&#41;<22&#41;v= -v;else v-=10;else
    #define F for&#40;r=d;r<d+N;
    #define H&#40;v,g&#41;v=h&#40;v,*g++= *r++&#41;,*g=0;
    #define B&#40;n&#41;b&#40;l,n&#41;,&#40;V&#41;printf&#40;l
    V
    exit&#40;&#41;;char*g,c&#91;M&#93;,d&#91;N&#93;,q&#91;N&#93;,p&#91;N&#93;,*e,*r=d+N,l&#91;M&#93;,*t="??",*k,*m="DEATHISDSev2oinpohae3ttsluuln4a?uibfe 5l\0rtlfrb6 ?a?el&#58;e7$!n\0?e t8%ccp\0.%s9deelc.s T.@?-t.\t<J /\0=a\nP=Q Sex \0l KW Sin a$\0ane-lay% ge#-slediefuk ar  r$via-&#58;o ?+&#125;&#58;r? n \0&#58;&#41; ee%lone 1-esy666!-~v\n.!^`'~@#\0\np~===&#58;=q";b&#40;o,n&#41;char*o;&#123;for&#40;k=n+m;*o++=*k;k+=9&#41;;&#125;int
    y=M*2,v,x,s,f,j,o;u&#40;s&#41;&#123;B&#40;s&#41;&#41;;if&#40;!gets&#40;l&#41;&#41;exit&#40;0&#41;;return&#40;o=
    *l&#41;=='y'||o=='Y'||o!='n'&&o!='N'&&u&#40;s&#41;;&#125;h&#40;v,m&#41;&#123;for&#40;k=c;*k!='J';&#41;if&#40;m==*k++&#41;break;m=k-c;if&#40;v<0&#41;W&#40;v=m-v&#41;
    if&#40;m==1&#41;W&#40;v+=11&#41;
    v+=m;return
    v;&#125;main&#40;w,z&#41;char**z;&#123;b&#40;c,2&#41;*X;for&#40;--w&&&#40;y=atoi&#40;1&#91;z&#93;&#41;&#41;;y>1;&#41;&#123;if&#40;r-d>N*3/4&#41;&#123;B&#40;8&#41;&#41;;F++r&#41;*r=c&#91;&#40;r-d&#41;%13&#93;;F&#41;w=
    *&#40;g=d+rand&#40;&#41;%N&#41;,*g=
    *r,*r++=w;r=d;&#125;for&#40;;;&#41;&#123;B&#40;3&#41;,y&#41;;if&#40;!gets&#40;l&#41;||&#40;w=atoi&#40;l&#41;&#41;<1&#41;exit&#40;0&#41;;if&#40;w&1||w>M||w>y&#41;B&#40;1&#41;,y<M?y&#58;M&#41;;else
    break;&#125;y-=w,s=f=j=x=v=0,g=q,e=p;H&#40;x,g&#41;H&#40;x,g&#41;H&#40;v,e&#41;H&#40;v,e&#41;*t=
    *q;S&#40;t&#41;*q=='A'&&y>=w/2&&u&#40;5&#41;&&&#40;y+=&#40;3*&#40;h&#40;0,1&#91;q&#93;&#41;==10&#41;-1&#41;*w/2&#41;;if&#40;x==-21&#41;goto
    _;if&#40;v==-21&#41;&#123;y+=w/2;goto
    _;&#125;while&#40;x>-17&&x<17&#41;H&#40;x,g&#41;while&#40;&#40;v==20||*p==-1&#91;e&#93;&#41;&&y>=w&&u&#40;6&#41;&#41;&#123;y-=w;++s;for&#40;g=e++;2&#91;g&#93;=
    *g,g!=p;&#41;--g;*g++=
    *e;*g=' ';i&#58;v=h&#40;h&#40;0,*p&#41;,*e++=
    *r++&#41;;S&#40;t&#41;if&#40;*p=='A'&&-1&#91;e&#93;!=
    *p&#41;goto
    _;&#125;if&#40;f=y>=w&&u&#40;7&#41;&#41;y-=w,H&#40;v,e&#41;while&#40;!f&&v<22&&u&#40;4&#41;&#41;&#123;H&#40;v,e&#41;if&#40;v<22&#41;S&#40;t&#41;&#125;_&#58;x<0&&&#40;x=
    -x&#41;;v<0&&&#40;v=
    -v&#41;;if&#40;v<22&#41;if&#40;v==x&#41;j+=w*++f;else
    if&#40;x>21||v>x&#41;j+=w*2*++f;if&#40;s--&#41;&#123;*e++=' ';*e++=
    *p;*e=0;for&#40;e=p;*e=2&#91;e&#93;;&#41;e++;goto
    i;&#125;y+=j;S&#40;q&#41;&#125;;&#125;
    
    
    Copyright &#40;c&#41; 1990, Landon Curt Noll & Larry Bassel
    C'est du 'C', ça marche, ça fait quelque chose de pas complètement crétin, ça ne fait pas 800 000 lignes et pourtant j'ai comme l'impression que cela ne doit pas être facile à maintenir, peut-être quelques commentaires seraient utiles, non ?
    Cet exemple n'est pas plus falacieux que de prétendre que les commentaires sont inutiles sous prétextes que certains ne servent à rien
    J'affirme péremptoirement que toute affirmation péremptoire est fausse
    5ième élément : barde-prince des figures de style, duc de la synecdoque
    Je ne réponds jamais aux questions techniques par MP

  6. #86
    Membre actif
    hum, de mon expérience perso, je sais pas trop dans quel sens comprendre le terme "spontané".

    La programmation n'est qu'une étape dans un projet. Elle n'est qu'une petite partie en plein milieu d'un projet. Avant il y a l'analyse, après la maintenance, et la phase de réalisation doit évidement prendre l'amont et l'aval.

    Donc il est impensable (à moins qu'il s'agisse d'un tout petit projet) de ne pas prendre en considèration une phase d'analyse et de ne pas penser à faciliter la maintenance.

    Lors de projet important, lors de l'écriture de chaque composant, on a besoin d'une vision globale du projet. Sans phase d'analyse, c'est impossible si le projet est important. De plus, en général, on réalise un programme pour un client et non pour soi, il est donc rare de connaitre totalement ce que doit faire le programme.

    Par contre, si on considère le terme "programmation spontanée" comme le fait d'être capable de "pisser du code", enfin, un algorithme complexe capable de réaliser une tache sans avoir à y reflechir plus que ca juste avant de l'écrire, ca j'en suis capable. Je n'ai pas besoin d'un gros effort de reflexion pour ecrire une fonction ou un algorithme. J'ai besoin d'avoir une vision globale, de connaitre le but et les opérations que doivent réaliser mes composants, par contre, pour ce qui est de l'écriture et de l'algorithme, j'écris ca très facilement ...

    Mais dans tous les cas, il faut bannir la programmation sans analyse préalable... parce que là, c'est pas des bugs, c'est des erreurs de conceptions qui vont arriver ... et le cout de maintenance explose ...
    Java/J2EE, PHP, ASP.NET

  7. #87
    Inactif  
    J'ai essayé, mais je n'ai pas pu lire tout (6 pages...), alors voici mon expérience personnelle sans tenter de la théoriser :

    Je programme dans 2 environnements différents :
    1) chez moi, pour mes besoins propres et/ou mon plaisir
    2) professionnellement

    Chez moi, je programme de "relativement" petites choses (20 tables dans la bases), et surtout je suis le créateur du besoin, dans cet environnement il est très très rare que je fasse une analyse/conception/modélisation.... très détaillé, parce que je connais très bien mon besoin, j'ai les tables en tête parce que c'est en termes relationnels que j'exprime mes besoins (à moi-même).
    Professionnellement, les besoins sont exprimés par d'autres personnes connaissant généralement bien leur métier, mais qui ne savent pas l'exprimer (normal, ce n'est pas leur métier) en termes relationnels, ou objets, ou..., sans compter tous les non-dits ou pire les habitudes archaïques (pour ne pas dire obsolètes) de gestion, d'où la nécessité d'un langage commun (c'est la volonté d'UML) ; d'autre part je travaille sur des systèmes où 300 tables représentent une moyenne basse, et là j'avoue, à ma grande honte : si je ne reprends pas le MCD (ou le MPD si le MCD n'est pas disponible) de temps en temps, j'ai du mal à visualiser les interactions de 300 objets (avec des classes à la place des tables, le problème est le même).
    Je ne parlerais pas du travail d'équipe, je pense que tout a été dit ici sur ce sujet.
    J'affirme péremptoirement que toute affirmation péremptoire est fausse
    5ième élément : barde-prince des figures de style, duc de la synecdoque
    Je ne réponds jamais aux questions techniques par MP

  8. #88
    Membre averti
    M. Doloop (je trouve ça un peu froid mais bon, à rome fait comme les romains ;-) )
    Dans la mesure où la programmation spontannée est votre création (au moins le nom, même si d'autres la pratique) alors que XP est une méthode précise, documentée (nombreux livres et sites) je ne pense pas que la liaison soit directe. La PS peut peut être être classée dans les méthodes agiles, famille de XP, mais n'est certainement pas équivalente à XP.
    Vous semblez refuser tout encadrement, XP encadre souplement mais encadre. Les tests unitaires et automatiques sont l'une des bases sans laquelle les autres pratiques n'ont aucun sens : comment remanier sans tests pour garantir qu'on ne fait pas une erreur? Comment travailler à 10 sur un code, avec toutes les différences de niveau, sans tests pour garder la cohérence?
    Ce n'est pas une programmation tres axées sur les bogues, c'est une méthode qui amha accepte l'homme dans son imperfection autant que dans son génie (ce que ne fait pas le classique cycle en V amha toujours). La qualité doit être là, malgré les défauts humains, donc tout est fait pour faire un logiciel fiable.
    Quant à deviner l'origine des bogues, même de très bons développeurs se plantent, or quand il faut livrer, pas d'excuses.
    En résumé, la PS et XP sont aussi éloignés qu'un chien et qu'un chat : ce sont tous deux des animaux, mais ils font les choses différemment.


    Pgibone, les commentaires ne sont qu'une manière de rendre un code lisible. La pratique de nombreux développeurs montre qu'il est possible de rendre un code totalement lisible, à condition bien sur de ne pas utiliser certaines astuces de syntaxe dont le C déborde, et qui en font l'un des langages les plus obscur dans les mains d'un maitre de l'obscurité ;-)


    Cyr1c, tu décris le classique cycle en V. Sauf que... l'experience de nombreux projets ratés ou en retard montre que la spécification initiale parfaite est impossible (on ne peut pas tout prévoir, on n'a pas l'expérience du produit puisqu'il n'existe pas) et qu'elle devra être profondémment revue de toute façon. XP accepte ce fait et le gére. Une phase initiale d'analyse certes, mais sans vouloir tout dire.
    XP dissémine tant l'analyse/spécification que les tests garantissant la qualité tout au long du projet, ce qui évite les grosses erreurs de spécification, et les longues phases pénibles de débogage.

  9. #89
    Inactif  
    les commentaires ne sont qu'une manière de rendre un code lisible
    Bien sur, et je suis partisan d'une règle simple : utiliser une nomenclature claire et complète pour les noms de fonctions, variables, constantes etc.

    fSolde = fTotalCredit - fTotalDebit;

    est plus clair que a = b - c, où même que s = c - d, et ne nécessite aucun commentaire !

    Je n'ai jamais voulu dire que j'étais partisan du code "obfusqué".
    J'affirme péremptoirement que toute affirmation péremptoire est fausse
    5ième élément : barde-prince des figures de style, duc de la synecdoque
    Je ne réponds jamais aux questions techniques par MP

  10. #90
    Membre averti
    Citation Envoyé par pgibone
    Je n'ai jamais voulu dire que j'étais partisan du code "obfusqué".
    Alors on est d'accord, juste un probleme de comm

  11. #91
    Membre émérite

    C'est du 'C', ça marche, ça fait quelque chose de pas complètement crétin, ça ne fait pas 800 000 lignes et pourtant j'ai comme l'impression que cela ne doit pas être facile à maintenir, peut-être quelques commentaires seraient utiles, non ?
    du commentaire pas necessairement, de la mise en page ( espace, saut de ligne ) plus surement
    il y a du linge sur la corde à linge

  12. #92
    Inactif  
    du commentaire pas necessairement, de la mise en page ( espace, saut de ligne ) plus surement
    Je suis quasiment certain que même mis en page plus simplement ce code resterait obscur !
    J'affirme péremptoirement que toute affirmation péremptoire est fausse
    5ième élément : barde-prince des figures de style, duc de la synecdoque
    Je ne réponds jamais aux questions techniques par MP

  13. #93
    Membre averti
    Citation Envoyé par pgibone
    Je suis quasiment certain que même mis en page plus simplement ce code resterait obscur !
    Il est surtout obscur du fait du nommage des variables et de l'utilisation d'astuces C

  14. #94
    Inactif  
    Il est surtout obscur du fait du nommage des variables et de l'utilisation d'astuces C
    Nous sommes donc d'accord : un code mal formé, mal nommé, mal commenté est inutilisable en entreprise, où l'on a toujours besoin de maintenir le code parce que les spécifications évoluent.
    Au risque de choquer beaucoup de gens je suis même un adversaire de l'astuce (je crois que cedricgirard aussi), car une astuce n'est que l'exploitation, éventuellement intelligente, d'une situation à un instant précis au détriment de la nature profonde des objets et de leurs relations. Il est facile de prendre le contre pied de ce que je viens de dire, parce que la frontière entre "nature profonde" et "situation a un instant précis" est fluctuante. Et puis l'astuce est satisfaisante, on se sent tellement malin quand on en trouve une (moi aussi).
    Je suis de la génération qui a dû utiliser en permanence des astuces, soit pour économiser des octets (XOR AX, AX à la place de MOV AX, 0 par exemple) soit pour économiser du temps de traitement (écrire 16 fois les mêmes 15 lignes de codes à la place d'une boucle, parce les tests et les sauts prennent trop de temps), nous étions contraints d'utiliser des astuces, maintenant que ce n'est plus le cas on peut se permettre de penser à la vie du logiciel qui ne s'arrête pas le jour de la livraison
    J'affirme péremptoirement que toute affirmation péremptoire est fausse
    5ième élément : barde-prince des figures de style, duc de la synecdoque
    Je ne réponds jamais aux questions techniques par MP

  15. #95
    Membre averti
    Je pense en effet que les astuces sont bonnes pour les envirronements qui en ont besoin, mais en dehors pas vraiment utiles. La clarté est plus importante que le millioneme de seconde économisé.

  16. #96
    Membre actif
    oui, maintenant, "l'astuce" pour gagner du temps se positionne plus au niveau de l'optimisation d'algorithme complexes et lourd qu'au niveau de l'astuce de programmation.
    Après, en ce qui concerne des applications nécéssitant des calculs temps réels (je pense aux jeux), là l'utilisation d'astuces de programmation peut être necessaire. Néanmoins, les moteurs graphiques sont en général des gros monolithes de code très difficile à maintenir car il a été optimisé de tous les cotés...
    Java/J2EE, PHP, ASP.NET

  17. #97
    Membre averti
    Je dirais que le véritable gain de temps sur les algos lourds vient d'une refonte meilleure de l'algo que sur des optimisations locales. Souvent quand c'est lent c'est que l'algo est mauvais.

  18. #98
    Membre averti
    Le cycle en V est descendu en flammes au profit de l'X programming. Soit.
    Mais il éxiste d'autres cycles de vie adapter au fait que souvent les spécifications de départ sont incomplètes : cycle en spirale, cycle itératif (succession de petits cycles en V).
    J'ai personnellement utiliser le cycle itératif sur un projet ou on ne savait pas trop où on allait, de petits cycles en V de 1 à 3 mois : on garde la maîtrise de l'architecture, les spécifications d'interfaces et logicielles sont à jour, on avance pas à pas. Avec une bonne gestion de configuration, he trouve ce cycle très bien adapté au "on verra après si c'est possible".

  19. #99
    Membre averti
    Citation Envoyé par tut
    Le cycle en V est descendu en flammes au profit de l'X programming. Soit.
    Mais il éxiste d'autres cycles de vie adapter au fait que souvent les spécifications de départ sont incomplètes : cycle en spirale, cycle itératif (succession de petits cycles en V).
    J'ai personnellement utiliser le cycle itératif sur un projet ou on ne savait pas trop où on allait, de petits cycles en V de 1 à 3 mois : on garde la maîtrise de l'architecture, les spécifications d'interfaces et logicielles sont à jour, on avance pas à pas. Avec une bonne gestion de configuration, he trouve ce cycle très bien adapté au "on verra après si c'est possible".
    Pas descendu en flamme, simplement XP propose autre chose et argumente sur l'interet de l'alternative. XP prone de fait un cycle itératif court (une à deux semaines), et XP ne revendique pas d'avoir inventé des pratiques.
    Les cycles itératifs sont bien connus, on fait du TDD dans les années 50. Simplement de les avoir assemblé en un tout cohérent et d'amener une vision du développeur comme un artisan, et non pas un ouvrier.

  20. #100
    Inactif  
    Je suis tout à fait partisan de la vision programmeur = artisan, et même artiste parfois, au sens où un joueur d'échec peut être un artiste ; c'est tout à fait évident quand on peut reconnaître le code d'un programmeur comme on peut reconnaître un joueur rien qu'en regardant une partie (ce qui n'arrive jamais avec les petits joueurs (pas d'offense, je suis un nano-joueur d'échec)).
    J'affirme péremptoirement que toute affirmation péremptoire est fausse
    5ième élément : barde-prince des figures de style, duc de la synecdoque
    Je ne réponds jamais aux questions techniques par MP