Ce qui fait la différence entre un simple projet et un bon projet

**Franck SORIANO** · 13/05/2008, 13h18

Envoyé par el_slapper

ça me fout les jetons, ça. J'ai eu l'exemple VRAI d'un forfait ou les cas-tests étaient écrits à l'avance. Sur certaines fonctions, les types avaient codé en dur les réponses au cas test(par exemple, pour une somme de 1000, avec 4,5% d'interêt, le cas-test attendait 45. Alors le programme donnait toujours 45. Quel que soit le montant ou le taux d'interêt).

Dans les grosses structures très orientées planning et budget, on trouve parfois une version légèrement différente :
- On n'a pas le temps de finir le dev. Donc les devs codent des méthodes vides à la place, qui retournent des constantes au lieu de faire le calcul.
- Le dev est ainsi livré en respectant les délais. Et passe en tests.
- Evidemment les tests disent que ça ne marche pas et ça retourne aux devs pour correction.

Sauf que cette fois, c'est comptabilisé dans la phase de test et maintenance (donc sur un budget différent) et plus sur la phase de dev initial.
Il paraît qu'il y a quelques années, c'était très pratiqué chez Microsoft (bon depuis je crois qu'ils ont compris et qu'ils travaillent différemment).

Mais j'ai un collègue qui faisait une mission pour une banque. Ils devaient développer une interface qui produisait un fichier. Au moment de la deadline, ils devaient fournir un exemple de fichier généré à l'équipe de test pour validation du dev.
Comme le dev n'était pas fini, le chef de mon collègue lui a demandé de faire un fichier à la main sous notepad et c'est ce fichier qui est parti pour valider le dev !

**_skip** · 13/05/2008, 14h49

En bref, même avec des équipes de bonne foi, se baser sur le résultat attendu me semble insuffisant pour prétendre avoir tester la robustesse de l'appli....

Les meilleures méthodologies au monde ne peuvent pas faire face à des situations de négligence ou à des imprévus.
Cependant, le TDD a déjà cela de bon qu'il oblige le développeur à se poser certaines questions et à s'interroger sur les cas de bords. Par ailleurs, je pense personnellement que cela responsabilise la personne qui implémente une fonctionnalité.

Un projet TDD comportera inévitablement un nombre important de tests unitaires, cela permet au fil du temps de limiter la régression lorsque les fonctionnalités évoluent... ou même après un simple refactoring.

Ce n'est pas pour autant un remplacement du testeur humain, mais cela permet d'automatiser des opérations qui seraient fastidieuses et très onéreuses en temps si le testeur devait les déclencher manuellement ou se mettre dans la situation précise pour laquelle ces opérations s'exécutent.

**el_slapper** · 13/05/2008, 15h04

ouh là, beaucoup de choses en peu de mots.

Envoyé par _skip

Les meilleures méthodologies au monde ne peuvent pas faire face à des situations de négligence ou à des imprévus.

on est bien d'accord jusque là.

Envoyé par _skip

Cependant, le TDD a déjà cela de bon qu'il oblige le développeur à se poser certaines questions et à s'interroger sur les cas de bords. Par ailleurs, je pense personnellement que cela responsabilise la personne qui implémente une fonctionnalité.

j'ai du mal à voir en quoi. Le développeur, au lieu de suivre une spécification, suit un résultat attendu. La spec' dit :
_"en cas de décès, annuler le dossier et envoyer le courrier 037 au trésor"
le test dit
_"faire mourir le client de test; vérifier le bon envoi du courrier 037 au trésor"

en quoi celà est-il impliquant ou responsabilisant?

Envoyé par _skip

Un projet TDD comportera inévitablement un nombre important de tests unitaires, cela permet au fil du temps de limiter la régression lorsque les fonctionnalités évoluent... ou même après un simple refactoring.

Il comporte un nombre important de tests unitaires si le concepteur a bien fait son boulot. Si il a oublié le cas ou le client casse sa pipe, le testeur expérimenté, lui, a de fortes chances d'y penser(il a déjà eu le cas sur une autre appli).

En fait, ce qui me gène là-dedans, c'est qu'on part du principe que la spécification se suffit à elle-même en termes de testing. Alors que dans une démarche classique, le testeur repasse derrièrre pour mettre en place son propre cahier de tests, et sert de deuxième barrage aux oublis intempestifs de la spécification(après le codeur, qui parfois aussi a de bonnes idées).

Envoyé par _skip

Ce n'est pas pour autant un remplacement du testeur humain, mais cela permet d'automatiser des opérations qui seraient fastidieuses et très onéreuses en temps si le testeur devait les déclencher manuellement ou se mettre dans la situation précise pour laquelle ces opérations s'exécutent.

automatiser? En quoi le fait d'écrire les cas-tests comme guide de base pour le développeur est-il une conditino obligatoire pour automatiser le test? Sur une application avec une spec classique, si l'environnement technique s'y prête, rien n'interdit au testeur de se farcir(ou de faire faire) ses propres automatismes de test. La démarche que tu présentes le guidera simplement vers une manière de faire spécifique.

**_skip** · 14/05/2008, 09h37

j'ai du mal à voir en quoi. Le développeur, au lieu de suivre une spécification, suit un résultat attendu. La spec' dit :
_"en cas de décès, annuler le dossier et envoyer le courrier 037 au trésor"
le test dit
_"faire mourir le client de test; vérifier le bon envoi du courrier 037 au trésor"

en quoi celà est-il impliquant ou responsabilisant?

On ne donne pas au développeur un cas de test pour lui demander d'écrire à l'aveugle des fonctions qui résolvent ce test au lieu de lui décrire une fonctionnalité. Je n'ai jamais dit ça.

Simplement que le développeur qui implémente une fonction va commencer par écrire les tests unitaires AVANT la fonction.
Suppose qu'il doive implémenter une fonction de calcul du montant d'intérêt d'un compte bancaire.
Ecrire des tests unitaires va le forcer à se poser des questions du style "que devra-t-il se passer si..."

-Implicitement, il va penser au cas ou le compte fourni en paramètre existe pas, et donc clarifier quelle sera la réaction du programme dans ce cas précis. c'est un début de réflexion sur la gestion d'erreur.
-Par ailleurs, il va écrire un test unitaire pour chacun des types de comptes afin de couvrir les différents chemins empruntés par sa fonction.
-Les cas critiques auront aussi leur test, afin de vérifier que la fonction réagit correctement, retour d'erreur, exception etc...

Ensuite seulement on se lance dans l'implémentation concrète, on va faire en sorte que les tests passent. Fin de l'implémentation on rejoue les tests unitaires, puis ensuite si nécessaire on refactor le code pour qu'il soit bien propre et organisé.

Résultat des courses, on a un code sur lequel les réflexions importantes comme la gestion des cas de bords ont été menées et de plus, on a des tests qui seront très pratique pour tester la non-régression à l'avenir.

Le développeur est obligé de se poser la question des cas de bord, obligé de tester son code et c'est pour cela que j'ai parlé de responsabilité.

Il comporte un nombre important de tests unitaires si le concepteur a bien fait son boulot. Si il a oublié le cas ou le client casse sa pipe, le testeur expérimenté, lui, a de fortes chances d'y penser(il a déjà eu le cas sur une autre appli).

En fait, ce qui me gène là-dedans, c'est qu'on part du principe que la spécification se suffit à elle-même en termes de testing. Alors que dans une démarche classique, le testeur repasse derrièrre pour mettre en place son propre cahier de tests, et sert de deuxième barrage aux oublis intempestifs de la spécification(après le codeur, qui parfois aussi a de bonnes idées).

J'ai jamais dit ça non plus, les tests unitaires écrits en TDD ne sont pas le dernier rempart avant la livraison client, tout bon projet est testé par un humain avant une release. Toutefois ça augmente considérablement les chances du développeur de s'apercevoir tout de suite lorsqu'il casse une fonctionnalité, pas 15 jours plus tard soit 1 jour avant la release, à un moment ou plus personne ne sait dire pourquoi ça marche plus, ce qui a été touché. Etc..

automatiser? En quoi le fait d'écrire les cas-tests comme guide de base pour le développeur est-il une conditino obligatoire pour automatiser le test?

Oh! ça c'est une question intéressante et ça nécessite une comparaison démesurée :
En quoi le fait d'utiliser un IDE est-il une condition obligatoire pour faire du code propre? En rien... Toutefois ça aide et ça te guide plus ou moins vers un meilleur résultat ou une meilleure productivité que bloc note et la compilation à l'aide d'une ligne de commande à 200 paramètres

.

SI tu bosses en TDD, tes tests unitaires sont là pendant toutes les phases du cycle de développement, ils peuvent être rejoués facilement et dégrossir fortement le boulot de l'équipe de test *humaine*. Est-ce qu'on peut travailler autrement qu'en TDD et écrire des tests unitaires? Oui bien sûr, sauf qu'en TDD ça fait carrément partie du processus.

**souviron34** · 14/05/2008, 13h35

Sans intervenir dans votre débat, ma position ayant déjà été donnée avant, juste sur ceci :

Envoyé par _skip

En quoi le fait d'utiliser un IDE est-il une condition obligatoire pour faire du code propre? En rien... Toutefois ça aide et ça te guide plus ou moins vers un meilleur résultat ou une meilleure productivité que bloc note et la compilation à l'aide d'une ligne de commande à 200 paramètres

.

c'est faux. ça fait même en général du code beaucoup plus "dégueu" que ce qu'on fait sans.

Le seul gain est celui de la "productivité", permettant d'utiliser des programmeurs avec moins de connaissances...

**_skip** · 14/05/2008, 14h05

Envoyé par souviron34

c'est faux. ça fait même en général du code beaucoup plus "dégueu" que ce qu'on fait sans.

Le seul gain est celui de la "productivité", permettant d'utiliser des programmeurs avec moins de connaissances...

Beaucoup de gens ne seraient pas d'accord avec toi comme tu t'en doutes sûrement

. Par ailleurs le rapport avec la connaissance du développeur m'échappe quelque peu.

**souviron34** · 14/05/2008, 14h47

Envoyé par _skip

Beaucoup de gens ne seraient pas d'accord avec toi comme tu t'en doutes sûrement

. Par ailleurs le rapport avec la connaissance du développeur m'échappe quelque peu.

au point 1), je sais bien

mais c'est la réalité.. Dans TOUS les projets sur lesquelles j'ai travaillé, ça a été le cas...

Même les ide bien conçus comme Delphi produisent quand même du code plus complexe que si il était fait à la main.

Pour le point 2), suffit de voir les forums GTK, wxwidgets, etc.. Plus facile que X, sur lequel c'est pourtant basé. Pour faire des choses simples, (et la plupart du temps pas très jolies) ça suffit. Mais apprendre X et sa philosophie est plus long, donc moins rentable...

**davcha** · 15/05/2008, 12h51

1) Tu parles du RAD, non ? Mais qu'est-ce qui t'empêche, exactement, d'écrire, ton code à la main quand tu utilises un IDE ?...
Tu préfères vraiment travailler sans code-hints, sans auto-complétion lors de la saisie, sans outils de refactoring, sans validation du code intégré à l'éditeur, sans .... la liste est longue. Bref tu préfères travailler avec un bloc notes ?

2) C'est peut-être pas ton univers, mais tu préfères travailler directement avec les api windows qu'avec dotnet pour faire une interface graphique sous windows dans le cadre de la réalisation d'une appli bureautique ?

3) "C'était mieux aaaavant !..." ?

**_skip** · 15/05/2008, 13h15

Je pense qu'il a voulu souligner quelques problèmes liés aux IDE et aux automatismes qu'ils offrent lorsque ceux-ci sont mal compris par l'utilisateur.

Je lis parfois sur ce forum des mecs qui se vantent de ne bosser qu'avec un bloc-note à coloration syntaxique, ça ne les met pas en valeur je trouve car une des plus grosses préoccupation dans l'informatique, c'est la productivité. Ne pas bosser avec les outils adaptés c'est ne rien comprendre à ce problème.

Le développeur doit pouvoir focaliser ses efforts sur le projet, pas sur des tâches rébarbatives et automatisables, pas sur le fait de savoir de tête que c'est /p qu'il faut mettre au compilateur au lieu de /h.

Les aides au développement sont donc toutes bonne à prendre, dans la mesure ou elles ne deviennent pas des boîtes noires... Je pense que c'est ce dernier point auquel souviron a fait allusion.

**el_slapper** · 15/05/2008, 14h27

Sur la clarté du code, je dirais qu'un générateur de code n'est valable que si il permet de TOUT faire. Il m'est arriver de générer du code cobol(le générateur n'est plus commercialisé, ce qui mettait d'ailleurs le client dans la mouise), puis de devoir trifouiller le code généré à la mimine. Le code généré était infâme. D'ailleurs, il l'est sans doute toujours.

un outil de dév qui est une solution complète, pourquoi pas - même si certains éléments sont moins élégants. Mais des trucs à droite à gauche....buerk.

**_skip** · 15/05/2008, 16h33

L'un des principes dans la génération de code, c'est justement de ne pas toucher à ce qui est généré, juste éventuellement étendre ce qui a été généré, mais on devrait en principe être capable de refaire une génération par dessus sans perdre ses changements.

Dans le projet sur lequel je travaille actuellement, les classes d'accès à la base de données et les entités correspondantes aux tables sont à 98% du généré.

**hed62** · 15/05/2008, 16h53

Moi de même, aucun code généré n'est retouché, par contre il est étendu. C'est effectivement une précondition à la génération de code.

**souviron34** · 16/05/2008, 02h04

peut-être , mais vous êtes jeunes

ce que je veux dire, c'est que quand on est seul sur un projet, que le projet est petit, oui pourquoi pas...

Des équipes de 10, 20, 60 programmeurs, des projets de plsuieurs centaines de milliers de lignes, des durées de ve de plusieurs années , voire dizaine d'années, c'est de la folie pure que de vouloir laisser le générateur décider..

Je répète, le code est "dégueu" : pas structuré en bibliothèques, mal découpé, pas de réutilisation quand c'est possible, une méthode par action ET par objet, etc etc...

La catastrophe assurée dans les gros projets...

**_skip** · 16/05/2008, 08h51

Des équipes de 10, 20, 60 programmeurs, des projets de plsuieurs centaines de milliers de lignes, des durées de ve de plusieurs années , voire dizaine d'années, c'est de la folie pure que de vouloir laisser le générateur décider..

Je répète, le code est "dégueu" : pas structuré en bibliothèques, mal découpé, pas de réutilisation quand c'est possible, une méthode par action ET par objet, etc etc...

Je parlais spécialement de la génération d'une couche de mapping objet, si on suit ta généralisation, on devrait donc écrire tout ça à la pogne, avec du code SQL en chaine de caractère. Le tout à grand coup de copier-coller?
Tu sais, il existe des générateurs très performants et très paramétrables de nos jours, qui produise du code d'une qualité très respectable.

**hed62** · 16/05/2008, 09h16

Je suis assez d'accord avec skip, sur le projet dont je parle, nous sommes une cinquantaine (tous métiers compris, il y a une vingtaine de developpeurs), la charge est environ de 15000jH sur 3ans, et toutes les couches "basses" comme l'accès aux bases de données, les proxy des web services sont générés. Idem pour l'implémentation des webservice, l'enveloppe est générée, nous codons le corue métier.

Il n'y a aucun problème de 'saleté' (bien que je convienne que le générateur puisse être amélioré, il n'y a rien d'irrémédiable), et chaque objet métier est extensible pour apporter les contrôles/méthodes complexes du domaine (assurance vie)

pas structuré en bibliothèques

Etant en C#, nous n'avons pas de bibliothèque, mais des DLL, c'est tout comme. Nous avons une DLL par niveau d'accès (SQL, Objets métiers bas niveau générés, Objets métiers haut niveau et étendus).

mal découpé,...une méthode par action ET par objet

Comment cela? Pourrais tu donner un exemple ?

Personnellement, je n'imagine pas le temps de developpement, et le nombre incroyable de saleté que nous introduirions si tout cela n'était pas généré. Au moins le code est uniforme.

splash68 · 16/06/2009, 17h59

Pour moi un bon projet est avant tout un projet vendable...Surtout dans la société d'aujourd'hui ;
Un projet peu être très bon, mais si personne n'en veut...peut-on encore parler de bon projet !?

**Furikawari** · 17/06/2009, 09h05

Envoyé par splash68

Pour moi un bon projet est avant tout un projet vendable...Surtout dans la société d'aujourd'hui ;
Un projet peu être très bon, mais si personne n'en veut...peut-on encore parler de bon projet !?

Euh en toute rigueur le coté vendable c'est le job du commercial, la réussite du projet vient du chef de projet et de ses ouailles. En quoi un mauvais commercial qui ne vendrait rien ferait un mauvais projet ?

splash68 · 17/06/2009, 11h40

Je suis d'accord avec le fait que la réussite du projet vient du chef de projet et de ses ouailles. Mais se que je veu dire c'est que un projet peut etre mené parfaitement et etre très bon techniquement mais aujourd'hui on ne peut plus se détaché du coté commercial.
A quoi bon faire un excellent projet (quel qu'il soit) s'il n'interesse personne ?
Je pense qu'un chef de projet aujourd'hui ne peut plus se passé d'analysé si un projet est viable commercialement avant de commencé à codé quoi que se soit.
Pour moi si un projet n'est pas vendable (car trop spécifique par exemple) ou n'interesse personne, c'est un mauvais projet.

**Furikawari** · 17/06/2009, 11h47

Envoyé par splash68

Je suis d'accord avec le fait que la réussite du projet vient du chef de projet et de ses ouailles. Mais se que je veu dire c'est que un projet peut etre mené parfaitement et etre très bon techniquement mais aujourd'hui on ne peut plus se détaché du coté commercial.
A quoi bon faire un excellent projet (quel qu'il soit) s'il n'interesse personne ?
Je pense qu'un chef de projet aujourd'hui ne peut plus se passé d'analysé si un projet est viable commercialement avant de commencé à codé quoi que se soit.
Pour moi si un projet n'est pas vendable (car trop spécifique par exemple) ou n'interesse personne, c'est un mauvais projet.

Ce n'est pas son job. Un projet ce n'est pas de la génération spontanée, il y a en amont des personnes qui ont étudié la viabilité économique.