methode de programmation

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 :aie:, je voulais avoir vos avis et comment vous faites.

merci
yan

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

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.

Citation:

---

Envoyé par 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.

---

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

Citation:

---

Envoyé par 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.

---

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

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

Citation:

---

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.

Citation:

---

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

Citation:

---

3- si il faut, correction de la conception

---

Cela fait partie de la phase 1 aussi.

Citation:

---

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.

Citation:

---

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.

Citation:

---

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.

Citation:

---

Envoyé par exterieur

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. 8-)
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.

Citation:

---

Envoyé par Mat007

cf. toutes les méthodes agiles.

---

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

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 ?

Remarque interessante. Merci

Citation:

---

Envoyé par exterieur

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

---

Cette étape se situe dans le développement.

Citation:

---

Envoyé par exterieur

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

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.

Citation:

---

Envoyé par Mat007

Je ne suis complètement pas d'accord. 8-)
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à.

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.

Citation:

---

Envoyé par Emmanuel Deloget

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

Citation:

---

Envoyé par Mongaulois

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.

Citation:

---

Envoyé par Emmanuel Deloget

@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)

Citation:

---

Envoyé par Emmanuel Deloget

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... ;)

Citation:

---

Envoyé par exterieur

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.

Citation:

---

Envoyé par exterieur

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.

Citation:

---

Envoyé par 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 ?

---

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.

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.

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

Par contre, la prémisse:

Citation:

---

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

Citation:

---

Envoyé par wiztricks

(...) 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.

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

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 8-) ).

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

Citation:

---

Tu trouves que les tâches sont trop petites ?

---

Pour moi, la durée signifie "contrôle" d'avancement à la fin. Au moins j'ai confiance au plus je tends à rapprocher les "contrôles" :(

Par contre:

Citation:

---

le travail de découpage des fonctionnalités en tâches unitaires

---

Ca c'est du boulot de conception (design) qui demande a avoir été fait un minimum correctement (ou un maximum suivant la méthodologie) pour éviter un tas de "rework" au fur et à mesure que le code est produit.

Ce qui est bluffant dans les méthodes agiles est qu'on peut faire l'impasse là dessus et designer l'application au fur et à mesure qu'on écrit le code.
Je ne suis pas contre et cela est parfois utile et bénéfique, sauf que tous les projets ne peuvent pas être conduits comme çà.
- W

Ça vous est arrivé qu'un test soit basé sur un certain design du programme, que le design nécessite d'être remanié, et que cela invalide les modules de tests, obligeant à les réécrire ? Que faites-vous dans ce cas ?

Citation:

---

Envoyé par wiztricks

Pour moi, la durée signifie "contrôle" d'avancement à la fin. Au moins j'ai confiance au plus je tends à rapprocher les "contrôles"

---

Qu'est-ce que tu entends exactement par contrôle ?
S'assurer que le développement va rentrer dans les délais avec les fonctionnalités promises ?
En pratique on a une roadmap générale avec la liste des fonctionnalités de très gros grain (une sorte de traduction en use cases des spécifications grosso modo), et on utilise la progression sur les itérations passées pour estimer celle à venir.
Bien sûr c'est une estimation, donc on se trompe, le but est surtout d'estimer souvent pour pouvoir détecter le plus tôt possible qu'on ne va pas tenir les délais et qu'on va devoir sacrifier des fonctionnalités (ou négocier un délai, etc..).

Citation:

---

Envoyé par wiztricks

Ca c'est du boulot de conception (design) qui demande a avoir été fait un minimum correctement (ou un maximum suivant la méthodologie) pour éviter un tas de "rework" au fur et à mesure que le code est produit.

---

La définition des tâches est avant tout un travail fonctionnel, en pratique le client (ou le responsable fonctionnel) et le développeur se réunissent et découpent en petit morceaux les fonctionnalités gros grain jugées les plus urgentes à mettre en place. Le développeur estime combien de temps chaque tâche nécessite (plus les tâches sont précises et petites et moins on risque de se tromper de beaucoup) et le client les trie par ordre de priorité.
Cette étape permet aussi de lever la majorité des flous restants dans le cahier des charges et de s'assurer que tout le monde a la même vision du travail à réaliser.

Citation:

---

Envoyé par wiztricks

Ce qui est bluffant dans les méthodes agiles est qu'on peut faire l'impasse là dessus et designer l'application au fur et à mesure qu'on écrit le code.
Je ne suis pas contre et cela est parfois utile et bénéfique, sauf que tous les projets ne peuvent pas être conduits comme çà.

---

Oui c'est vrai, mais je dirais que ce n'est pas forcément pour les raisons auxquelles on pense en premier.
Je trouve que ce qui rend possible ce genre d'approche tient surtout au rôle du client. Si le client final ne joue pas le jeu, qu'il tient absolument à fournir un cahier des charges au début et ne plus entendre parler du projet jusqu'à la recette, ça limite un peu.

Mais on n'est pas non plus obligés de partir complètement à l'aveuglette sans aucunes spécifications ou cahier des charges...
Dans le domaine dans lequel je travaille actuellement (simulation militaire et serious games) en général du point de vue du client final on a un fonctionnement waterfall classique avec appels d'offre et tout le foin.
Ensuite en interne on a quelqu'un qui joue un rôle fonctionnel pour prendre les décisions et faire l'interface avec le client.

MAT.

Citation:

---

Envoyé par Noxen

Ça vous est arrivé qu'un test soit basé sur un certain design du programme, que le design nécessite d'être remanié, et que cela invalide les modules de tests, obligeant à les réécrire ? Que faites-vous dans ce cas ?

---

Il y a plusieurs type de tests et donc plusieurs types de dégats à considérer.

Si ca casse les tests fonctionnels, çà remet peut être aussi en cause le contrat passé avec le client... et là, je suis très embêté ;-(

Concernant les tests unitaires, il y a au moins deux niveaux.

Les tests d'intégration: ils testent les interfaces présentée aux autres composants... S'il les faut changer, la casse sera limitée à certains développements. L'impact peut être un retard sur la livraison...

Les tests unitaires: ceux là testent l'implémentation et... si l'implémentation change, il va certainement falloir en ré-écrire un certain nombre.

Une des différences entre intégration et unitaire est que l'intégration valide que l'interface fonctionne sans aller dans les conditions aux limites. Si on a besoin de parallèliser les dévelopements, on peut dans un premier temps se contenter de mockups.

Les tests unitaires vont eux tester:
- les conditions aux limites,
- couvrir l'ensemble du code.

Ceci dit, il faut que le projet ait une certaine complexité pour qu'une telle architecture de tests (fonctionnel, intégration, unitaire) soit utile.

- W

moi je ne jure que par ca et mes boss en sont tres content :

the good way

Citation:

---

Envoyé par Noxen

Ça vous est arrivé qu'un test soit basé sur un certain design du programme, que le design nécessite d'être remanié, et que cela invalide les modules de tests, obligeant à les réécrire ? Que faites-vous dans ce cas ?

---

Pour moi les tests unitaires font partie intégrante du code et vont donc évoluer avec. En général quand je remanie j'essaye de procéder par petites étapes en commençant par modifier les tests pour prendre en compte le changement et en corrigeant le code au fur et à mesure pour faire passer les nouveaux tests.
En fait les tests sont quelque part une expression du design dans la mesure où ils révèlent la manière dont sont manipulés les composants (d'ailleurs les tests peuvent aussi être considérés comme la documentation des composants) et pour changer le design je vais m'efforcer de commencer par exprimer le changement de design par les changements à apporter dans les tests.

Par contre si le changement est conséquent et radical, je fais un essai un peu à l'arrache de remaniement brutal du code utile sans toucher aux tests, juste pour voir comment ça fait, et si je suis satisfait je revert tout et je recommence en procédant par étapes.

MAT.

Citation:

---

Envoyé par Noxen

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 8-) ).

---

Mon préféré reste CxxTest qui se débrouille tout seul comme un grand pour faire le lien entre une fonction de test et les tests à déclarer au "framework". Les dernières versions de FRUCTOSE semblent suivre la même approche -- script perl qui s'occupe de l'introspection.
Et je n'ai pas encore testé le framework de google.

Des comparatifs peuvent être trouvé sur l'ancien blog de Noel Llopis, et dans quelques numéros du magasine Overload (en ligne sur le site d'ACCU).

Je code avec des restrictions très fortes, via des invariants garantis de préférence par le typage, limitant ainsi fortement la nécessité de tout tester.

Citation:

---

Envoyé par loufoque

Je code avec des restrictions très fortes, via des invariants garantis de préférence par le typage, limitant ainsi fortement la nécessité de tout tester.

---

Cela semble intéressant mais j'ai quelques difficultés à me représenter cela.
Vous pourriez donner un exemple simple?
- W

Je n'utilise que des objets qui ne peuvent jamais être vide ou dans un état invalide et ceci avec une sémantique valeur.

Citation:

---

Envoyé par loufoque

Je n'utilise que des objets qui ne peuvent jamais être vide ou dans un état invalide et ceci avec une sémantique valeur.

---

Salut, tu aurais un exemples ou un lien de ce que tu parle???
J'ai dû mal à comprendre... :cry:

Je poursuis la remarque de loufoque:

Citation:

---

Envoyé par loufoque

Je n'utilise que des objets qui ne peuvent jamais être vide ou dans un état invalide et ceci avec une sémantique valeur.

---

Ce qui, en C++, signifie:
* code résistant aux exceptions
* RAII
* type safety (ce qui permet une récupération d'une bonne partie des erreurs logique au moment de la compilation)
* utilisation de la librairie standard

Et autres techniques dont le but est de maximiser la validité du code. Le Saint Graal étant d'arriver à un code qui ne peut compiler que si il est correct (ce qui n'est pas prêt d'être le cas, mais en s'arrangeant bien, on peut déja obtenir des choses sympas en C++).

Citation:

---

Envoyé par Emmanuel Deloget

Je poursuis la remarque de loufoque:

Ce qui, en C++, signifie:
* code résistant aux exceptions
* RAII
* type safety (ce qui permet une récupération d'une bonne partie des erreurs logique au moment de la compilation)
* utilisation de la librairie standard

Et autres techniques dont le but est de maximiser la validité du code. Le Saint Graal étant d'arriver à un code qui ne peut compiler que si il est correct (ce qui n'est pas prêt d'être le cas, mais en s'arrangeant bien, on peut déja obtenir des choses sympas en C++).

---

Ce sont de bons principes de programmation: ils permettent de prévenir des aberrations dans les cas "limite" souvent difficiles à provoquer via des tests.

Je ne pense pas qu'on puisse s'assurer que ces principes aient été respectés sans faire une revue du code.
Et malheureusement coder proprement ne signifie pas toujours que çà fera "papa, maman" comme on l'attend :cry:

- W

Citation:

---

Envoyé par wiztricks

Ce sont de bons principes de programmation: ils permettent de prévenir des aberrations dans les cas "limite" souvent difficiles à provoquer via des tests.

Je ne pense pas qu'on puisse s'assurer que ces principes aient été respectés sans faire une revue du code.
Et malheureusement coder proprement ne signifie pas toujours que çà fera "papa, maman" comme on l'attend :cry:

- W

---

Non, franchement, respecter ces principes est très simple en C++, et ça se contamine très facilement à tout code qui vient se baser sur ça.

Une classe dont tous les membres respectent le RAII respecte RAII, résiste aux exceptions.
Et pour que tous ses membres respectent le RAII, s'aider de la librairie standard si besoin.

----

Bon et sinon, j'suis déçu, personne n'essaie un minimum de garantir les invariants de la classe, en spécifiant à la main et en faisant quelles implications logiques ?

Pour des objets dont l'implémentation est compliquée bien, pas pour un p'tit Timer à la con.

Un pointeur, par exemple, ça peut être nul.
Un pointeur de fonciton, ça peut être nul.
Un Boost.Any, ça peut être nul.
Un Boost.Function, ça peut être nul.

Un objet dans un état nul invoque soit un comportement indéfini, soit une erreur, soit une exception.
Des choses que je tiens à éviter entièrement par conception.

En fait je fais de même, je les evite.

Sauf quand j'en ai besoin :)
Quand la logique du programme implique une absence d'objet référé, c'est naturel d'utiliser un pointeur. Comme c'est dans la logique du programme, ça doit être géré. Et par là même, l'etat nul n'est jamais une erreur, si il est permis.

Enfin dans l'idéal du moins.

Dans le cas d'un objet optionnel, j'utilise un wrapper de type boost::optional<T> ou de type boost::variant<T, null_type>.

Tout comme Some of 'a | None en ML ou le Maybe monad en Haskell.

C'est tout de même souvent une erreur de conception que de devoir travailler avec des objets qui peuvent être nuls.

Citation:

---

Envoyé par loufoque

Dans le cas d'un objet optionnel, j'utilise un wrapper de type boost::optional<T> ou de type boost::variant<T, null_type>.

Tout comme Some of 'a | None en ML ou le Maybe monad en Haskell.

C'est tout de même souvent une erreur de conception que de devoir travailler avec des objets qui peuvent être nuls.

---

boost::optional<T>, j'aime pas trop, la valeur est ajoutée est pas énorme, dans le sens où le typage ne te force pas à vérifier si l'objet est nul ou non.

Alors qu'à l'inverse boost::variant<T, null_type> ou le type Option de ML t'oblige à vérifier si l'objet est valide.

Citation:

---

C'est tout de même souvent une erreur de conception que de devoir travailler avec des objets qui peuvent être nuls.

---

Je ne vois pas en quoi?

Le cas le plus courant sur le quel je tombe est simplement quand on a besoin de savoir quel objet on a a un moment, ou si on a pas d'objet.
Par exemple une icone selectionnée ou aucune selectionnées, sont des etats valides dans beaucoup d'application (je pense principalement aux jeux vidéos là ou c'est très courant).
De même dans les bases de données il est souvent utile d'indiquer que l'information est manquante par une valeur nulle (qui est différente d'un texte vide par exemple).

A mon humble avis, remplacer systématiquement ce genre de logique par un objet est souvent overkill comme on dit, même si il ya des cas où c'est pertinent, ça ne semble pas l'etre pour tous les cas. D'ailleurs, ça n'aide pas forcément à la compréhension en travail d'équipe (quand toute l'équipe ne connais pas boost et n'a pas le temps de s'y mettre par exemple). Autant se servir des mécanismes de base du language.

Le cas des champs nuls dans une base de données est un cas courant, oui.
Après l'histoire des icônes j'ai pas compris. Un objet icône, une fonction is_checked et voilà...