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

Idelways · 10/01/2011, 17h27

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

pseudocode · 10/01/2011, 17h50

"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)

eomer212 · 10/01/2011, 18h05

simple, faire en sorte que les spécifications de l'appli ne changent pas toutes les 5 minutes..

kaymak · 10/01/2011, 18h13

Citation:

Envoyé par eomer212

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+

FR119492 · 10/01/2011, 18h57

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:

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

kaymak · 10/01/2011, 19h37

Citation:

Envoyé par FR119492

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:

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.
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+

pseudocode · 10/01/2011, 19h50

Citation:

Envoyé par kaymak

La méthode Gérard majax !

Une variante du Reality distortion field.

spidermario · 10/01/2011, 20h35

Citation:

Envoyé par pseudocode

"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.

bleporini · 11/01/2011, 07h18

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!

Patriarch24 · 11/01/2011, 09h36

Citation:

Envoyé par pseudocode

"Make It Work, Make It Right, Make It Fast", Kent Beck.

+1.

Citation:

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.

Barsy · 11/01/2011, 09h36

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.

rawsrc · 11/01/2011, 09h44

Bonjour

Citation:

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.

martopioche · 11/01/2011, 11h35

Citation:

Envoyé par pseudocode

"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...

pseudocode · 11/01/2011, 11h41

Citation:

Envoyé par martopioche

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".

kaymak · 11/01/2011, 11h51

Citation:

Envoyé par pseudocode

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

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

Citation:

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 +

martopioche · 11/01/2011, 13h36

Citation:

Envoyé par kaymak

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

...

ymajoros · 11/01/2011, 14h44

Citation:

Envoyé par Barsy

"tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

Indiana Jones ?

Barsy · 11/01/2011, 15h07

Citation:

Envoyé par ymajoros

Indiana Jones ?

perdu

Tellen · 11/01/2011, 15h09

Citation:

Envoyé par ymajoros

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.

Barsy · 11/01/2011, 15h14

Citation:

Envoyé par Tellen

Mais non !!! ...

T'aurais pu laisser les gens essayer de deviner un peu...

10/01/2011, 17h27	#1
Idelways Coordinateur publications Développeur Ruby on Rails / iOS et journaliste Inscription : juin 2010 Messages : 1 101 Détails du profil Informations professionnelles : Activité : Développeur Ruby on Rails / iOS et journaliste Informations forums : Inscription : juin 2010 Messages : 1 101 Points : 24 230 Points : 24 230	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
	71

10/01/2011, 17h50	#2
pseudocode Rédacteur/Modérateur Xavier Philippeau Architecte système Inscription : décembre 2006 Messages : 9 403 Détails du profil Informations personnelles : Nom : Xavier Philippeau Âge : 39 Localisation : France, Hérault (Languedoc Roussillon) Informations professionnelles : Activité : Architecte système Secteur : Industrie Informations forums : Inscription : décembre 2006 Messages : 9 403 Points : 14 092 Points : 14 092	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.
	40

10/01/2011, 18h05	#3
eomer212 Membre actif christian Développeur indépendant Inscription : août 2004 Messages : 251 Détails du profil Informations personnelles : Nom : christian Âge : 43 Localisation : France Informations professionnelles : Activité : Développeur indépendant Secteur : Transports Informations forums : Inscription : août 2004 Messages : 251 Points : 184 Points : 184	coder vite, et bien. simple, faire en sorte que les spécifications de l'appli ne changent pas toutes les 5 minutes..
	11

10/01/2011, 18h57	#5
FR119492 Rédacteur/Modérateur Jean-Marc Blanc Inscription : avril 2007 Messages : 2 649 Détails du profil Informations personnelles : Nom : Jean-Marc Blanc Âge : 71 Informations forums : Inscription : avril 2007 Messages : 2 649 Points : 3 482 Points : 3 482	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: 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. 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)
	92

11/01/2011, 09h36	#11
Barsy Expert Confirmé Ingénieur développement logiciels Inscription : octobre 2007 Messages : 1 127 Détails du profil Informations personnelles : Sexe : Âge : 28 Localisation : France, Loire Atlantique (Pays de la Loire) Informations professionnelles : Activité : Ingénieur développement logiciels Informations forums : Inscription : octobre 2007 Messages : 1 127 Points : 2 599 Points : 2 599	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 !!"
	50

11/01/2011, 07h18	#9
bleporini Membre régulier Inscription : juin 2007 Messages : 89 Détails du profil Informations forums : Inscription : juin 2007 Messages : 89 Points : 71 Points : 71	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

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email