mercredi 01 juillet
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Démarche qualité et Logiciel Libre

Posté par Lucas (). Modéré le 08 février 2005.
0
Grâce à leur énorme base d'utilisateurs-testeurs, les Logiciels Libres sont d'une qualité bien supérieure aux logiciels propriétaires. Cette idée répandue est généralement fausse. Dans la pratique, de nombreux logiciels libres sont aussi, voire plus bogués que des logiciels propriétaires.

La suite plus bas ...

> Lire la suite (195 commentaires, moyenne: 2,8).   [dépêche : 3214 caractères]

Dans le monde du Libre, deux comportements sont fréquents parmi les développeurs :

- Les hardcore programmers : "Je peux écrire 1000 lignes de code d'un seul jet, et ça marche direct. Les tests, c'est pour les losers qui savent pas coder."

- Les extrémistes du modèle de développement Open Source : "Des tests ? Pour quoi faire ? C'est mes utilisateurs qui les font !"

Comme pour la documentation, on touche ici à une des limites du Logiciel Libre : les développeurs sont pour une grande majorité bénévoles, et ne veulent pas s'embêter avec tout ce qui n'est pas fun : documentation, tests, ...

Dans le monde propriétaire, les méthodes de développement intègrent les tests au développement du logiciel. eXtreme Programming (XP), par exemple, prône l'utilisation intensive de tests, et notamment de tests unitaires. XP recommande même d'écrire les tests avant le code à tester.

Mais la plupart des logiciels libres ignorent totalement cette démarche, et se basent sur une démarche qualité incomplète basée sur des Bug Tracking Systems ou Bugzillas : les bugs remontés ainsi sont en général les bugs les plus apparents, mais un bug bien enfoui peut rester non corrigé pendant des lustres. Ce bug très gênant de gconfd est un bon exemple : un bug dans un algorithme de gestion d'arbre présent depuis GNOME 2.0 (juin 2002), signalé fin septembre 2004, corrigé début février.

Et même si un développeur de Logiciels Libres voulait tester son code, avec quoi le ferait-il ? Les ateliers de test libres sont rares (je ne connais que DejaGNU) et peu utilisés, sauf pour quelques projets plutôt faciles à tester (Binutils, Coreutils, Glibc, GCC, uclibc ...). Du côté des langages de script, c'est un peu mieux : beaucoup de programmes Perl sont livrés avec une suite de test et Python a PyUnit (mais est-ce vraiment utilisé par les développeurs ?). Ruby, langage pour XP par excellence, se démarque : l'interpréteur est testé par le rubicon (un vrai jeu de mots d'informaticiens au passage : Ruby doit passer le Rubicon...), et les tests unitaires sont largement utilisés par les développeurs.

Alors que les logiciels propriétaires populaires deviennent de plus en plus robustes (loin est le temps où Windows plantait sans arrêt), il est important d'augmenter la qualité des Logiciels Libres. Cela passe par l'utilisation massive de techniques ayant fait leurs preuves dans l'industrie, mais mal maîtrisées dans la communauté.

On peut aussi se poser une question plus profonde : Alors qu'avec Perl, Python, Ruby et C#, nous avons des langages permettant de développer efficacement des applications de haut-niveau, pourquoi continuer à développer majoritairement en C/C++, avec lesquels il est nettement plus facile d'introduire des bugs ? Pourquoi ne pas limiter l'utilisation de ces langages aux bibliothèques ?

Qu'en pensez-vous ? Testez-vous vos applications ? Avec quoi ?

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

ha ?!??

Posté par Christophe Merlet (page perso, ) le 08/02/2005 à 22:28. (lien). Évalué à 7.

A la lecture de cette humeur, j'était persuadé que c'était un journal privé de seconde page, puis, j'ai vu en haut à droit "modéré par...". On est donc dans une news de première page, c'est dire l'importance de la reflexion.

J'était prêt à parler de troll gratuit sans fondement, mais si les modéros juge que c'est de la bonne news de première page, c'est que je n'ai pas du savoir tirer la substantifique moelle de cette information.

Il est tard, je suis fatigué, ça doit être ça...

Ah oui mais...

Posté par l_arpenteur_k (page perso, ) le 08/02/2005 à 22:39. (lien). Évalué à 10.

Pour bosser actuellement avec l'éditeur d'un ERP très spécifique et très proprio, au développement d'un module pour leur appli, je ne peux que constater que leur ERP n'est pas livré si débuggé que ça à leurs clients. Et je ne parle pas du développement en cours mais bel et bien du logiciel vendu. A chaque mise-à-jour de leur produit s'ensuit une floppée de bogues et de cd de correctifs et d'heures de support, hotline et consorts, avec pour consigne de bien surveiller l'intégrité de la base de donnée etc etc.
C'est peut-être un tort, mais je suis plus tolérant avec du logiciel libre (et gratuit, je n'ai pas l'expérience du LL payant) qu'avec un produit sur lequel nous n'avons pas la main, qui coûte une fortune et sur lequel on se permet de laisser traîner d'infâmes bogues. C'est à se demander s'ils ne profitent pas du fait qu'une entreprise puisse être "prisonnière" de leur solution : dans une certaine mesure, c'est moins contraignant de subir une appli mal testée plutôt que de remettre en cause le choix de l'ERP qui gère toute l'infrastructure et de tout changer.
Tout ça pour me dire que je ne suis pas loin du hors-sujet, arf !

d'une extrêmité à l'autre...

Posté par Morreale Jean Roc () le 08/02/2005 à 22:48. (lien). Évalué à 10.

c'est bien de vouloir diluer certains mythes il faut saluer l'initiave, mais de là à dire que dans le monde du logiciel propriétaire = il y a de la bonne doc, des tests à tout les niveaux etc... c'est retomber dans un autre mythe ! Je ne compte plus le nombre d'applications aux sources fermés sans documentation potable, et n'ayant jamais vu l'ombre d'un test, que ce soit pour des logiciels métiers ou de simples sharewares.

Généralités et lieux communs, bonjour !

Un choix perso

Posté par TeXitoi (Jabber id, page perso, ) le 08/02/2005 à 22:59. (lien). Évalué à 2.

C'est en effet un problème plutot classique.

Personnellement, j'ai commencé le petit développement en shell pour faire quelques trucs basique, puis j'en suis venu au C. Ce passage au C m'a beaucoup appris, mais c'est les programmes les plus buggé que j'ai jamais écrit ;-)

Puis, j'ai été forcé de faire du java pour des projets à l'école. J'ai alors découvert les avantages du GC, des gestions d'exceptions et tout ça.

Bon, java, c'est bien, mais la liberté de java est relativement contesté, la machine virtuelle est lente, GNUCLASSPATH pas encore fini, c'est un des derniers trolls encore en vie...

J'ai donc choisi une autre voie : ocaml. Son typage statique, sa forme fonctionnelle et itérative, les 3 modes d'utilisations (interpreteur, machine virtuelle et compilation native), sa gestion d'exception, son GC, son model objet et modulaire, ses outils m'ont fait choisir ce language pour mes futurs développements.

Bon, y'a des inconvénients : langage peu utilisé (ça se rescent sur le manque de bindings sur les interfaces graphiques entre autre). Je pense que c'est pour ça que C et C++ sont très utilisés.

Ocaml me permet donc de faire de petite fonction testable directement au developpement dans l'interpreteur, de ne pas faire d'erreur de mauvais typage, d'utiliser le style itératif ou fonctionnelle... C'est mon choix et je vous laisse le critiquer, et pourquoi pas, me donner de nouvelles idées ;-)

Et Java

Posté par Pierre Tramonson () le 08/02/2005 à 23:04. (lien). Évalué à 9.

C'est dommage de parler d'ateliers de test libres et de langages sans citer Java et tous les projets open-source et/ou libres qui s'y rattachent. JUnit, Ant, les plugins Eclipse, jcoverage...

Voilà avec quoi peuvent être faits les tests en Java :
http://dmoz.org/Computers/Programming/Languages/Java/Development_To(...)

De la criticité des bugs

Posté par Florimond Simonklein (page perso, ) le 08/02/2005 à 23:13. (lien). Évalué à 7.

Bon alors le bug de gnome qui existe depuis la version 2.0, si je comprends bien, il n'a gené personne entre juin 2002 et septembre 2004 ?

Je veux bien croire que les méthodes extrémistes décrites en début "d'article" sont loin d'être parfaites, et même très certainement criticables. Bugzilla doit rester ce qu'il est : un outil de retour pour les défauts du logiciel - ces défauts étant classés par ordre d'importance.

Alors oui, il y a des bugs qui ne sont jamais corrigés pendant des années ; que peut-on en tirer comme conclusion ? Que ces bugs appartenaient à des features qui n'ont servi à personne pendant des années ?

Qu'est-ce qui est important, c'est que les bugs n'existent pas, ou qu'ils soit corrigés rapidement (et gratuitement ?) quand ils sont trouvés ?

Concernant la démarche qualité : wikipedia dit "La gestion de la qualité est un moyen que se donnent certaines entreprises dans un but d'amélioration continue." Je crois qu'un bugzilla rentre tout à fait dans la catégorie "outil permettant une amélioration continue".

Appréciation des langages

Posté par Veiovis () le 08/02/2005 à 23:16. (lien). Évalué à 0.

Alors qu'avec Perl, Python, Ruby et C#, nous avons des langages permettant de développer efficacement des applications de haut-niveau, pourquoi continuer à développer majoritairement en C/C++, avec lesquels il est nettement plus facile d'introduire des bugs ?

Il me semble plus juste de séparer le C et le C++. Je suis d'accord sur le C. En revanche, le C++ a sa place à côté du C#, même pour des applications de haut niveau. Avec les performances en plus. Et je ne comprends pas non plus pourquoi Java n'est pas là.

Python => unittest

Posté par Fabien (page perso, ) le 09/02/2005 à 00:40. (lien). Évalué à 4.

Pour Python, les versions récentes (> 2.2 ou 2.3), PyUnit est livré d'origine sous le nom de module unittest.

balle en argent

Posté par Antoine () le 09/02/2005 à 00:40. (lien). Évalué à 8.

eXtreme Programming (XP), par exemple, prône l'utilisation intensive de tests, et notamment de tests unitaires. XP recommande même d'écrire les tests avant le code à tester.

Une méthodologie n'est pas une balle en argent. Il y en a qui aiment l'extreme programming, d'autres qui n'aiment pas, certains pour qui ça marche et d'autres pour qui ça ne marche pas. Ce n'est pas parce que peu de projets libres utilisent l'extreme programming que "le logiciel libre, ça suxe".
Rappel : une consommation excessive de buzzwords est dangereuse pour la santé.

Je ne suis pas d'accord

Posté par Guy Thiry () le 09/02/2005 à 01:02. (lien). Évalué à 8.

<<< Dans le monde du Libre, deux comportements sont fréquents parmi les développeurs :

- Les hardcore programmers : "Je peux écrire 1000 lignes de code d'un seul jet, et ça marche direct. Les tests, c'est pour les losers qui savent pas coder."

- Les extrémistes du modèle de développement Open Source : "Des tests ? Pour quoi faire ? C'est mes utilisateurs qui les font !" >>>

D'où viennent ces « statistiques » qui semblent improvisées ? Le monde de l'open-source ne contient pas que des « hardcore programmers » ni des extrémistes de quoique ce soit. Il
y a aussi tout plein de gens sérieux capables non seulement de faire des tests unitaires, mais
aussi des tests de performances, de vérifier que ce qu'on produit n'a déjà pas été fait par quelqu'un d'autre, de vérifier qu'on respecte bien certaines règles (notamment en matière de brevets), etc.

<<< Comme pour la documentation, on touche ici à une des limites du Logiciel Libre : les développeurs sont pour une grande majorité bénévoles, et ne veulent pas s'embêter avec tout ce qui n'est pas fun : documentation, tests, ... >>>

C'est vrai qu'un développeur peut avoir tendance à négliger de documenter correctement son
travail. Mais c'est cela n'a rien à voir avec l'open-source (c'est tout aussi vrai pour des logiciels
propriétaires). En ce qui concerne la documentation en général des produits open-source,
celle-ci existe et est même très bien réalisée. Prenons un exemple : la distribution Knoppix.
Il existe des ouvrages très bien faits sur le sujet. Donc la documentation ne manque pas.
Mieux : celle-ci est réalisée par des documentalistes indépendants du produit (c'est un gage
de qualité).

<<< Dans le monde propriétaire, les méthodes de développement intègrent les tests au développement du logiciel. eXtreme Programming (XP), par exemple, prône l'utilisation intensive de tests, et notamment de tests unitaires. XP recommande même d'écrire les tests avant le code à tester. >>>

L'extreme programming n'a rien à voir avec le monde propriétaire. Cette technique peut
très bien s'appliquer en tout en en partie à n'importe quel produit de dévéloppement, qu'il
soit open-source ou pas.

<<< Mais la plupart des logiciels libres ignorent totalement cette démarche, et se basent sur une démarche qualité incomplète basée sur des Bug Tracking Systems ou Bugzillas : les bugs remontés ainsi sont en général les bugs les plus apparents, mais un bug bien enfoui peut rester non corrigé pendant des lustres. Ce bug très gênant de gconfd est un bon exemple : un bug dans un algorithme de gestion d'arbre présent depuis GNOME 2.0 (juin 2002), signalé fin septembre 2004, corrigé début février. >>>

Les techniques de bug tracking sont utilisées par tout le monde (aussi bien open-source
que propriétaire). Même si, comme vous semblez le prétendre, certains bugs mettent trop
de temps à être corrigés, il ne faut pas en faire une généralité. Certains éditeurs de logiciels
propiétaires permettent de faire remonter les bugs rencontrés. Hélas, on n'a jamais de suivi
de ces bugs ni de leur correction éventuelle.

<<< Et même si un développeur de Logiciels Libres voulait tester son code, avec quoi le ferait-il ? Les ateliers de test libres sont rares (je ne connais que DejaGNU) et peu utilisés, sauf pour quelques projets plutôt faciles à tester (Binutils, Coreutils, Glibc, GCC, uclibc ...). Du côté des langages de script, c'est un peu mieux : beaucoup de programmes Perl sont livrés avec une suite de test et Python a PyUnit (mais est-ce vraiment utilisé par les développeurs ?). Ruby, langage pour XP par excellence, se démarque : l'interpréteur est testé par le rubicon (un vrai jeu de mots d'informaticiens au passage : Ruby doit passer le Rubicon...), et les tests unitaires sont largement utilisés par les développeurs. >>>

Les tests unitaires peuvent être utiles mais sont bien loin d'être toujours efficaces voire
nécessaires. C'est clair, si on part du principe que les développeurs open-source ne sont
capables que de pondre 1000 lignes de code d'une traite sans tester, on doit se poser
quelques questions (à mon avis faire des tests unitaires sur 1000 lignes de code, ça ne
sert pas à grand chose). Par contre, les tests d'intégration (quand il faut assembler les
différentes briques d'un produit), c'est tout à fait autre chose : dans ce cas, même si
les tests unitaires répondent OK, en général, c'est au moment de l'intégration que tout
s'écroule.

<<< Alors que les logiciels propriétaires populaires deviennent de plus en plus robustes (loin est le temps où Windows plantait sans arrêt), il est important d'augmenter la qualité des Logiciels Libres. Cela passe par l'utilisation massive de techniques ayant fait leurs preuves dans l'industrie, mais mal maîtrisées dans la communauté. >>>

Ca m'intéresse de savoir d'où vous tenez ce genre d'information. Expliquez-moi pourquoi
des logiciels propriétaires sont devenus plus robustes. J'ai reçu, il y a 6 mois, une lettre
de ma banque me demandant de ne plus utiliser Internet Explorer mais d'utiliser plutôt
Mozilla ou Opera. Contrairement à ce que vous semblez souligner, les logiciels libres sont
bels et bien utilisés dans le monde industriel (et avec des méthodologies adéquates comme
par exemple Rup). L'open source a vielli, il a mûri et il devient tout à fait fréquentable.

<<< On peut aussi se poser une question plus profonde : Alors qu'avec Perl, Python, Ruby et C#, nous avons des langages permettant de développer efficacement des applications de haut-niveau, pourquoi continuer à développer majoritairement en C/C++, avec lesquels il est nettement plus facile d'introduire des bugs ? Pourquoi ne pas limiter l'utilisation de ces langages aux librairies ? >>>

Chaque langage de programmation a sa spécificité. La facilité qu'on a d'introduire un bug
dans un produit ne dépend pas du langage choisi : un développeur conciencieux en C n'a rien
à voir avec un développeur débutant en Java. L'open source est une bénédiction dans le
sens où elle ne limite pas les choix des développeurs (par exemple : rien que le C pour des « librairies » ) car cela crée un terrain favorable à l'interopérabilité.

<<< Qu'en pensez-vous ? Testez-vous vos applications ? Avec quoi ? >>>

Le monde open-source n'est pas fait que de « hardcore » développeurs ni d'extrémistes
de tout poil ne désirant rien tester : le monde open-source se dirige à grands pas vers un monde professionnel ouvert : voilà le vrai changement.

???

Posté par fabb () le 09/02/2005 à 01:25. (lien). Évalué à 8.

> Dans la pratique, de nombreux logiciels libres sont aussi, voire plus bogués que des logiciels propriétaires.

Super.

> Dans le monde du Libre, deux comportements sont fréquents parmi les développeurs :

Comme dit De Gaulle :
- "Dans la vie il y a deux catégorie. Ceux qui pensent qu'il y a deux catégories et les autres".

> Comme pour la documentation, on touche ici à une des limites du Logiciel Libre : les développeurs sont pour une grande majorité bénévoles, et ne veulent pas s'embêter avec tout ce qui n'est pas fun : documentation, tests, ...

Pour la documentation, c'est globalement vrai. Mais notes aussi que la documentation des logiciels proprios n'est pas toujours top non plus. De plus avec le logiciel proprio il manque une doc souvent indispensable :
- les sources

Certe on peut documenter exhausivement chaque fonctionnalité et chaqu'un de ses comportements en fonction de l'environnement, mais ça coûte très cher pour certains projets.

> Mais la plupart des logiciels libres ignorent totalement cette démarche, et se basent sur une démarche qualité incomplète

Le problème est qu'il n'y a AUCUNE bonne méthode. Linux (via OSDL) avait bosser sur la question et pour finir ... c'est toujours les tests "grandeurs natures" qui marche le mieux. C'est toujours les tests avec l'expertise de bons utilisateurs qui marchent le mieux.

> Ce bug très gênant de gconfd est un bon exemple : un bug dans un algorithme de gestion d'arbre présent depuis GNOME 2.0 (juin 2002), signalé fin septembre 2004, corrigé début février.

Cool, un bug. Avec une bonne requête bugzilla on doit pouvoir en remonter une centaine. C'est à croire que MS (le roi du proprio et de la communication sur les divers tests/méthodes qu'ils utilisent) corrige rapidement ses bugs. Tout le monde ici connais des bug dans les produits MS qu'ils ont mis des années a être corriger.
Combien a coûté la mauvaise qualité (donc test) en sécurité des produits MS ?
C'est absolument énorme. Aussi bien du côté des utilisateurs que du côté de MS.

J'ai bossé sur les unix proprio et ce n'est pas toujours rose. Entre autre le compilateur HPUX était bien buggué. Certain source pour des raisons que j'ignore totalement ne marchait bien qu'avec "-O0" et jamais avec "-O2". Pourquoi ? Aucune idée. Mais je n'ai jamais eu ce type de problème avec gcc.

> Et même si un développeur de Logiciels Libres voulait tester son code, avec quoi le ferait-il ?

C'est une phrase d'une grande naïveté.
Comment tu fais pour tester le noyau Linux ou gtk ?
Il y a des "trucs" qui supporte bien les tests et d'autres non. Linux est un enfer à tester systématiquement.
Faire des procédures pour Perl, python, etc est plus facile. Notons que ce sont souvent des tests de non-regression et que passer les tests ne signifie pas qu'il n'y a aucun bug. Ça marche uniquement si le bug est reproductible et celà s'appuis aussi sur un bon retour des utilisateurs.

> Du côté des langages de script, c'est un peu mieux

Normal, c'est plus facile.

> Alors que les logiciels propriétaires populaires deviennent de plus en plus robustes

Tu l'as dis. Prends les logiciels libres populaires et ils sont tout aussi robustes et parfois plus que les logiciels propriétaires.

> il est important d'augmenter la qualité des Logiciels Libres.

On ne peut pas être contre.

> Cela passe par l'utilisation massive de techniques ayant fait leurs preuves dans l'industrie, mais mal maîtrisées dans la communauté.

D'où tu sors cette conclusion ?
Le logiciel libre n'a pas de "déficite" de fiabilité par rapport au logiciel propriétaire. Le logiciel libre gagne sur le logiciel propriétaire et singer le logiciel propriétaire uniquement pour avancer la même pub que le propriétaire (test et "toussa") n'est pas à priori ce qu'il faut faire.

> On peut aussi se poser une question plus profonde : Alors qu'avec Perl, Python, Ruby et C#, nous avons des langages permettant de développer efficacement des applications de haut-niveau, pourquoi continuer à développer majoritairement en C/C++, avec lesquels il est nettement plus facile d'introduire des bugs ?

C'est un excellent troll.
Recodes mplayer ou gtk ou Xorg en perl et tu constateras qu'il faut un Pentium XIII à 800THz et 256To de mémoire vive.
Il y a beaucoup de code en C/C++ et dont le niveau de qualité est absolument remarquable. Regardes dans ta distribution préférée pour t'en convaincre.
Si on regarde le nombre de programme en scripts rapporté au nombre de leurs bugs, le score ne doit pas être aussi bon que pour le C/C++.

> Pourquoi ne pas limiter l'utilisation de ces langages aux librairies ?

Tu comprends ce que veut dire le mot "libre" ?

Tu ne sais pas qu'il y a beaucoup beaucoup plus de codes dans les librairies que dans les programmes ?

Si tu ne sais pas ça ...

> Qu'en pensez-vous ?

Comment dire honnètement le fond de ma pensée.
Cette article est une grosse m....

> Testez-vous vos applications ?

Oui.

> Avec quoi ?

Mon cerveau et ça marche assez bien.
Plus sérieusement, les tests ne sont qu'une toute petite partie d'un processus qualité global.
La conception du logiciel est souvent l'élément clef de la qualité.
Le qualité du codage, le soucis du développeur de "bien faire" est aussi extrèmement important.

Les tests c'est pour récupérer ce que les cerveaux des concepteurs et développeurs ont introduit.
Prends des concepteurs nuls et des développeurs nuls.
Tu auras beau blinder les tests, la qualité globale sera minable. Et si la qualité est formidable, le logiciel est nul.

On sait depuis _très_ longtemps qu'un bug découvert en phase de test coûte _très_ cher. Donc depuis bien longtemps, les bons chefs de projets mise à 90 % sur la conception et le développement.
C'est comme ça que le logiciel libre fait globalement. Voir par exemple Linus Torvalds qui est très "chiant" sur la qualité du code ou la conception d'une fonctionnalité. Il a entièrement raison.
Un bon code a peu de bug. Un bon code se debuggue facilement. Il y a toujours quelques exceptions pour confirmer la règle.


Le logiciel libre est "mauvais" quand il n'est pas assez soutenu (manque de testeurs ou développeurs, etc). Si tu veux bien payer des testeurs (car ils ne veulent pas bosser gratuitement) je t'invite vivement dans cette démarche.

Mais le logiciel libre est "bon" et même excellent quand le modèle du libre est pleinement appliqué :
- les meilleurs concepteurs/développeurs et motivés
- grosse base de testeurs qui remontent les bugs


J'ai rien contre les tests, les outils, etc.
Mais je préfère laisser la décision d'utiliser ces outils/méthodes a ceux qui ont l'expertise.

Personnellement, j'insiste sur la conception, le codage et le "soucis de la qualité" à chaque étage (et pas uniquement en phase de test). L'idéal est de "bétonner" en amont au maximum afin que les tests finaux soient le moins nécessaire possible.


QUESTIONS :
Pourquoi linuxfr laisse passer ce genre de troll en première page ?

Le troll il faut le "combattre" et ça bouffe du temps. Je m'en passerais bien.

Préjugés

Posté par RuleZ () le 09/02/2005 à 04:47. (lien). Évalué à 4.

Il me semble que l'erreur ici c'est de chercher à opposer Libre et Propriètaire *globalement*
Ca ne peut mener à *rien*, c'est une démarche *absurde*, on se fonde forcément sur des préjugés.

Ya beaucoup trop de paramètres secondaires qui influenceront la qualité avant même le modèle diffusion, celui-ci ayant même un impacte différent en fonctions de chacun des paramètres : nombre de dév et expérience, nombre d'utilisateurs et exigences, masse du projet, importance du projet (critique ou pas), nature de l'utilisation, etc..

Et surtout, une démarche qualité ne se résume *absolument pas* aux tests unitaires, ils ne sont qu'un simple outil pour venir l'appuyer !

Entre conception : organisation humaine, architecture du projet, rigueur du code ...
Et utilisation : Ergonomie du reporting des bug et organisation/implication/réactivité des correcteurs ...
On n'en est pas encore aux tests unitaires, mais on a déja énormément de quoi influencer la qualité. Et ici sans même encore parler de Libre ou de Proprio, on n'en est encore à des paramètre qui viendront influencer le projet en fonction avant tout des caractéristiques de celui ci.


Maintenant, pour faire cette opposition générale Libre/Proprio au niveau de la qualité de conception justement, et pour troller un peu: je prends deux projets identiques en tout point, deux équipes de base identiques aussi (même taille, même compétences et même état d'esprit), excepté que l'un des projets sera proprio, l'autre libre ...
Tout ce que je voie c'est que l'équipe "Libre", du simple fait des implications de la diffusion, se verra bénéficier d'une meilleur qualité de conception, puisqu'ils se voient imposer des contraintes supplémentaires de par la nature même de la diffusion, du simple fait que le code soit diffusé avec le binaire : pour le libre, les sources font partie du produit final, la qualité de la conception bénéficiera donc des contraintes et objectifs qualitatifs du produit final dans son intégralité !
Et là, c'est sur, je ne pourrais que conseiller à l'équipe "Proprio" de s'imposer des tests unitaires pour compenser cette faiblesse par une contrainte supplémentaire.

test unitaire en C:C++ et autre

Posté par Monsieur Flynn () le 09/02/2005 à 06:16. (lien). Évalué à 1.

Tout d'abord je suis comme beaucoup ici, je ne comprends pas pkoi le java est absent ?? c'est pourtant un langage pour lequel une palanqué de librairie de test Junit et autre ont été developpé .. ( je pense même mais je peux me tromper, que le java doit faire parti des langages ayant le plus d'outil de test ).

Pour C et C++ il est trés simple de tester .. tu fais tes tests unitaires avec par exemple Cppunit. Tu vérifie tes fuites mémoires avec valgrind.
Tu vérifie ta couverture de code avec gcov, tu utilises gprof ...

Les outils existent également, suffit de vouloir vraiment tester son programme et pas de dire ; oh ca serait bien de tester mon programme C++ mais c'est trop dur de chercher sur Google...

ensuite .. Perl est a mon avis la pire abominasserie au niveau test et debug ... Et pour python ( je suis pas spécialise ) mais il me semble qu'il est super simple d'introduire des bugs ultra difficiles à trouver en égard au caractére totalement dynamique du langage...

Et puis utiliser des poncifs aussi éculés que les dev logiciels libres sont tous des gens qui ne testent pas ou dans les boites proprios ils font leur tests et tout et tout ( tu as déjà bosser dans une boites qui fait de l'édition proprio ? ), je trouve ca un peu simple.. :)

Enfin toute ta prose t'auras au moins permis de decouvrir un nouveau langage le Java ( vu qu'apparement tu connaissais pas ) et de découvrir des outils de tests pour le C/C++ :)

Droit de réponse

Posté par Lucas () le 09/02/2005 à 07:02. (lien). Évalué à 9.

Bon, c'est moi qui ai posté la news. Je vais répondre en bloc à pas mal de remarques vues dans les commentaires. Mais d'abord, le but de la news est de faire prendre conscience que tout n'est pas parfait au royaume du libre. Et les commentaires ne m'ont pas fait changer d'avis.

Exemples donnés : Mozilla, GCC

Oui, à mon avis, Mozilla est peut-être un peu moins buggé que IE. Oui, il y a des logiciels libres qui sont très fiables (j'en cite d'ailleurs dans la news). Souvent, ils sont testés correctement (cf Gcc). Mais la très grande majorité des LL ne sont pas d'une fiabilité irréprochable (loin de là)

Java

Pour Java, c'est vrai que j'ai oublié de le citer (mea culpa). Mais l'utilisation de Java dans la communauté (pour produire des logiciels libres) reste assez anecdotique.

Outils de test pour C/C++

Après, j'ai eu droit à une liste exhaustive de moyens de tester du C, du C++. Oui, bien sûr, ca existe. Mais le problème, c'est que leur existence ne suffit pas à rendre tous les pgmes C/C++ moins buggés d'un seul coup. Il faut les utiliser. Et y a pas grand monde qui le fait.

Le bug de gconfd

L'exemple du bug de gconfd était intéressant car il s'agissait d'un bug enfoui très loin dans le code. C'est le genre de bugs très difficile à faire remonter par un utilisateur, car il peut être rencontré de manières très différentes et pas forcément fréquentes. De plus, c'est typiquement le genre de bugs qui est facile à détecter avec des tests.

"Certains logiciels propriétaires sont buggés eux aussi"

Ca, c'est le raisonnement le pire. "On fait du code pourri, mais c'est pas grave, les autres aussi !" Dans la dépeche, je disais "Logiciels propriétaires populaires", pas "Tous les softs proprios". Tout ce que je veux dire, c'est que les softs propriétaires ont fait (pour beaucoup) de gros efforts côté qualité ces derniers temps, et que l'argument des logiciels libres plus fiables ne tient plus vraiment. La qualité des LL et des LP devient (à la louche) égale. Et pour que les LL reprennent la tête, il faudrait que beaucoup de développeurs acceptent de voir leur code d'une manière un peu moins biaisée, et se rendent compte qu'il contient des bugs et que le tester peut améliorer les choses.

Libre...

Posté par PsychoFox () le 09/02/2005 à 08:16. (lien). Évalué à 2.

Je ne vois pas le rapport entre ton raisonnement et les logiciels libre (à part les caricatures ridicules sur les "hardcores programmers" et "extremistes du libre").

Les problèmes mentionnés ici sont valable pour tout. Que ce soit du proprio ou du libre, on retrouve ce genre de pratiques. La seule chose, c'est que ça se voit plus quand on peut lire le code en question, et que pour un logiciel libre, on distribue généralement le produit avant qu'il soit complet. Dans le monde du proprio, ce serait incensé de vendre un produit au stade du prototype ou de la version alpha (pourtant dans la réalité c'est presque ça).

On en est arrivé à un point ou même les freewares/sharewares proprio distribués un peu partout, et dont on se méfiait tant il y'a quelques années, sont arrivé à un niveau de qualité que beaucoup de gros produits proprio de grands éditeurs n'ont pas. Moi ce qui me fait halluciner, c'est quand ma boite achète un produit proprio à plusieurs centaines ou milliers de francs pour avoir une usine à gaz buggée qui te mets un PIV 3Ghz sur les genous pour un truc qui ne devrait pas consommer particulièrement de ressources.

Motivation initiale

Posté par Thomas Petazzoni (page perso, ) le 09/02/2005 à 08:26. (lien). Évalué à 10.

Bonjour,

J'ai personnellement beaucoup insisté auprès de Lucas pour qu'il poste une news sur le sujet. Toutefois, à l'origine, notre discussion est partie d'un billet qu'il avait rédigé sur son blog : http://www.lucas-nussbaum.net/blog.php/?2005/01/04/78-la-demarche-q(...) Ce billet n'opposait en rien logiciel propriétaire et logiciel libre. Il se demandait simplement si les logiciels libres étaient suffisamment testés, si oui, lesquels et avec quoi. Il se demandait également ce qui pouvait être amélioré de ce coté là, et si le fait que le Logiciel Libre soit principalement développé par des amateurs chevronnés pour le « fun » fasse que peu de logiciels soient testés.

La news publiée a malheureusement complètement changé le ton du billet. Au lieu de poser des questionnements sur les Logiciels Libres, de s'interroger sur ce qui se fait, ce qui est améliorable, elle affirme que les Logiciels Libres sont mal testés et que dans les logiciels propriétaires c'est nettement mieux.

Résultat : un énorme troll, avec un débat pas très intéressant.

A mon avis, les questions qu'il faut se poser, ce sont les suivantes :
- quels sont les Logiciels Libres qui sont déjà testés, comment le font-ils, est-ce applicable à d'autres Logiciels Libres ?
- quels sont les outils disponibles, que permettent-ils, comment fonctionnent-ils ?
- comment amener les développeurs de Logiciels Libres à tester de manière plus automatisée leurs logiciels, et à ne pas uniquement reposer sur le feedback des utilisateurs ?
- quelles sont les techniques et outils permettant d'automatiser le test des logiciels utilisant des interfaces graphiques ? (en effet, gcc, glibc, c'est relativement simple à tester, il suffit de compiler un fichier, de regarder si la sortie est correcte, et c'est bon. Mais pour Ooo, comment faire ?)

Personnellement, la réponse ou les débats suscités par ces questions m'intéressent réellement.

Et Debian ?

Posté par R4f (page perso, ) le 09/02/2005 à 08:47. (lien). Évalué à 4.

Je suis étonné de ne pas voir cité le projet Debian, exemplaire en ce sens. Il s'est doté d'un département Assurance Qualité (QA : http://qa.debian.org/) que bien des projets et entreprises propriétaires, voire libres, devraient envier...

J'aimerais bien avoir une réaction de Raphaël Hertzog à ce sujet !

D'autant plus que les tests unitaires ne sont qu'un élément (parmi tant d'autres) de la qualité d'un logiciel. Le titre de cette dépèche est un peu racoleur en ce sens...

Pourquoi tant de haine

Posté par Guillaume Knispel () le 09/02/2005 à 08:56. (lien). Évalué à 0.

J'aimerais savoir pourquoi une confusion ambulante trollistique entre modèle de développement et license se balade en premiere page sur lfr ?

A moins d'avoir des statistiques précises et fiable (et pour compter les bugs, on sait tous que c'est plus difficile), cet article expose un point de vue absolument sans fondement, comme le serait le point de vu adverse.

Il ne faut pas oublier que des bouses existe dans le LL, tout comme dans le LP, mais de là a mettre tous les LL dans un panier et tous les LP dans l'autre... Abus complet.

Vient ensuite le moment de la critique gratuite des bugzilla dont l'inefficacité n'est pas non plus démontrée.

Je croyais bettement qu'il était loin le temps des trolls "ca va plus vite que vous", "y a moins de failles que vous", "y a moins de bugs que vous", ...

A oui j'ai failli oublier de parler d'un moment ou j'ai bien rit : quand j'ai lu que les chaines de compilation était facile à tester :p

Choisir un cycle de dev

Posté par Franck Hanot (page perso, ) le 09/02/2005 à 09:33. (lien). Évalué à 5.

Oy,

Cette news a le mérite de poser le problème et j'en remercie son auteur.
Premièrement, la problématique est différente selon qu'on développe un logiciel ou un progiciel car les contraintes sont bien différentes.
Or, la carte de visite du logiciel libre et/ou de Linux, ce sont des projets logiciels (Apache, mySql (!), Mozilla, etc...). La pire des erreurs serait de les comparer le cycle de développement des logiciels avec celui des progiciels. On ne développe pas une appli bancaire spécifique comme on développe un navigateur. Le progiciel est développé avec des ressources déterminées selon le budget, il est à usage unique, spécifique, pas forcément évolutif, et le déploiement se fait en lien direct avec l'équipe de réalisation. Pour le logiciel c'est tout l'inverse.

Deuxièmement, parlant de logiciel, le milieu du libre fait peut-etre les frais d'une liberté, celle de ne pas avoir de contrainte subie. Si Mozilla répond à IE en terme de fiabilité, respect des standards, rapidité, ouverture, etc., c'est par la seule motivation de leurs auteurs et non pas parce qu'un objectif commercial a été défini. Du coup, un cycle de développement n'est mis en place que si les développeurs le veulent bien. C'est une erreur.
Personne ne doit faire l'économie du choix d'un cycle de développement, quel qu'il soit (XP, RAD, V, W, cascade, étoile, spirale (ça c'était le passage "j'en connais des choses")).
La question n'est pas de savoir s'il faut en choisir un, mais lequel choisir. Et il est vrai que le seul choix d'un bug tracker n'est pas suffisant.
Au passage, l'XP (qui ne s'applique qu'aux progiciels) est un remâchage marketing de méthodes éprouvées. Son seul mérite est de faire oublier le RAD (Rapid Application Développement) qui foutaient dans la mouise les développeurs dont les CdP pensaient que c'était le moyen de développer des applications plus rapidement (alors que ça incite seulement à se donner les moyen de définir rapidement les spécifications en lien avec le client et donc de perdre un minimum de temps, nuance)

Tests sur la sécurité du code

Posté par Robert VISEUR (page perso, ) le 09/02/2005 à 09:46. (lien). Évalué à 1.

Que pensez-vous de l'utilisation d'outils d'analyse de code comme, par exemple, pour les aspects relatifs à la sécurité, Flawfinder et RATS (au passage, ça répond en partie à la question sur la disponibilité d'outils d'analyse) ?

URL :
- http://developpeur.journaldunet.com/news/010530rats.shtml(...)
- http://www.dwheeler.com/flawfinder/(...)
- http://www.zataz.com/documentation/6902/documentation-audit-code-ra(...)

La démarche qualité existe - elle est seulement différente

Posté par herodiade () le 09/02/2005 à 10:36. (lien). Évalué à 4.

Le probleme c'est que les tests unitaires n'attrapent pour ainsi dire jamais les bugs de la vie réelle. Eg, tu peut testunitairiser autant que tu veut les fonctions du noyau linux, vérifier qu'elles font ce qu'on attend d'elles, ça ne les aidera en rien à mieux supporter tel ou tel materiel. La qualité d'une fonction d'une ou d'un groupe de fonction n'induit pas le bon fonctionnement du logiciel !

Les LL misent généralement sur la période d'incubation (elle est souvent très longue) durant laquelle, effectivement les utilisateurs ont leur role à jouer. Mais c'est la condition pour un débug pertinent: un débug en conditions réelles.

Et ça (une longue période d'incubation) c'est très précisément ce que les sociétés developpant des logiciels propriétaires ne peuvent quasiment jamais se permettre.

Une autre méthode très généralement utilisé est la relecture et validation systèmatique des modifications du code source proposées. Relecture par non pas par une ou deux personnes (comme avec la méthode XP), mais par un grand nombre de developpeurs très pointus. Je te recommande à ce sujet de jetter un oeil au fonctionnement de la communauté de developpement d'OpenBSD ou d'Apache.

Complexité

Posté par Giboyle (page perso, ) le 09/02/2005 à 12:10. (lien). Évalué à 2.

En léger décallé, deux petites réflexions :
- un service informatique qui veut fournir à ses "clients" des outils fiables doit bien choisir les produits qu'il déploie. Dans le monde du libre, et sur certaines fonctions, il y pléthore d'options, d'où l'importance de cette phase de choix et d'analyse : la "vitalité" des projets est un paramètre important et qui n'existe dans les logiciels propriétaires que sous la forme de la "part de marché"... Tout ça pour dire qu'il y a mécaniquement beaucoup de déchets dans les LL et qu'il ne faut pas mettre en parallèle la qualité de _tous_ les LL avec celle des logiciels propriétaires, générallement moins nombreux (les barrières en entrée sur le marché ne sont pas identiques).
- les phases de tests qualité c'est bien gentil, mais outre que ça ne remplace pas une bonne architecture des logiciels et la rigueur de programmation, ça marche très mal dès que la combinatoire est importante, dès que le logiciel en question peut être mis en oeuvre dans des situations très variées, dès que la latitude des utilisateurs est très importante. Combien de milliers de pages faudrait-il pour décrire un plan de test complet sur un client de messagerie façon Thunderbird ou sur Open Office Writer ? Quelques millions ? Et combien d'environnements de test ?

Après il faut faire des choix : les ressources consommées par l'assurance qualité seraient-elles mieux utilisées à faire des revues de codes, des re-codage le cas échéant, le tri et l'analyse des rapport de bogues ?

Par contre, en terme de qualité, je crois qu'il est impératif de s'assurer que les développeurs d'un logiciels _utilisent_ ce logiciel. Ca les motive pour bien faire et pour corriger les défauts. Et ça, c'est plus fréquent pour le libre que pour les logiciels des éditeurs à mon sens : les développeurs des LL s'impliquent souvent pour leurs besoins propres, et c'est déjà une très bonne base pour obtenir une bonne qualité...

A titre d'info, je trouve les dernières versions de la suite bureautique d'un-grand-éditeur-américain-que-nous-connaissons-bien _truffées_ de bogues, en pleine régression par rapport à celles d'avant., et ce en dépit de leur procédure qualité certainement très élaborée et onéreuse. Je les soupçonne d'utiliser Open Office :-)

Stop !

Posté par JPz (page perso, ) le 09/02/2005 à 12:10. (lien). Évalué à 10.

Tout d'abord remercions l'auteur de cette news car il soulève un problème intéressant. Je suis effaré par la stupidité de pas mal de commentaires faits par des gens qui :
- confondent tests unitaires et leurs pratiques de bricoleurs (#ifndef, tester les valeurs en entrée de fonction, tester l'application dans leur coin, ...)
- n'ont jamais essayé la pratique des tests unitaires avec un framework adéquat
- font confiance dans la grandeur de leur esprit pour ne pas faire de fautes
- fusillent l'auteur de la news en partant dans un troll hors-sujet tout ça parce qu'il ose mettre en doute certains assertions de la grande communauté du libre.

Pratiquer les tests unitaires, c'est pourtant simple et on se rend très vite compte des avantages que cela apporte. En premier lieu on développe des composants que l'on teste de suite. Assembler des composants blindés aux tests donne un assemblage de meilleure qualité. En second lieu, cela a un impact indéniable sur la modélisation. Un composant difficile à tester est souvent un composant mal modélisé. On va donc chercher à le découpler au maximum de ces dépendances. Au final cela force à faire les choses proprement et l'impact sur le logiciel final est évident. Enfin une autre bonne pratique est que quand je découvre un bug, je ne me jette pas dessus pour faire un correctif. Je cherche d'abord à le reproduire/isoler dans un test unitaire. Une fois cette étape faite, je peux apporter la correction. J'évite ainsi à l'avenir les régressions. Cela peut sembler contraignant voir inutile pour certains, mais cela paie systématiquement quand un projet prend de la taille.

Il serait également stupide de croire que les tests unitaires sont inutiles pour de petits projets. Le temps passé sur les tests lors de la conception (les tests ça ne s'écrit pas après sinon c'est inutile) est largement compensé au final car on converge plus vite vers un logiciel qui marche. Il faut essayer pour s'en rendre compte, ça ne semble pas évident de prime abord ...

Pas mal de techniques récentes intègrent cette notion. Je pense en particulier à l'IoC (Inversion of Control) qui permet l'obtention d'assemblages modulaires de composants découplés. Du coup ces composants sont très simples à tester. Le logiciel est ainsi meilleur.

Enfin il faudrait arrêter de prendre les systèmes de rapport de bugs comme des outils ultimes. Les utilisateurs sont là pour utiliser un logiciel, pas pour chercher dans le code la raison d'un bug. Si certains le font c'est tant mieux, mais la majorité ne le fera pas. Quand on critique MS qui prend ses utilisateurs pour des testeurs tout le monde trouve ça normal, mais quand c'est pour un logiciel libre, tout le monde dit : "envoie un rapport de bug et un patch si possible"...

Il faudrait comparer ce qui est comparable...

Posté par jch () le 09/02/2005 à 12:18. (lien). Évalué à 1.

Je crois qu'on compare des choses qui n'ont rien à voir. On peut pas comparer le développement d'un LL et d'un soft propriétaire.

Quand je regarde mon PC Linux, je me rend compte que pas mal de softs qui y sont installés sont des versions de développement (numéro de version << 1.0). Dans un monde propriétaire, c'est sûr que ces softs ne risqueraient pas de planter : Je n'y aurais pas accès du tout.

D'autre part, pour qu'un projet libre puisse espérer obtenir une base d'utilisateurs (et donc de contributeurs potentiels) non négligeable, il faut releaser souvent (ce n'est pas facilement conciliable avec la mise en oeuvre d'une politique de tests rigoureuses).

D'autres parts, tester tester, oui, mais comment ? J'ai l'impression que cette news fait l'impasse sur une différence majeure entre Linux et les OS propriétaires : la diversité.

Un logiciel peut bien fonctionner sur la machine d'un développeur et être instable sur celle d'un utilisateur pour peu qu'ils n'aient pas exactement les même bibliothèques (versions ou options de compilation légèrement différentes).

Oui, il y a des projets n'ayant aucune politique de tests digne de ce nom (mais c'est en rien spécifique au monde du LL), mais pour les autres, je crois que ce n'est pas aux développeurs, mais aux intégrateurs (donc les distributions) d'assurer le gros des tests et de ne pas intégrer de versions de développement en les présentant comme "stables"...

Tests de performances

Posté par Stéphane TRAUMAT (page perso, ) le 09/02/2005 à 12:20. (lien). Évalué à 2.

Personnellement, je pense que ne pas utiliser des tests unitaires est la plus grosse erreur qu'on peut faire en dev...

En plus des tests unitaires, je pense qu'il faut aussi tester la montée en charge... et c'est dans cette optique que nous développons un nouvaeu projet: http://junitscenario.sourceforge.net/(...)

Une première version du projet est attendue ce mois-ci

distinguer logiciel OpenSource et logiciel OpenSource

Posté par Cyril PIERRE de GEYER (page perso, ) le 09/02/2005 à 13:48. (lien). Évalué à 1.

AHMA il faut distinguer deux types de logiciels : ceux impliquant une grande communauté et ceux développé par une poignée de développeurs.

Je pense que ce billet fait référence à la news sur le peu de bug de MySQL: http://news.zdnet.com/2100-1009_22-5563918.html(...)

Il y est dit que MySQL doit la qualité de son code au fait qu'il soit OpenSource et que de nombreux développeurs peuvent faire des retours.
Dans le cas d'un outil comme MySQL c'est sur qu'avec le nombre impressionnant d'utilisateur certains se trouvant confronté à un bug pourront aller voir le code source et corriger l'erreur avant de le signaler aux equipes de MySQL.
Pour ce type d'outils le mode logiciel libre est positif (mais peut être negatif si des crackers profitent du source pour rechercher des failles dans le but de les exploiter).

Par contre si on parle de logiciels libre type le petit outil de CMS développé par une ou deux personnes en Java, Perl voire PHP(la techno importe peu) alors la oui il peut rester des bugs faute de mainteneurs et de testeurs.

On ne peut donc généraliser, notre monde est trop large.

Cyruss

--
Co auteur du livre PHP 5 avancé
http://www.amazon.fr/exec/obidos/ASIN/2212123698/

Martin Michlmayr

Posté par imalip (page perso, ) le 09/02/2005 à 14:15. (lien). Évalué à 6.

Pour ceux que ca interesserait, Martin Michlmayr, accessoirement actuel Debian Project Leader, fait precisement une these a Cambridge sur le sujet "quality management in free software projects". Il a d'ailleurs donne une petite conf sur le sujet a Oxford il y a deux semaines, assez interessante.

Plus de details sur son site : http://www.cyrius.com/research/index.html(...)

--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

Haute teneur en troll

Posté par XHTML/CSS inside (page perso, ) le 09/02/2005 à 17:25. (lien). Évalué à 1.

Troll potentiel détecté !

Qu'est-ce qu'on dit dans ce cas ? Ah oui :

Trop gros passera pas !


Plus sérieusement, je trouve que les propos de la news sont un peu secs :
Alors que les logiciels propriétaires populaires deviennent de plus en plus robustes (loin est le temps où Windows plantait sans arrêt), il est important d'augmenter la qualité des Logiciels Libres

Je suis tout à fait d'accord qu'il faut améliorer les logiciels libres (par principe : vive la qualité !), mais je ferais remarquer que les logiciels libres populaires sont particulièrement stables, j'en veux pour exemples (sur le portable du boulot sous Win) : Filezilla, Mozilla, Firefox, Thunderbird, Open Office sont relativement durs à faire planter (perso jamais eu un plantage avec).
(et je passe sur Apache, Linux, etc.)

Je serai plus nuancé, il est vrai que certains softs proprios sont de plus en plus stables (XP ne plante quasiment pas sur les bécanes avec lesquelles je l'utilise), ce ne sont pas tous qui s'améliorent (j'ai essayé Office 2003, et je n'ai pas arrêté d'avoir des plantages dans tous les sens avec Word...), je dirais que c'est la même rengaine pour les logiciels libres (certains d'améliorent, d'autres sont des bouses sans nom).

--
In tartiflette we trust !

Entièrement d'accord, il faut augmenter la qualité des développements

Posté par David Mentré (page perso, ) le 09/02/2005 à 20:29. (lien). Évalué à 4.

Pour ma part, je suis entièrement d'accord avec toi : la plupart du temps, que ce soit pour du proprio ou du libre, on développe toujours comme on faisait du soft dans les années 70. Il faut absolument que les développeurs de logiciel libre s'efforcent de faire un soft sans bugs, avec toutes les techniques possibles.

Par exemple, pour demexp, on utilise :
- un langage de haut niveau, OCaml, avec des fonctionnalités qui évitent certaines classes de bug (un garbage collector pour les bugs mémoires, l'inférence de type pour les bugs sur les structures de données, des exceptions pour les cas d'erreur, ...) ;

- un code documenté avec de la programmation littéraire (voir par exemple http://www.linux-france.org/~dmentre/demexp/demexp-server-book-2005(...) ) ;

- utilisation de générateurs de code à partir de description déclaratives dès que c'est possible. Par exemple la description XDR des formats de messages réseaux nous permet de générer automatiquement les routines d'encodage/décodage ;

- des tests unitaires systématiques pour chaque module, y compris les cas d'erreur. Les tests sont remis à jour quand le code bouge ;

- des tests d'intégration. Comme demexp est un client serveur, le serveur a un mode --autotests où une thread cliente est créée, elle se connecte au serveur et effectue toutes les actions attendues d'un client (y compris tester les cas d'erreur).

J'ai pas encore eu le temps de faire de la vérification formelle, mais j'y pense.

Evidemment, il y a toujours des bugs. Mais au moins les dégâts sont limités.

cmake / ctest

Posté par Mathieu Malaterre (page perso, ) le 10/02/2005 à 01:52. (lien). Évalué à 2.

J'y crois pas. Je trouve pas une seule reference a ctest / cmake ou meme Dart. Tous ces projets sont developpers sous license BSD like, a jour et toujours maintenu. Ils servent dans des projet gigantesques comme ITK, ParaView ou meme VTK.

ctest est la partie de cmake qui permet de dialoguer avec Dart. Tout est genre automatiquement:

- Debut des nightly tests
- Contruction du projet (suivant un script de config)
- Exectution des tests (suivant un script de config)
- Envoi des resultats ( de compilation et d'execution des tests).

La seule chose a faire c'est un cronjob sous *nux ou une schedule task sous win.

ctest permet aussi l'integration avec valgrind, comme ca vaut nightly test permettent aussi de detecter les mem leaks, sans avoir besoin d'attendre des heures le resultats.

Refs:
http://cmake.org (cmake, ctest)
http://vtk.org (VTK)
http://itk.org (ITK)
http://paraview.org (ParaView)
http://public.kitware.com/Dart/ (Dart)

[+] je m'appelle pohrteukoi et je suis un nain

Posté par wahnby () le 10/02/2005 à 11:03. (lien). Évalué à -5.

cette news est nulle et trollesque en plus alors je posterai rien. De toute façon on poura dire tout ce qu'on veut sur le systeme de developement des LL le constat et la -> "ça marche".par exemple aucun logiciel proprietaire n'a eu autant de succé que firefox et poutant y'en a eu des navigateur pas libre. De toute façon les developeur de logiciel libre (enfin beaucoup (ou peut etre que moi mais ça m'etonerai)) programme pour le plaisir donc ils programment comme ils le sentent on peut pas les saouler avec les tests et tout ça.

De toute façon le C c'est le meilleur langage qui existe , apres les langages haut niveau c'est pour les programmeur bidon qui se crois inteligent quand ils rajoutent des contraintes.

[+] Si je peux me permettre

Posté par Wolf Ben (page perso, ) le 10/02/2005 à 14:07. (lien). Évalué à -4.

Je suis vraiment déçu voir outré de voir que sur un site avec autant d'affluence on trouve des personnes qui rédige un peu n'importe quoi vive les Troll.

D'une tout programmer qui se respecte hardcore encore plus que les autres font de la doc génèrent des rapports tel que checkstyle en java ou jdepend, classycle ou et bien d'autre encore.

Associé à çà des test ? Lucas ne doit certainement pas être au courant que Juint est loin d'être le seul à pouvoir créer des classes de tests ! Y'a clover, fitnesse etc.

Il manque vraiment de fondement cet article si les proprio du site font confiance à des personnes qui ne savent apparement pas rédiger un article en faisant un minimum de recherche ...

C'est sur que certain projets "maison" fait par des amateurs qui se disent bon/hardcore programmeurs et qui n'en sont par forcément pour autant ... mais les vrai font çà dans les normes.

Suffit par exemple de prendre les gros projets opensource tel que eclipse, jonas +/- et pas mal de moteur 3D (irlich, 3d crystal).

C'est du n'imp bravo.

Les outils de tests

Posté par Cédric Girard (page perso, ) le 10/02/2005 à 14:55. (lien). Évalué à 4.

Ils existent pour tous les outils, libres ou non

http://xp-france.net/cgi-bin/wiki.pl?ListeDesOutilsDeTest(...)

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.5924s (dont 0.0462 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !