Discussion :

[Invité]

Il faut faire gaffe, j'ai déjà vu du prototype (enfin maquette mais c'est pareil) se retrouver en production.

Bah quand la personne a développé la maquette sans code optimisé ou mise en forme (en pensant ne faire qu'une maquette) , quand tu dois le reprendre derrière tu souffres.

Oui c'est normal mais en effet il faut être prudent, c'est cependant préférable de livrer ce proto qui fonctionne bien que ne jamais livrer

[Robin56]

Ensuite au fil du temps, le refactoring permet d'améliorer encore et encore le code.

Le pouvoir du refactoring a ses limites. Quand on part sur de mauvaises bases, on ne peut pas tout miser sur le refactoring pour améliorer la chose. Ce n'est pas pour rien qu'il y a des architectes qui réfléchissent à la structure des applications dès le début d'un projet.

Je préfère un code un peu moche au départ mais qui permet une application qui fonctionne que du code propre d'une application qui ne marche pas.

Entre une application qui marche pour ce qu'on lui dit de faire mais ne peut plus évoluer sans tout casser et une application bien pensée à qui il manque quelques boulons, je ne suis pas certains de faire le même choix que toi.

Et comme Bebel le fait remarquer, faisons attention au symptôme du prototype qui finit en production.

[Invité]

Le pouvoir du refactoring a ses limites. Quand on part sur de mauvaises bases, on ne peut pas tout miser sur le refactoring pour améliorer la chose. Ce n'est pas pour rien qu'il y a des architectes qui réfléchissent à la structure des applications dès le début d'un projet.

En effet, mais ce n'est pas le cas partout, et dans ces situations où on ne peut compter sur une architecte, et où on a des délais à respecter, on ne peut pas toujours passer ses journées à réécrire le code en le perfectionnant au niveau lisibilité alors qu'on a encore rien produit.

Entre une application qui marche pour ce qu'on lui dit de faire mais ne peut plus évoluer sans tout casser et une application bien pensée à qui il manque quelques boulons, je ne suis pas certains de faire le même choix que toi.

Et comme Bebel le fait remarquer, faisons attention au symptôme du prototype qui finit en production.

Oui, enfin un bug peut aussi finir en prod , il faut faire attention à tout, cependant on dévie du sujet, on parle des normes de codage et je parlais surtout du fait que vouloir s'attarder trop à perfectionner son code à l'infini peut finir par ne jamais livrer pas à temps car il y a toujours de quoi améliorer dans le code, il faut parfois poser des limites et se contenter de quelque chose qui fonctionne afin d'avancer.

[transgohan]

Pour les gros systèmes complexes on se retrouve souvent à vendre un prototype en fait...
Quand on doit mettre deux à trois ans pour le faire et qu'après la présentation au client pour décrocher le marché on apprend qu'au lieu des 6ans de dev on a en fait que 2ans pour le faire parce que les commerciaux croient dur comme fer que le projet est presque fini vu que le proto fonctionne...
Bah... Tu fais quoi ?
Tu leur dis que ce n'est pas possible et qu'on va devoir payer 4ans de délai de retard ? Même ton chef veut pas en entendre parler.

[LooserBoy]

Rencontré dernièrement, un certain nombre de webservices développés en C# avec comme obligation d'utiliser une architecture de type automate avec des états/transitions alors que le process métier est purement linéaire. De même pour les business objects qui sont derrière...
Le code est lisible, certes, mais les performances ne sont absolument pas là.
On nous dit que ce n'est qu'un pilote mais combien de pilotes se sont retrouvés en production dans cette boite où j'ai travaillé 3 ans par le passé et où je suis retourné par rachat de la boite où je bossais...

Sans compter l'utilisation extrêmement abondante de traces (logguer les infos, c'est bien mais on arrive à des limites absolument élyséennes...) d'un outil sans aucune fiabilité et extrêmement gourmand tant en ressources qu'en performances.