Discussion :

[maxim_um]

Salut,

Ce topique est bien, mais il ne me semble pas y avoir vu la notion d'XP abordé. Il est à noter que l'«Extreme Programming» fournit un cadre intéressant au projet pour justement aboutir à quelque chose de bon.

Je rajoute que dans un contexte plus global, il faut toujours se garder d'en faire trop ou pas assez. Si on n’en fait pas assez, on n’aura pas totalement répondu au cahier des charges et il y a le risque de perdre des clients. Si on en fait trop, on perd tout simplement de l'argent.

S'il y en a qui pensent «valeur ajoutée», il est à noter qu'elle se fait sur le service, pas le produits. Quant aux bogues, ils font partie des mœurs, mais aussi de la communication de l'entreprise. Je dirais presque que c'est un moteur de vente ou d'attractivité pour le produit. C'est globalement pour cette raison que le perfectionnisme n'est pas une qualité, du moins dans le domaine de la programmation. Cela dit, certains langages et certains concepts y tendent naturellement (JAVA/C++ [POO]).

Enfin, je conclurais qu’un bon projet est un projet qui donne du travail. Et il sera d'autant plus profitable que ses concepteurs auront su le rendre malléable.

[hegros]

Surtout pas ! Il faut un regard exterieur, un point de vue différent. Sinon, on va tester "pour que cela marche" et c'est tout (à moins d'avoir une excellente rigueur/méthode).

Je ne serais pas aussi affirmatif, en même temps c'est une citation de l'année 2008

Pour rappel le schéma type du DDT est en spiral et en continu.(mais autant ouvrir un autre débat)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
1-Ecrire un code de test qui échoue
2-Ecrire un code de production qui passe le test

Idéalement en binôme pour l'aspect important que tu soulignes à savoir le regard extérieur.

Dans le cas où ce n'est pas la même personne qui écrire le code de test et le code de production cela me fait penser au cycle de développement en cascade mais bon après tout c'est une question d'organisation et de pratique cependant la technique du DDT concerne 2 choses :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
1-Les tests à proprement parlé
2-La conception technique

Se forcer (pour un développeur) à écrire un test AVANT(et il faut bien insister sur le fait de l'écrire avant, un peu comme les commentaires...) le force à réfléchir sur la conception technique (quelle classe créer, quelle méthode et quel paramètre, quel algorithme etc...). Si c'est une autre personne qui écrit le test unitaire alors c'est que la conception est déjà terminée, et ce n'est plus vraiment du DDT, ou alors qu'il est en plein dedans (en conception).


Rapidement sur ce qui fait la différence entre un simple et un bon projet : le client, le produit, le processus de développement, les membres de l'équipe et l'argent !

[souviron34]

Se forcer (pour un développeur) à écrire un test AVANT(et il faut bien insister sur le fait de l'écrire avant, un peu comme les commentaires...) le force à réfléchir sur la conception technique

t'aurait-on fait évoluer légèrement ?

Rapidement sur ce qui fait la différence entre un simple et un bon projet : le client, le produit, le processus de développement, les membres de l'équipe et l'argent !

De toutes façons la question initiale est un peu bête : on peut avoir un projet simple qui soit bon, un projet simple qui soit pas bon, un projet compexe qui soit bon, un projet complexe qui soit pas bon..

[maxim_um]

De toutes façons la question initiale est un peu bête

Peut-être mal exposé, mais certainement pas bête. De toute façon, l'intention a été clairement précisée dans les postes qui ont suivi.

[splash68]

t'aurait-on fait évoluer légèrement ?






De toutes façons la question initiale est un peu bête : on peut avoir un projet simple qui soit bon, un projet simple qui soit pas bon, un projet compexe qui soit bon, un projet complexe qui soit pas bon..

Sur ce point je suis d'accord ! la question initiale est pas mal floue et de plus subjective