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 ?

[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

[Emmanuel Deloget]

Il n'y a pas besoin de donner un nom à une méthode agile pour pouvoir l'utiliser.

-- [note: c'est une séparation, parce que je change de sujet]

Personnellement, j'implémente RUP avec des cycles itératifs extrèmement courts (1 à 2 jours).

En gros, le développement devient:

A) inception -- celle là, je peux pas y couper: il faut quand même définir les objectifs, non ?

B) élaboration -- dans un moindre mesure: on s'autorise le développement des use case, mais on en reste plus ou moins là. Le but est, comme précédemment, de savoir ou on va, pas comment on va le faire. Par contre, la phase d'architecture est passée à la trappe - elle est intégrée dans la phase de réalisation. Cela permet la plupart du temps de ne faire qu'une seule itération dans la phase d'élaboration, puisque le besoin d'affinage du modèle est moins fort.

C) réalisation -- on peut découper cette phase en autant d'itérations que souhaité. Mes itérations ressemblent à conception/developpement/test, ou la phase de conception peut se doubler d'une phase de refactoring si besoin. Normallement, je devrais faire conception/test/developpement, mais je suis trop fainéant.

D) la phase de maintenance est généralement moins problématique (sur les 3 projets dont je me suis occupé ces derniers mois, seul 1 projet nous est revenu avec 1 bug, donc on peut dire que cette phase est assez calme pour l'instant).

@Mat007; je ne suis trop pas d'accord avec toi: si les entreprises continuent à essayer de concevoir les systèmes complètement avant de les produire, ce n'est pas parce qu'elles ne veulent pas se mettre aux méthodes agiles, mais parce qu'il y a véritablement un besoin de contrôle de ce qui va être fait. Une fois complètement défini, un projet devient maitrisable, et les difficultés techniques sont connues. C'est la condition sine qua none pour le succès: quelqu'un, quelquepart, DOIT avoir une idée précise de l'artefact qui sera généré, sans quoi personne ne sait quoi faire et le projet s'enlisera un jour ou l'autre - que la méthode utilisée soit "agile" ou non.

Je dois avouer que je n'ai pas encore trouver une quelconque méthode agile satisfaisante. Je me pose encore trop de questions sur elles. Premièrement, qu'est-ce qui différencie une méthode agile d'une méthode non agile? Quel projet peut être géré avec une méthode agile ? Quel projet ne peut pas l'être ? Pourquoi ? Est-ce une limite de la méthode ? Quels sont les points importants qui définissent une méthode agile ? En quoi ces points sont importants ? etc.

[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à.

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

[exterieur]

@Mat007; je ne suis trop pas d'accord avec toi: si les entreprises continuent à essayer de concevoir les systèmes complètement avant de les produire, ce n'est pas parce qu'elles ne veulent pas se mettre aux méthodes agiles, mais parce qu'il y a véritablement un besoin de contrôle de ce qui va être fait. Une fois complètement défini, un projet devient maitrisable, et les difficultés techniques sont connues. C'est la condition sine qua none pour le succès: quelqu'un, quelquepart, DOIT avoir une idée précise de l'artefact qui sera généré, sans quoi personne ne sait quoi faire et le projet s'enlisera un jour ou l'autre - que la méthode utilisée soit "agile" ou non.

Je dois avouer que je n'ai pas encore trouver une quelconque méthode agile satisfaisante. Je me pose encore trop de questions sur elles. Premièrement, qu'est-ce qui différencie une méthode agile d'une méthode non agile? Quel projet peut être géré avec une méthode agile ? Quel projet ne peut pas l'être ? Pourquoi ? Est-ce une limite de la méthode ? Quels sont les points importants qui définissent une méthode agile ? En quoi ces points sont importants ? etc.

Tout à fait d'accord, la méthode dépend de l'environnent, du domaine d'application. En embarqué (Aéronautique, férroviaire, automobile) les méthodes sont plutôt celles des conceptions complètes avant codage... mais dans d'autre domaines... on applique plutôt du type agiles...

[Mat007]

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

A titre personnel, au niveau développeur, je pioche essentiellement dans XP. Je dis pioche parce que le sommet de ma hiérarchie est complètement réfractaire à certaines pratiques (le binômage notamment).
D'ailleurs si la majorité des méthodes dites agiles s'intéresse surtout à la gestion de projet (Scrum a le vent en poupe en ce moment), la partie développement pratique est surtout couverte par XP.

@Mat007; je ne suis trop pas d'accord avec toi: si les entreprises continuent à essayer de concevoir les systèmes complètement avant de les produire, ce n'est pas parce qu'elles ne veulent pas se mettre aux méthodes agiles, mais parce qu'il y a véritablement un besoin de contrôle de ce qui va être fait. Une fois complètement défini, un projet devient maitrisable, et les difficultés techniques sont connues. C'est la condition sine qua none pour le succès: quelqu'un, quelquepart, DOIT avoir une idée précise de l'artefact qui sera généré, sans quoi personne ne sait quoi faire et le projet s'enlisera un jour ou l'autre - que la méthode utilisée soit "agile" ou non.

Un des principes des méthodes agiles est de reconnaître qu'on ne peut tout fixer et connaître dès le départ, et que essayer de le faire est du temps perdu. Elles visent plutôt à mettre en avant des moyens de détection de problèmes et de contrôle progressif qui permettent de réagir rapidement et efficacement.

De plus le but d'un développement logiciel est-t-il de réaliser scrupuleusement ce qui a été défini x mois auparavant ? Ultimement c'est quand même de réaliser ce qui sert au mieux les intérêts du client (au sens large), donc si ce client change d'avis, a une idée lumineuse ou s'aperçoit en manipulant le produit qu'il a oublié plein de choses, il faut prendre en compte tout ça.

(je connais mal RUP, c'est pas spécialement dirigé vers toi)

Je dois avouer que je n'ai pas encore trouver une quelconque méthode agile satisfaisante. Je me pose encore trop de questions sur elles. Premièrement, qu'est-ce qui différencie une méthode agile d'une méthode non agile? Quel projet peut être géré avec une méthode agile ? Quel projet ne peut pas l'être ? Pourquoi ? Est-ce une limite de la méthode ? Quels sont les points importants qui définissent une méthode agile ? En quoi ces points sont importants ? etc.

Pour moi une méthode traditionnelle c'est un peu comme un canon et une méthode agile c'est un plus missile téléguidé : avec le canon on fait plein de calculs compliqués de trajectoires pour finir par tirer sans plus aucun contrôle sur la suite, avec un missile on s'en fout des calculs il suffit de le tirer et d'ajuster la trajectoire au fur et à mesure.

Bien sûr, comme toute bonne analogie, elle est fausse...

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 ...
(...)
La phase de conception (dans chaque étape) n'est pas négligeable...malgré tout.

Bien sûr qu'il y a de la conception, c'est juste qu'elle se fait tout le temps : conception et codage sont mélangés. Le fait d'écrire des tests unitaires (en TDD, donc avant le code 'utile') a vraiment cet effet magique de résoudre facilement et simplement les problèmes (associés à d'autres pratiques : suppression des duplications, remaniement agressif, KISS, YAGNI, etc..).

Il y a également une 'conception' de très haut niveau du système global mais en général ça peut se résumer à une douzaine de patates sur un tableau blanc.

En embarqué (Aéronautique, férroviaire, automobile) les méthodes sont plutôt celles des conceptions complètes avant codage...

A mon sens c'est un autre problème puisque dans ces domaines sont appliquées des méthodes de preuve de programme (ou en tous cas ça devrait...).

MAT.

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

[Mat007]

Pour revenir un peu dans le sujet initial voilà en gros à quoi ressemble ma manière de développer, en considérant que le travail de découpage des fonctionnalités en tâches unitaires (réalisables en quelques heures, un jour grand maximum) a été réalisé :

1. je prend la tâche suivante dans la liste des tâches (donc la plus urgente à traiter)
2. je repère les tests unitaires éventuellement existants qui portent sur le même module
3. je rajoute un test unitaire qui traduit la tâche en code, en ajoutant le strict minimum pour que ça compile (classes et méthodes vides par ex) avec le test qui échoue
4. j'implémente la première solution qui me vienne à l'esprit (mais pas la plus stupide non plus, un tant soit peu élégante tout de même) pour faire passer le test
5. je remanie (suppression de duplication, factorisations, etc...)
6. je vérifie que tous les autres tests déjà existants passent toujours
7. je commit

C'est le cas idéal, mais si par exemple au cours de 3 ou de 4 je m'aperçois que ce n'est pas si simple et qu'il va falloir que je remanie pour pouvoir insérer ma nouvelle fonctionnalité, je revert tout, je remanie et je commit avant de recommencer.
De la même manière si après 4 mon test échoue toujours, je revert tout ce que j'ai fait pendant 4 sans perdre 1h à essayer de déboguer, et je recommence.
Si en 7 j'ai fait une boulette (j'ai oublié de commit un fichier, j'ai commit trop sûr de moi sans relancer tous les tests et certains ne passent plus, j'ai implémenté une solution non portable, etc...) je vais recevoir un mail du serveur de build qui lors de chaque commit recompile et relance tous les tests (sur 4 plates-formes différentes).
Ensuite je recommence 3->7 tant que je considère que la tâche n'est pas complètement réalisée, sachant que la validation finale pour savoir si j'ai bien réalisé ce qu'on voulait n'est pas faite par moi mais par le client.

Je fais ça aussi pour mes projets personnels sur lesquels je suis tout seul d'ailleurs...

Au final c'est, je trouve, vraiment très agréable à pratiquer, ça donne un rythme entraînant, une assurance dans tout ce qu'on fait, on ne débogue presque jamais, etc...

MAT.

[wiztricks]

@MAT
Pour ce qui est du codage, çà me va bien.

Par contre, la prémisse:

Pour revenir un peu dans le sujet initial voilà en gros à quoi ressemble ma manière de développer, en considérant que le travail de découpage des fonctionnalités en tâches unitaires (réalisables en quelques heures, un jour grand maximum) a été réalisé

peut faire débat quant au niveau de détail à atteindre pour prétendre pouvoir commencer à coder sérieusement.

Je ne pense pas qu'une méthode soit meilleure qu'une autre : elle doit être adaptée au type de projet à réaliser.
- W

[Mat007]

(...) la prémisse (...) peut faire débat quant au niveau de détail à atteindre pour prétendre pouvoir commencer à coder sérieusement.

Tu trouves que les tâches sont trop petites ?
C'était pour donner un ordre de grandeur, en pratique ça atteint régulièrement 2 ou 3j chez nous... Mais on s'est aperçu que les trop grosses tâches (au-delà d'un jour ou par là) n'étaient souvent pas décrites assez précisément et que ça conduisait soit à avoir le développeur qui a besoin de demander des précisions (à la limite pas très grave) soit le développeur qui comprend de travers ou invente les précisions manquantes (plus grave, du coup ça empêche la validation de la tâche et ça mène à des corrections pour l'itération suivante et ça fait perdre du temps à tout le monde).

MAT.

[Noxen]

Merci Mat007 (et désolé d'avoir squaté le post de Mongaulois ).

En fait je fais des recherches sur les tests unitaires (et incidemment sur les TDD) depuis un mois environ, et j'ai encore un peu de mal à les concevoir. J'ai commencé avec TUT, qui me paraissait léger. Je pense que je vais bientôt tester cppUnit lite (et je crois qu'il faudra vraiment que je découvre boost ).

Pour l'instant, je n'ai travaillé que sur de petits projets maisons, ou de cours, qui n'étaient pas tellement propices à l'exploration des TDD, on travaille souvent un peu à l'arrache. Du coup, changer d'habitudes et passer à une méthodologie basée sur les tests demande un certain effort intellectuel et un certain temps d'adaptation ; mais je commence à voir que ça impose un certain nombre de contraintes sur le développement (enfin, ceci-dit, ce n'est pas forcément un mal).