Aussi etonnant que ca puisse paraitre, Linuxfr publie un article tres interessant sur la necessite de tester les logiciels libre et de faire de la doc (user et dev).
En gros, ca casse du sucre sur le LL dans son ensemble.
Pourquoi? Parce que si les gros projets libre connu (Noyau, kde, gnome, mozilla) sont assez bien teste, ce n’est pas forcement le cas de tous les LLs.
De mon point de vue, les arguments sont pertinants, on peut en discuter mais en essayant que ca parte pas en troll/godwin.
+1 pour cet article …
a mon avis c’est aussi une question d’age du logiciel libre et de son "enfermement"
parce que le nombre de fois ou j’ai demandé de l’aide pour certains trucs et que je me suis pris un man blahblah et des rires derriere ca aide vraiment pas à vouloir passer au libre …
pour que le libre soit bien diffusé et s’integre de plus en plus dans la vie de tous les jours il faut de la bonne doc bien faite claire comprehensible user friendly et des tests
le truc c’est que c’est chiant a faire et que comme pour le libre personne n’est payé rare sont ceux qui veulent se taper les corvés …
n’empeche ensuite les gens achetent des o’reilly et comprennent les softs …
le jour ou y’aura de la doc claire o’reilly fera faillite …
je suis sur que c’est o’reilly qui pousse les gens du libre à faire de la doc abscon …
Intéressant et réaliste pour ce qui est du type de code que l’on peut trouver sur des LL. En revanche, la phrase « XP recommande même d’écrire les tests avant le code à tester » montre une inexpérience du monde industriel. C’est évidemment une pratique obligatoire dès lors que l’on veut faire du dev/test en parallèle et non pas un extrêmisme comme le sous entend l’article.
Pour ma part je teste souvent, de façon unitaire, au debugger afin de parcourir les structures de données aux limites (limite inférieure et supérieure). Je code en contrôlant quasi systématiquement l’ensemble des paramètres à l’entrée d’une méthode ce qui aide fondamentalement à la mise au point. Idem pour les tests d’intégration (lorsqu’on vient intégrer notre lib/code/module/process à un autre bout), je fais l’analyse des bornes du nouveau sous-système pour taper aux bornes de celui-ci.
Chaque entitée doit être autonome et ne jamais faire une faute. Si on lui passe de mauvaises infos, il faut quelle soit en mesure d’identifier ce context et donc de ne pas faire nawak. C’est le principe général que j’utilise et de fait, ça marche plutôt bien.
Heu non, je connais personne dans l’industrie a part des toutes petites boites avec des gens super talentueux et qui ont une experience d’ingenieur QA ou des petits groupes chez nous a la pointe de ce que nous on appalle l’EE (Engineering Excellence) qui experimentent avec test driven development. La technique elle meme est plutot recente (quelques annees au plus). La plupart des ingenieurs ne fonctionnent absolument pas de cette maniere.
Il y a une difference entre tester son code au fur et a mesure qu’on l’ecrit,et faire de l’XP de la maniere mentionnee. Le premier ce sont les unit test et c’est effectivement une evidence, on le fait en debuggant, en faisant tourner sur sa machine, en essayant de rentrer de la daube ou des donnes extremes pour s’assurer que chaque composant, blabla, tous dev digne de ce nom doit faire ce genre de trucs. Le second c’est ecrite des suites de tests, dans un framework de QA fait pour etre executees automatiquement et systematiquement a chaque changement. C’est prevoir de tester ton code sous 4 environements (98, XP, 200, 2003) et 3 architecture (x86, x64, IA64) par exemple et c’est surtout d’ecrire le code de test selon les specs, avant d’ecrire le code lui meme. Comme ca pas moyen de devier des specs au fur et a mesure que tu developpe sans adapter le framework de test. Il y a une difference entre unit test et test. C’est un facteur de complexite qui n’a rien a voir. Ingenieur QA c’est un metier, il fait pas juste ce que le developpeur a pas le temps de faire, c’est malheureusement bien plus complexe que ca.
C’est au contraire mal connaitre l’industrie que de dire que c’est le minimum obligatoire. La plupart des societes n’ont meme pas d’equipe de QA dediee ou de test attitree et s’imaginent que les dev feront suffisament bien le boulot et /ou de unit test pour que ca soit bon… Ou alors elles s’imaginent qu’il suffit d’assigner suffisament de ressources pendant la beta ou l’alpha pour debusquer tout les bugs. Alors parler d’XP ou des test driven devel, c’est a des annees lumieres de ce qu’elles envisagent.
Totalement en désaccord avec Glop mais c’est devenu une habitude ^^
Tous les développements d’ampleurs et « sérieux » que je connais sont réalisés en détachant le dev de l’équipe de tests. Je ne parle pas du geek qui cogne du code au fil de l’eau et qui réalise un petit utilitaire de TAG mp3, mais de véritables équipes de dev. Quand je dis « indus » c’est probablement mal formulé mais j’ai bossé pour des grosses boîtes dans des domaines « sérieux » et toutes fonctionnaient de la sortes. (Alcatel, FT, Lucent Technologies, Matra BAE, …).
D’ailleurs il me semble bien que le principe du dévelopement en V décrit déjà cette méthode.
Il ne faut pas croire que c’est une méthode que je préconise systématiquement et que je dénigre les devs qui ne suivent pas ce principe (au contraire), mais faire bosser des équipes de dev en considérant que les tests sont intégrés aux devs… huhuhu… BSOD is coming… On ne bosse pas forcément sur des PCs qu’on peut rebooter comme ça, peinard
Glop> Ne me dis pas que Windows est dev comme ça !? (remarque ça expliquerait des choses …) zouuu trolling is started
[quote name=‘Moktar’ date=’ 9 Feb 2005, 10:23’]des domaines “sérieux” et toutes fonctionnaient de la sortes. (Alcatel, FT, Lucent Technologies, Matra BAE, …).
[right][post=“330701”]<{POST_SNAPBACK}>[/post][/right][/quote]
tsst tsst. Tu voulais dire les domaines temps réels, sécurité embarquée etc… Mais les autres domaines ne sont pas pour autant “pas sérieux”.
C’est simplement que dans les autres domaines, l’apport d’une qualité extrême est trop couteuse par rapport aux avantages. Attention je n’ai pas dit qu’il ne fallait pas faire de la qualité: Les docs et les tests sont indispensables même dans le plus petit projet (même à 1 personne).
Bon on recommence J’explique un truc, tu comprend a cote sans vraiment lire ce qui est ecrit et tu pars sur ton idee de ce que tu crois avoir lu. Forcement a ce rythme la on est jamais d’accord. C’est d’ailleurs ce que tu as fais avec l’article de depart. Je connais bien le sujet, ca fait 6 mois que je suis plongé dedans pour suivre les etude de ce que l’on pourrait adapter de certaines methodes de XP a notre equipe, ou a notre division, ce qu’elle a apporte a qui, quand et comment sur combien de temps, dans des equipes de quelle taille, sur des projets de quelle envergure. En gros comment changer la maniere dont on travaille. C’est pas le premier rapport de plusieurs pages sur exactement le sujet que je me tape Sachant qu’on a deja une equipe de dev, une equipe de test et une equipe de PM, c’est pas ca qui est remi en cause DU TOUT, ca se joue sur des choses plus subtile qui sont le fond de l’article en question et qui sont neamoins fondamentales.
Je t’explique que t’as pas pige la difference entre ce que c’est que le test driven development qui fait parti de l’XP et ce qu’est le developpement standard et habituel d’application (en remettant meme en cause le fait que ca soit un « standard » voir plus loin). L’un n’a rien a voir avec l’autre et la difference est enorme, et non c’est loin d’etre une evidence ou quelque chose que tout le monde fait, ou meme que la majorite envisage.
Et un standard… c’est sans meme rentrer dans les milliers de boite qui ne font meme pas cela. Tu serais surpris du nombre de PME ou de SSII qui developpent 90% du code produit sur la planette qui ne travaillent pas en ayant une equipe de test dediee. Il y a beaucoup de monde qui code profesionnelement, le langage le plus utilise au monde est VB avec 6 millions de developpeurs, je serais surpris de savoir qu’ils ont tous une structure formelle d’equipe d’assurance qualitee pour aller avec…
Quand a windows… beaucoup des standards de developpement de projet logiciel a grande echelle (pense >500 developpeurs, y en a pas bcp au monde…) a ete en grande partie invente et rafinne par Microsoft. Windows compte plusieurs milliers de devs. Malgre des experiences ailleurs dans l’industrie (oui avec dev et test separe) auparavant j’ai decouvert un autre monde sur les gros projets MS. Le decoupage Dev/QA/PM en trois structure independante qui n’ont pas de rapport hierarchique l’un a l’autre est devenue une reference qui est etudiee academiquement et donc beaucoup de monde gagnerait a s’inspirer. Mon logiciel ayant 1000 developpeurs travaillant dessus, j’ai tres bien compri ce que tu disais quand tu parlais de « l’industrie ».
Je maintiens que apparement d’apres ta reaction, t’as carrement pas pige ce qu’etais l’XP et le test driven developement si tu t’imagine que c’est un standard et l’evidence dans l’industrie.
J’adore quand Moktar et Glop se tapent dessus pour dire la même chose… ce que Glop appelle Dev/QA, Moktar l’appelle Dev/Equipe d’intégration(tests)
Youpi, c’est la fête du slip.
C’est exactement la même chose hein… Chez Alcatel, dans les systèmes embarqués, on fait aussi des routines de tests (manuelles ou programmés), faites par une équipe à part, qui a des cahiers des charges, des specs, etc.
Bref, les équipes d’intégrations s’amusent, et font « ca marche pas LA, monsieur le dev »… parceque monsieur le dev’, si il fait ses tests tous seuls, ca part en cahouette, obligé, puisque quand on dev, on a la tête dans le guidon, on croit connaitre les pieges, et on test qu’on évite bien les pièges (sauf qu’on a pas vu un autre truc, forcement, et c’est pour cela que les equipes de tests, independantes et détachées, sans aucune connaissance supposée du code, lancent des tests completement au pif, eux)
Si faire les tests d’integration, c’est pas « faire de la qualité », je sais pas ce que c’est
Urdle: tout a fait, c’est exactement vrai ce que tu dis. C’est la qu’entre le test driven developmeent et les methode de devel XP. Ca evite, ca oblige, le dev a pas avoir la tete dans le guidon et a ecrire les tests avant le developement pour eviter cela justement. En faisant cela, le nombre de bugs finaux est en theorie grandement reduit et/ou leur gravite diminuee.
C’est en ca que c’est fondamentalement pas pareil que les methodes « traditionelles » avec une equipe de test separee qui teste l’integration a posteriori. Ca parait evident dit comme ca mais il faut voir que les methodes poru « pas avoir la tete dans le guidon » sont couteuse et c’est pas forcement trivial que ca va rapporter plus que ce que ca coute a la base. Dire a tes developpeurs « non, vous ecrivez pas la feature, vous ecrivez l’architecture de test d’abord et vous allez le faire en collaboration avec l’equipe de QA » au lieu du classique, « vous ecrivez du code, vous le testez de base, l’equipe de QA passe derriere avec ses outils et ses test pour verifier que tout va bien » c’est enorme comme changement. Je sais pas si la difference peut paraitre subtile vu de loin, mais c’est remettre en cause fondamentalement la maniere dont travaille tous les dev que je connais (a part comme je l’ai dit quelques rares equipes ou societes, en general petites, qui aiment experimenter avec des chose nouvelles que presque personne a fait avant elles). Parceque a priori, ca parait perdre du temps de faire ces choses la
Note en passant parceque c’est un sujet qui me tient a coeur:
Il se trouve qu’on est en plein dans ce qui fait (ou devrait faire, l’informatique est une jeune discipline) l’ingenierie informatique et l’ingenieur par rapport a la notion de « codeur », l’ingenierie c’est l’etude de la meilleure maniere de realiser quelque chose. Un tres bon ingenieur a meme pas besoin d’etre un tres bon codeur, mais de comprendre ce que font les codeurs et les methodes qui amenent les meilleurs resultats et pourquoi.
[quote name=‹ urdle › date=’ 9 Feb 2005, 10:51’]J’adore quand Moktar et Glop se tapent dessus pour dire la même chose…
[right][post=« 330709 »]<{POST_SNAPBACK}>[/post][/right][/quote]
J’espère qu’ils se comprennent mieux avec leurs collègues, ça les aidera pour bosser
[quote name=‹ phili_b › date=’ 9 Feb 2005, 10:35’]tsst tsst. Tu voulais dire les domaines temps réels, sécurité embarquée etc… Mais les autres domaines ne sont pas pour autant « pas sérieux ».
C’est simplement que dans les autres domaines, l’apport d’une qualité extrême est trop couteuse par rapport aux avantages. Attention je n’ai pas dit qu’il ne fallait pas faire de la qualité: Les docs et les tests sont indispensables même dans le plus petit projet (même à 1 personne).
[right][post=« 330704 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Oui oui, j’ai mis « sérieux » entre guillemets et pour aller vite. Désolé de faire un raccourci de la sorte. Ce que je veux dire, c’est qu’une application trucmuche sur un PC qui se gauffre de temps en temps « ce n’est pas trop grave » alors que lorsque c’est un équipement « inaccessible », ça l’est déjà plus
[quote name=‹ GloP › date=’ 9 Feb 2005, 10:42’]SSII qui developpent 90% du code produit sur la planette…
[right][post=« 330708 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Joli. J’ai mis un certain temps à décoder. C’est un terme d’eXtreme Programming ?
Sinon pour ajouter mon grain de sel : J’ai 6 ans d"expérience dans le dev dans des SSII et chez un éditeur de progiciel. Le problème que je vois très souvent dans tout ce qui est specs/docs/tests c’est les changements de dernière minute, c’est les clients.
On a tellement habitué les clients à être les rois, à tout exiger de l’informatique, qu’on se plie à tous leurs caprices. Le client exige tout, n’importe quoi et son contraire le lendemain, et une SSII en forfait ou un éditeur dépendant de deux ou trois très gros clients capricieux (et je parle même pas du service marketing) est obligée de suivre celà. J’ai vu des projets avec un nombre de documentation hallucinante mais qui n’était plus à jour, parce qu’au début du projet tout était beau dans le meilleur des mondes mais le projet est ensuite parti dans de multiple directions et la docs/spec/tests, même si elle était existante au début, n’a pas pu suivre faute de temps. C’est d’ailleurs pour la même raison (et aussi à cause de cette chiennasse d’entropie) que le code d’un projet devient de plus en plus pourri au fil des années. au bout d’un moment il faudrait tout réécrire, mais celà coûte trop d’argent. Et le but d’une entreprise ce n’est pas de faire un logiciel de qualité, mais de faire des rentrées d’argent, ce qui n’est pas tout à fait pareil.
Je dirais que la chance des logiciels libres c’est qu’ils ne s’inscrivent pas dans une relation clientèle qui amène à ce genre de chose. Et la chance d’une entreprise comme Microsoft c’est qu’elle a un tel poids qu’elle peut se permettre de dire à ses clients « vous mangerez ce qu’il y a dans votre assiette ». Je n’ai pas dit qu’ils ne sont pas à l’écoute de leur client mais ils peuvent se permettre de livrer un logiciel que s’il est effectivement fini (s’ils ne commettent pas de nouveau l’erreur d’appeler une truc « windows 95 » et du coup d’être obligés de le sortir en 95) ou d’imposer leurs choix techniques (de qualité, ou du moins cohérents pour eux).
Je vois bien en quoi ca réduit les couts… Les gens du QA (test-intégration, donc) sont rarement développeurs, cela aide donc les QA à réduire leurs coûts de beaucoup (car ils auront BEAUCOUP moins de boulot, le produit étant moins buggé quand il arrive, 80% des bugs, notamment des bugs d’intégration, étant éliminés par la moulinette pré-programmée), en n’augmentant que légerement le coup de développement.
En revanche (et ça n’était pas clair, je demande une précision), cela ne remplace PAS les tests, et la necessité d’une équipe de tests, séparée totalement de l’équipe de dev (c’est juste que ca réduit cette équipe, car ils ont moins de versions à tester eux meme « à la mimine » pour pas grand chose).
Enfin à mon avis, ce système est l’aboutissement de la mise en place d’une démarche qualité balèze, parceque les specs, faut pas qu’elles bougent, ce qui implique que la conception doit être béton (fini la conception à l’arrache), et ça demande une rigueur très importante.
Nan parceque si la conception bouge tout le temps, le dev doit modifier sa moulinette alors qu’il a la tete dans le guidon, et y’a moyen que ca parte en vrille très vite là
Et le problème en France, comme dit cocobill, c’est que le client est lourd, très lourd, et change le cahier des charges tout le temps (ca va de la couleur du bouton à la nouvelle donnée à intégrer), et ça peut impacter la conception (sauf que si la conception est bien pensée, à moins d’une modif fantaisiste, ca ne devrait pas impacter tout le modèle, mais bon… comme j’ai dit, si le dev doit sans arret modifier sa moulinette, c’est pas bon )
Moi je crois personellement que c’est surtout une question de methode de travail. Le LL s’en affranchit (de ces changement/exigence changeante du client) justement parcequ’il n’y a pas de relation client directe et que si le « client » veut quelque chose, il se le rajoute dans le source ou il attend que quelqu’un veuille bien lui faire. Mais ca veut pas dire que il y a pas moyen d’ameliorer les choses dans le cadre du developpement « Sur commande » ou commercial.
La regle d’or que, je pense, a tres bien compri MS, c’est que le developpeur, son metier c’est d’ecrire du code. C’est pas de gerer les docs et le specs, c’est pas d’etre en relation avec le client, c’est pas de parler au marketting, ou aux commerciaux. Si tu rassemble l’integralite de ces taches qui sont « pas du code », tu as une quantite de travail phenomenale et c’est chez nous exactement le role du PM (product manager) qui est la troisiemme branche ont je parle plus haut. Ils permettent d’isoler les devs de ces trucs, et surtout ce n’est pas le chef du projet qui a ce boulot. Il n’y a aucune relation de hierarchie entre le codeur et le PM. Le PM est la pour ecrire les specs, parler aux clients, etre sur que les specs sont en accord avec les attentes du clients, etc. Il est la pour que le dev soit « isole » par un fusible qui lui evite les delire d’un client qui change d’avis tous les deux jours. Il est la pour « decoder » ce que veut le client (et pas ce qu’il dit qu’il veut). Et je suis persuade que c’est un metier a part entiere qui demande des qualites et des competences qui ont RIEN a voir avec celles d’un codeur (et en particuleir des competences sociales et de dialogues… qui sont en general… pas si developpees que ca chez la plupart des codeurs). C’est je crois une des differences majeures que j’ai rencontre en arrivant a MS et je suis 100% convaincu que c’est un des facteurs les plus fondamentaux de la reussite d’un projet d’envergure.
Pour URDLE:
Le mythe de la spec qui bouge pas c’est exactement ce que c’est : un mythe. C’est juste impossible a imaginer, et ca arrive absolument jamais. La question apres c’est justement: quelle est la meilleure methode pour gerer un projet avec des specs qui bougent et comment minimiser l’impact des changement et les changement eux meme. D’ou le role du PM detaille plus haut, d’ou les experiences avec l’XP, etc. Si tu pars sur un hypothese : je met en place une methode qui est super solide si les specs changent pas, et si tout le monde est rigoureux 100% du temps, tu peux etre sur que ca marchera jamais La rigeur est bien sur importante pour faire un vrai taf de pro mais encore plus important c’est le flexibilite et l’adaptabilite. Et ca s’invente pas, ca s’assure par des methodes appliquees rigoureusement C’est pour ca que les methodes de XP apportent en theorie quelquechose en plus car elles permettent une plus grande flexibilites. Elle reduisent pas le role de l’equipe de test (qui doivent etre en parti au moins des codeurs, et des bons). Elles permettent juste cette plus grande reactivite aux changement…
(sinon pour ce qui est de re-ecrire en partant de zero je suis pas d’accord si tu lis les textes de Joel Spolsky - un des gourous du managment de projet logiciel - il demontre que toutes les boites qui font vraiment ca se cassent la gueule ou se mettent en grande difficultes, exemples concrets a foison a l’appui. Repartir de zero est un challenge enorme qui te met dans les choux par rapport a la concurence. Je conseille fortement son site d’ailleurs.)
D’accord avec coccobill, pour les gens qui bossent pas dans des boîtes “sérieuses”, les tests c’est de la grosse rigolade.
Dans ma boîte on doit faire la majorité des trucs à l’arrache, pour avant-hier, et que ça marche bien, évidemment. Alors tu codes vite, souvent pas très bien, tu fais 2-3 tests, tu passes ça au collègue “testeur” ( et doit tester à lui tout seul le code de 15 programmeurs, HAHAHAH ), puis à un troisième larron sensé être “user final” qui va faire encore 10 minutes de tests. Tests que tu dois spécifier, donc le gars va faire EXACTEMENT les même tests que toi, donc ça risque de marcher. Par contre n’ayant vraiment pas que ça à foutre et avec le téléphone qui sonne toutes les 10 minutes, il va pas s’amuser à chercher le schmilblick.
Si ça crashe pas, ça part direct chez le client, qui avec pas de chance va appeller tout faché 10 minutes après que ça marche pas. Et ça recommence …
Tout ça pour dire que ça fait plaisir de voir que des gens bossent “sérieusement”, mais malheureusement c’est pas le cas des 3 boîtes dans lequelles j’ai bossé. Et je pense que dans 80% des petites boîtes dirigées par des gens pas très doués ça risque d’être la même chose.
Donc pour revenir au sujet principal, comme partout, dans le libre il y a des logiciels bien faits, testés, documentés et tout le toutim, mais une grosse partie fait sans. Et c’est bien dommage.
Mon post donnait un avis général sur une méthode et était une réaction au thème général de l’article concerné. Je ne fais pas l’analyse de l’XP (que je ne connais pas). Il faut noter qu’il est pris à titre d’exemple.
Je viens de parcourir en travers la doc XP et le principe me semble très bien : réactivité et réalisme me semble des données parfaitement en phase avec le dev.
Je cite :
[quote]Les test unitaires
Ils sont une pierre d’angle de la programmation extrême.
L’accomplissement des tests unitaires nécessite de :
Récupérer une ossature de test unitaires : celle-ci aidera à la constitution d’une suite de tests automatisés.
Tester toutes les classes du système Il est préférable de créer les tests préalablement à l’écriture du code. Ceci permet d’avoir très tôt des informations de retour pendant la réalisation.
Les tests unitaires sont livrés dans le dépôt des codes source accompagnés du code qu’ils testent . Tout test unitaire trouvé manquant doit être immédiatement conçu. Un ensemble complet de tests est ainsi disponible au moment voulu.[/quote]
Je suis bien d’accord et de ce que j’en ai lu pour le moment, l’XP est intéressant.
[quote name=‘coccobill’ date=’ 9 Feb 2005, 11:03’]J’ai 6 ans d"expérience dans le dev dans des SSII et chez un éditeur de progiciel. Le problème que je vois très souvent dans tout ce qui est specs/docs/tests c’est les changements de dernière minute, c’est les clients.
[right][post=“330716”]<{POST_SNAPBACK}>[/post][/right][/quote]
On va encore dévier sur les SSII. Hors sujet, d’autant que tu peux toujours gueuler avec arguments à l’appui car si tu te laisses faire tu vas te retrouver de toute façon en échec à la fin du projet…et ce n’est pas spécifique aux SSII. Il faut simplement avoir bien fait (ou refait) l’expression des besoins avec les utilisateurs en temps utile, avec entretiens réguliers, et pas à l’arrache à la fin. Un client bon gestionnaire doit avoir conscience qu’à trop presser le citron, ça ne lui coutera pas plus cher si c’est au forfait mais ça va déraper en délai…c’est à dire au bout du compte quand même coûter des sous.
[quote name=‘GloP’ date=’ 9 Feb 2005, 11:20’]La regle d’or que, je pense, a tres bien compri MS, c’est que le developpeur, son metier c’est d’ecrire du code. C’est pas de gerer les docs et le specs, c’est pas d’etre en relation avec le client, c’est pas de parler au marketting, ou aux commerciaux[…]Ils permettent d’isoler les devs de ces trucs, et surtout ce n’est pas le chef du projet qui a ce boulot. Il n’y a aucune relation de hierarchie entre le codeur et le PM.
[right][post=“330723”]<{POST_SNAPBACK}>[/post][/right][/quote]
C’est l’idéal mais dans les petits projets, ou dans les régies, on est obligé d’être tout cela à la fois sinon on se fait bouffer par le client/utilisateur, surtout quand les gens censés nous isoler nous mettent au contraire une pression supplémentaire et nous demande de la fermer.
