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