Discussion :

[yan]

Salut,
je voulais avoir votre avis sur ma m�thode de programmation. Pour d�velopper un module pour un programme je fais g�n�ralement (en gros, ce n'est pas non plus une ligne strict de conduite):
1- conception

2- un code rapide qui marchote et qui impl�mente le gros de ma conception. Ainsi, j'ai tr�s vite quelque chose qui me permet d'�valuer les lacunes de la conception et surtout les risques futur.

3- si il faut, correction de la conception

4- mise au propre du code et debuggage

5- si besoin correction de la conception

6- optimisation si besoin + dernier bug et warning

Je ne trouve rien � redire, mais comme l'on as jamais raison , je voulais avoir vos avis et comment vous faites.

merci
yan

[wiztricks]

Dans la phase de conception je met l'emphase sur "comment vais je pouvoir tester que cela fonctionne".
Note: et non, je ne suis pas un adepte du TDD.
- W

[Mat007]

Salut,

Personnellement je ne pourrais plus d�velopper quoique ce soit sans �crire de tests unitaires (avant le code utile), �a me laisse vraiment trop une sensation de bricolage et de perte de temps...

MAT.

[yan]

Salut,

Personnellement je ne pourrais plus d�velopper quoique ce soit sans �crire de tests unitaires (avant le code utile), �a me laisse vraiment trop une sensation de bricolage et de perte de temps...

MAT.

Les test unitaire, faut vraiment que je m'y mette .
Ca semble �tre une tr�s bonne chose

[wiztricks]

Salut,

Personnellement je ne pourrais plus d�velopper quoique ce soit sans �crire de tests unitaires (avant le code utile), �a me laisse vraiment trop une sensation de bricolage et de perte de temps...

MAT.

Je ne sais pas ce que vous appelez "tests unitaires", mais personnellement ceux l� je les d�veloppe apr�s en white-box, pour assurer la couverture des
diff�rentes branches de code.
- W

[exterieur]

Salut,
bon pour commencer si tu veux du d�veloppement qualitatif...ta m�thode n'est pas bonne...

1- conception

Cette phase est primordiale, il faut y passer du temps.
Tu peux tr�s bien faire du code en parall�le, mais celui-l� ne doit �tre l� que pour valider la fesabilt� de tel ou tel concept.

2- un code rapide qui marchote et qui impl�mente le gros de ma conception. Ainsi, j'ai tr�s vite quelque chose qui me permet d'�valuer les lacunes de la conception et surtout les risques futur.

Cela fait partie de la phase 1 en fait...

3- si il faut, correction de la conception

Cela fait partie de la phase 1 aussi.

4- mise au propre du code et debuggage

Non, ici ce n'est pas une mise au propre du code mais bien une phase de codage � proprement parl�.
On ne fait pas de codage en m�me temps que de la conception... Tu peux v�rifier la fesabilit� de certaine chose par un test concret (donc un code de test) mais la phase de codage doit vraiement partir de ton doc de conception.

5- si besoin correction de la conception

Erreur, on ne corrige pas une conception apr�s avoir cod�. Cela peut para�tre pratique pour une petite appli toute gentille mais d�s que tu touches � des grande applis, corriger ta conception par rapport � ton code signifie tout bonnement que tu as mal con�u ton code...
C� veut dire aussi que tu n'es pas capable de dire arriv� � ta phase de codage que ta phase de conception est termin�e, tu ne peux pas pr�voir en terme de planning si ton projet d�rape ou non.
Il peux y avoir des retouches du document de conception dans la phase de codage, si on s'aper�oit qu'il manque de pr�cision ou que tel et tel concept n'est pas assez �volu�, mais dans ce cas l�, il faut stopper la phase de codage et revenir sur la phase de conception pour corriger cela et ensuite repartir sur ton codage.

6- optimisation si besoin + dernier bug et warning

L'optimisation, si la conception est bien faite ne devrait �tre que tr�s l�g�re et devrait concerner peut-�tre des probl�mes de marges (temporelles, m�moire...).
C'est dans ce point-ci que tu dois faire des tests fonctionnels et unitaires. Les cas de test doivent d'ailleurs �tre r�dig� en principe avant le codage.
Si ce n'est la cas, ils ne doivent en aucun cas �tre r�dig� � partir du code. S'il y a un �cart entre ta concpetion et ton code tu ne le verras pas si tu �tablis tes cas de test � partir du code.


Il n'est pas toujour �vident d'avoir une d�marche qualitative dans le d�veloppement logiciel car cela implique des sacrifices au d�part. Celui de passer par une phase de conception non n�gligeable.
Si cette phase est n�glig�e, la maitrise du d�veloppement ne peut pas �tre garantie...donc le planning peut conna�tre des d�rives tout autant non ma�tris�s...

Il est bon de ta part d'avoir pos� cette question.

Bon courage.

[Mat007]

Cette phase [de conception] est primordiale, il faut y passer du temps.
(...)
On ne fait pas de codage en m�me temps que de la conception...
(...)
Erreur, on ne corrige pas une conception apr�s avoir cod�.
(...)
C� veut dire aussi que tu n'es pas capable de dire arriv� � ta phase de codage que ta phase de conception est termin�e, tu ne peux pas pr�voir en terme de planning si ton projet d�rape ou non.
(...)
Il n'est pas toujours �vident d'avoir une d�marche qualitative dans le d�veloppement logiciel car cela implique des sacrifices au d�part. Celui de passer par une phase de conception non n�gligeable.
Si cette phase est n�glig�e, la maitrise du d�veloppement ne peut pas �tre garantie...donc le planning peut conna�tre des d�rives tout autant non ma�tris�s...

Je ne suis compl�tement pas d'accord.
C'�tait ce qu'on faisait il y a 10 ans parce qu'on ne savait pas faire autrement et qu'on pensait que blinder la conception en amont �tait la seule solution pour s'en sortir.
�a ne veut pas dire qu'il faut tout faire � l'arrache mais des moyens diff�rents, plus l�gers, plus souples, plus agr�ables et au final plus efficaces existent, cf. toutes les m�thodes agiles.

En ayant pratiqu� pendant plusieurs ann�es ces deux approches pour moi il n'y a vraiment pas photo : les m�thodes agiles font mieux � tous les niveaux que la cascade (ou le cycle en V ou le cycle en W ou etc...).

Apr�s chacun ses pr�f�rences, j'imagine...

MAT.

[yan]

cf. toutes les m�thodes agiles.

Je viens de regarder un peu (wikipedia). Tu utilise plut�t laquelle?

[Noxen]

Puisque vous parliez de tests unitaires, � quels points vous �tes exhaustifs avec ces tests ? Vous testez chaque ligne de code ou seulement les points critiques ? Vous ne testez que d'apr�s l'interface des modules ou vous testez aussi les m�thodes et variables internes ? Est-il prudent/utile d'utiliser des classes de test amies des classes � d�velopper ? Quel framework de test utilisez-vous ?

[Mat007]

Puisque vous parliez de tests unitaires, � quels points vous �tes exhaustifs avec ces tests ? Vous testez chaque ligne de code ou seulement les points critiques ? Vous ne testez que d'apr�s l'interface des modules ou vous testez aussi les m�thodes et variables internes ? Est-il prudent/utile d'utiliser des classes de test amies des classes � d�velopper ? Quel framework de test utilisez-vous ?

En g�n�ral on distingue deux types de tests :
. les tests client (ou tests d'int�gration) qui doivent tester l'ensemble d'un produit/biblioth�que/etc.. sachant qu'une partie peut �tre manuelle mais que c'est un peu fastidieux
. les tests d�veloppeur (ou tests unitaires) qui testent les modules � l'int�rieur et qu'il faut vraiment automatiser

Jusqu'� assez r�cemment je pensais que module = classe mais plus �a va et plus je m'aper�ois que je suis plus � l'aide avec module = petit ensemble de classes manipul�es � travers une fa�ade. Mais bon � la limite c'est accessoire.

Concernant les tests unitaires j'utilise Boost.Test associ� � Mockpp (ce dernier me semblant incontournable assez rapidement pour des tests un peu s�rieux) et je teste les modules uniquement de l'ext�rieur (black box) en consid�rant que l'int�rieur est un d�tail d'impl�mentation qui ne regarde que le module tant que celui-ci remplit correctement son contrat.

MAT.

[exterieur]

Je ne suis compl�tement pas d'accord.
C'�tait ce qu'on faisait il y a 10 ans parce qu'on ne savait pas faire autrement et qu'on pensait que blinder la conception en amont �tait la seule solution pour s'en sortir.
�a ne veut pas dire qu'il faut tout faire � l'arrache mais des moyens diff�rents, plus l�gers, plus souples, plus agr�ables et au final plus efficaces existent, cf. toutes les m�thodes agiles.

En ayant pratiqu� pendant plusieurs ann�es ces deux approches pour moi il n'y a vraiment pas photo : les m�thodes agiles font mieux � tous les niveaux que la cascade (ou le cycle en V ou le cycle en W ou etc...).

Apr�s chacun ses pr�f�rences, j'imagine...

MAT.

Oui et non, agiles vise � diviser les phases de conception et de codage temporellement.
Effectivement, on ne fait plus comme il y'a 10ans une conception globale de l'appli puis codage complet...
Mais l'id�e est la m�me dans chaque �tape, on concoit puis on code puis on teste et ainsi de suite ...
Dans l'id�e, si je divise temporelle 2 �tapes :
Je con�ois la 1, je doe la une, je la teste.
Puis m�me process pour la 2.
Mais si ma conception de la 1 est mauvaise et que la 2 d�pend de la 1, cela veut dire que la 2 peut ne pas marcher � cause de la 1 et qu'il faut reconcevoir la 1, la retester, puis retester la 2...du tmeps de perdu en sommes.
Certes moins de temps de perdu que si on a con�u toute l'appli et qu'on s'aper�oit en codant ou en testant que la conception est mauvaise...

La phase de conception (dans chaque �tape) n'est pas n�gligeable...malgr� tout.

Bon, j'ai fait de gros racourcis...certes, mais l'id�e est l�.

[yan]

Remarque interessante. Merci

Erreur, on ne corrige pas une conception apr�s avoir cod�.
[...]

Cette �tape se situe dans le d�veloppement.

C� veut dire aussi que tu n'es pas capable de dire arriv� � ta phase de codage que ta phase de conception est termin�e, tu ne peux pas pr�voir en terme de planning si ton projet d�rape ou non.

Je pense que si. Il faut juste pr�voir qu'elle parti risque d'�tre modifier. Ce n'est pas une refonte totale bien sur.

Personnellement, je ne crois qu'il est possible de tout concevoir avant de d�velopper... Il y as toujours des risques important qui peuvent apparaitre en cours de dev... Par exemple, un calcul qui n'est tout compte fait pas adapt�=> chang� de model => refonte d'une partie du code

[HanLee]

Je ne fais pas encore de tests unitaires automatis�s, mais je teste bien s�r.

-------

Des fois, c'est parfois super compliqu� d'�crire une batterie de tests pertinente, parce qu'il peut y avoir des cas de figure tr�s diff�rents.

Dans ces cas-l�, j'aime bien compl�ter �a par des sp�cifications et d�montrer � la main que le module marche.
Ca me fait gagner �norm�ment de temps, sous r�serve que les fonctions soient bien �crites, dans un style simple, s�r et idiomatiques (utilisation intensive de la STL et boost �ventuellement, afin de garantir des comportements).

Je d�tecte en g�n�ral facilement les fonctions par lesquelles les risques de dysfonctionnement peuvent venir.