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.