methode de programmation

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