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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Coder rapidement ou écrire du code de qualité ?
Les deux approches reviendraient au même, selon un célèbre développeur dessinateur

Le , par Idelways
64 commentaires

25PARTAGES

7  1 
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

Une erreur dans cette actualité ? Signalez-nous-la !

64 commentaires
Commenter Signaler un problème
jmguiche
Avatar de jmguiche
Membre averti https://www.developpez.com
Le 12/01/2011 à 8:47
D'après mon expérience, de presque 30 ans, il y a deux types de "clients".

Ceux qui ont l'esprit clair, rationnel et qui sont capable de stabiliser un besoin et de faire la différence entre l'accessoire et l'indispensable. Avec ceux là, il est possible de travailler bien et souvent vite ! Il est possible de concevoir une solution efficace fonctionnellement et propre techniquement, dans les délais.

Et les autres... Ceux avec qui, quelque soit la méthode de développement, le projet coutera au moins le double de ce qu'il devrait, à force d'incohérences, de voltes faces, d'oublies, d'imprécisions, de y'akafaukon, etc...

Tout cela n'a rien à voir avec la méthode employée. Avec une MOA incapable de stabiliser sa demande, les approche "top down" tombent à coté d'une cible qui bouge tout le temps et les approches itératives (extrem programming et autres) ne convergent pas mais tournent en rond.
8  0 
FR119492
Avatar de FR119492
Rédacteur https://www.developpez.com
Le 10/01/2011 à 18:57
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
9  2 
Fifan31
Avatar de Fifan31
Membre averti https://www.developpez.com
Le 12/01/2011 à 21:56
Il est aussi facile de coder à partir des spécifications que de marcher sur l'eau
A condition que les 2 soient gelées
7  0 
Barsy
Avatar de Barsy
Expert confirmé https://www.developpez.com
Le 11/01/2011 à 9:36
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.
6  0 
Barsy
Avatar de Barsy
Expert confirmé https://www.developpez.com
Le 27/01/2011 à 16:43
Le but du commercial reste quand même d'essayer de vendre la baignoire même si le client n'a besoin que d'une douche.

Le but du client par contre est de réussir à acheter la douche au prix du lavabo.

Le défi du développeur sera de réussir à réaliser la "baignoire-douche-lavabo" qui sera un subtil mélange entre les trois solutions et qui au final ne répondra à aucun besoin.
6  1 
pseudocode
Avatar de pseudocode
Rédacteur https://www.developpez.com
Le 10/01/2011 à 17:50
"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)

4  0 
zaventem
Avatar de zaventem
Membre expérimenté https://www.developpez.com
Le 27/01/2011 à 11:02
Citation Envoyé par zeavan Voir le message
Je suis totalement d'accord avec cet avis, en tant que developpeurs nous sommes des super utilisateurs ou super client, il n'a rien de choquant de remetrre en question les exigences du client, apres un apprentissage approfondie de son domain.
Tout comme il n'y a rien de choquant que ton plombier t'installe une douche quand tu demandes un baignoire; après tout, c'est lui le pro.

Ce genre de réflexion me fait vraiment peur
Pourrais-je rappeler qu'in fine, l'informatique n'a pour seul utilité que d'être un support au métier. Ni plus, ni moins. Donnez au client toute les cartes pour qu'il puisse décider en connaissance de cause, qu'il soit conscient des contraintes engendrées par son choix, c'est notre boulot; lui dire ce qu'il veut, c'est aberrant.

PS: le jour où un développeur sera un "super utilisateur" (hormis le cas rare de logiciel destiné spécifiquement aux informaticiens), les entrepreneurs de pompes funèbres seront de "super mort"
5  1 
Barsy
Avatar de Barsy
Expert confirmé https://www.developpez.com
Le 27/01/2011 à 11:14
Citation Envoyé par zaventem Voir le message
Tout comme il n'y a rien de choquant que ton plombier t'installe une douche quand tu demandes un baignoire; après tout, c'est lui le pro.

Ce genre de réflexion me fait vraiment peur
Pourrais-je rappeler qu'in fine, l'informatique n'a pour seul utilité que d'être un support au métier. Ni plus, ni moins. Donnez au client toute les cartes pour qu'il puisse décider en connaissance de cause, qu'il soit conscient des contraintes engendrées par son choix, c'est notre boulot; lui dire ce qu'il veut, c'est aberrant.

PS: le jour où un développeur sera un "super utilisateur" (hormis le cas rare de logiciel destiné spécifiquement aux informaticiens), les entrepreneurs de pompes funèbres seront de "super mort"
Sauf que si le client demande au plombier d'installer une douche en lui disant qu'il veut prendre des bains, je doute que le plombier ne lui fasse pas part de conseils dans ce cas.

Le but n'est pas de développer des fonctionnalités dans le dos du client, mais plutôt d'essayer de comprendre les besoins de celui-ci et proposer la solution que l'on considère la plus adaptée (même si elle peut être discutée ou refusée) plutôt que de se lancer aveuglément dans celle qu'il propose.
C'est un problème récurrent d'ailleurs en informatique, beaucoup de clients demande au développeur de réaliser une solution sans lui faire part des besoins initiaux. Et résultat, ce sont souvent des projets qui se plantent car le client n'a malheureusement pas pensé à tout.

C'est comme si j'allais chez le garagiste pour une panne et, plutôt que de lui expliquer la panne, je lui dis juste quelles pièces il doit changer.
5  1 
gangsoleil
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 28/02/2011 à 11:51
Citation Envoyé par ovh Voir le message
Le chiffrage c'est de la vaste blague... Les délais sont toujours largement sous-estimés... C'est souvent très aléatoire, même pour un dev expérimenté qui est à fond dans un projet, estimer le délai de réalisation d'une nouvelle fonctionalité est très difficile (à part pour certaines tâches simples bien sûr). Et on a très souvent tendance à minimiser.
Moui. Certaines personnes savent faire de vrais chiffrages, qui sont tres souvent corrects, a quelques pourcents pres bien sur.
Mais ca ne veut pas dire que les commerciaux accorderont ce chiffrage au projet.

Par ailleurs, il faut tenir compte de la loi de Hofstadter :
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
4  0 
Nebulix
Avatar de Nebulix
Membre expérimenté https://www.developpez.com
Le 12/01/2011 à 9:07
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
Pour le point 1, la méthode la plus sûre et la plus rentable n'est-elle pas de reservir ce qui a convenu à un client précédent ?
3  0 
Commenter Signaler un problème