Discussion :

[Idelways]

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]

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

[spidermario]

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

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]

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

+1.

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]

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]

Bonjour

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.

[ymajoros]

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

Indiana Jones ?

[notia]

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.

I like this

[el_slapper]

(.../...)
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.
(.../...)

D'accord avec le reste, mais pour les méthodes agiles, je ne suis pas emballé(enfin, pas toujours). Tout simplement parceque l'important n'est pas la méthode, mais que le client ET la MOA soient impliqués. Quand le client suit le projet de près et répond aux questions(et en pose), ça peut être du waterfall à 18 mois, ça marche. Ca eut marché aussi en agile, mais pas parceque c'est de l'agile. Pour moi, le choix de l'agile est surtout intéréssant pour des projets ou on peut tester vite(tout ce qui comporte une interface, tout ce qui est batches quotidiens). Pour les monstres mensuels que je traite actuellement, ça n'aurait aucun sens.

[Mobius]

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.

Je pensais que les méthodes agiles c'était le contraire : voir le graal s'éloigner en perdant du temps.
Expérience observé : Le client décide de passer aux méthode agile pour réduire les cycle de développement en ayant une qualité accrue. Il fait venir un expert agile expliquant à tout le monde comment faire. Après avoir écouté la grande messe, tout le monde met un maximum de bonne volonté, communique chaque matin sur le job de la journée. Il s'est révélé que ce qui devait prendre 5 minute chaque jour pouvait durée plusieurs heures. Le client, se rendant compte au fur et a mesure de l'avancé, peut donner de nouvelles directive (ou changer d'idée) encore plus souvent. Résultat des courses, on passe plus de temps en réunions (donc moins de temps de développement) et le travail est plus rapidement mis à la poubelle.

[pseudocode]

Je pensais que les méthodes agiles c'était le contraire : voir le graal s'éloigner en perdant du temps.
Expérience observé : Le client décide de passer aux méthode agile pour réduire les cycle de développement en ayant une qualité accrue. Il fait venir un expert agile expliquant à tout le monde comment faire. Après avoir écouté la grande messe, tout le monde met un maximum de bonne volonté, communique chaque matin sur le job de la journée. Il s'est révélé que ce qui devait prendre 5 minute chaque jour pouvait durée plusieurs heures. Le client, se rendant compte au fur et a mesure de l'avancé, peut donner de nouvelles directive (ou changer d'idée) encore plus souvent. Résultat des courses, on passe plus de temps en réunions (donc moins de temps de développement) et le travail est plus rapidement mis à la poubelle.

De la bonne volonté et un daily meeting n'est pas suffisant pour combler une absence de gestion projet.

Les methodes agiles mettent en oeuvre des cycles de développement complexes, nécessitant une grande rigueur dans la gestion du projet. C'est justement parce que le cadre du projet est très rigoureux qu'on peut se permettre de modifier le cahier des charges ou le contenu des itérations pendant le développement.

Si déjà on a du mal avec un SDLC simple (waterfall, spiral, sawtooth), il faut éviter de plonger dans l'agile en espérant que ca va magiquement résoudre les problèmes. Enfin, c'est mon avis.

[martopioche]

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

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

[eomer212]

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

[kaymak]

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]

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

[kaymak]

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

La méthode Gérard majax !

Un classique de l'incompétent informaticien, ou du trop expérimenté,
c'est selon ; )

a+

[pseudocode]

La méthode Gérard majax !

Une variante du Reality distortion field.

[Nebulix]

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 ?