La suite plus bas ... 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 ?
Aller plus loin
- Une présentation de DejaGNU (27 clics)
- Test unitaire sur Wikipedia (21 clics)
- Unit Test sur Wikipedia (plus complet) (8 clics)
# ha ?!??
Posté par Christophe Merlet (site web personnel) . Évalué à 7.
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...
[^] # Re: ha ?!??
Posté par Nicolas Barcet . Évalué à 10.
J'ai travaillé chez plusieurs éditeurs, notament dans le département assurance qualité, et je peux vous assurer que bien chez nombre d'entre eux des bugs considérés comme non majeurs sont détectés bien avant la sortie du produit, ne sont pas corrigés pour des contraintes de timing ou de coût, et ne sont surtout PAS DOCUMENTES au public, de peur de ternir l'image du produit !
Alors oui, tous les projets libres ne sont pas égaux, mais globalement, nul ne peut nier que la méthodologie necessaire pour qu'un projet libre puisse vivre est 1000 fois plus contraignante que chez la plupart des éditeurs. Exemples :
- essayer de faire entrer un bout de code non documenté dans un projet digne de ce nom, on peut voir comment on est reçu;
- la notion d'outil de gestion de source (CVS), quasi obligatoire dans le libre, n'est en place que chez très peu d'éditeurs, et encore, pas forcément sur tous les projets;
- la notion de bugzilla, librement accessible, n'est quasiement JAMAIS offerte par les éditeurs;
- essayer de rassembler une communauté sur le dev d'un projet mal écrit et/ou non documenté et/ou pleins de bugs, on alors peut mesurer sa solitude en tant que contributeur.
En plus, je crois que le simple fait qu'un developpeur sache que l'on puisse lire son code le pique dans son amour propre et le force a produire plus propre que s'il a l'assurance que seuls des binaires seront distribués.
Franchement, là, je suis dégouté à la lecture de cette "news" partial, non éttayée et qui apparement ne vise qu'a déstabiliser l'essort actuel du libre, qui lui, n'est pas sans fondements.
[^] # Re: ha ?!??
Posté par pasBill pasGates . Évalué à 10.
Ca c'est tout a fait normal, a la fois chez les softs proprios et chez les softs libres.
Si tu devais _tout_ corriger avant de sortir une version, tu ne le sortirais jamais ton soft.
Le probleme ici, c'est la maniere dont est gere la QA de bcp de softs libres, ca veut pas dire que c'est super genialement fait chez tous les editeurs de softs proprios non plus.
Alors oui, tous les projets libres ne sont pas égaux, mais globalement, nul ne peut nier que la méthodologie necessaire pour qu'un projet libre puisse vivre est 1000 fois plus contraignante que chez la plupart des éditeurs. Exemples :
- essayer de faire entrer un bout de code non documenté dans un projet digne de ce nom, on peut voir comment on est reçu;
- la notion d'outil de gestion de source (CVS), quasi obligatoire dans le libre, n'est en place que chez très peu d'éditeurs, et encore, pas forcément sur tous les projets;
- la notion de bugzilla, librement accessible, n'est quasiement JAMAIS offerte par les éditeurs;
- essayer de rassembler une communauté sur le dev d'un projet mal écrit et/ou non documenté et/ou pleins de bugs, on alors peut mesurer sa solitude en tant que contributeur.
Alors moi je te le dis clairement que _NON_ un projet libre est pas plus contraignant que chez bcp d'editeurs proprios.
a) Du code non-documente il y en a partout dans le code libre, j'ai fait l'experience avec Mozilla il y a qqe annees de cela, j'en fait encore regulierement des cauchemards. La doc pour developpeurs dans les projets libres c'est dramatiquement inexistant.
b) CVS n'a rien d'obligatoire dans les LL, plein de projets en font un usage intensif, mais plein de projets ne le font pas, et plein d'editeurs proprios utilisent un equivalent aussi bien entendu
c) un bugzilla like a peu pres tout le monde en a un, la difference etant que dans qqe cas du libre il est ouvert, mais c'est pas ca qui va faire que les bugs sont corriges, cf. le bugzilla de Mozilla qui contient des bugs datant de plus d'un an ou deux
d) Demandes aux dev de LL ici combien de gens se sont joints a leurs projets, tu vas etre decu du resultat.
En plus, je crois que le simple fait qu'un developpeur sache que l'on puisse lire son code le pique dans son amour propre et le force a produire plus propre que s'il a l'assurance que seuls des binaires seront distribués.
C'est peut-etre le cas pour certains, mais c'est :
a) tres tres loin d'etre le cas de tous les devs de softs proprio
b) pas ca qui va empecher des mauvais developpeurs ou des developpeurs inexperimentes de faire du code sale, sans doc, ...
Le probleme qu'a mon avis Lucas aborde ici c'est ca :
Bcp de developpeurs du libre(pas ceux des gros projets on s'entend) n'ont aucune idee de ce qu'est la QA. Les tests unitaires, le blackbox et whitebox testing, stress testing, la documentation des interfaces,... sont un terme chinois pour bcp d'entre eux car ils n'ont pas l'experience de gros projets ou ces elements sont essentiels si tu veux arriver au bout.
C'est aussi bien entendu le cas de softs non-proprios, mais ici il s'agit de cibler un probleme qui affecte le libre et qui est en directe contradiction avec le mythe qui veut que les LL soient mieux codes que des equivalents proprios.
[^] # Re: ha ?!??
Posté par fabb . Évalué à 8.
<mode="ma vie">
J'ai repris une applis proprio car les utilisateurs n'étaient pas contents. L'applis (une grosse) représentait 10 années homme. J'ai mis 2 ans (!) pour la rendre satisfesante en terme de qualité (je faisais aussi les demandes d'évolution à la volée au cas par cas) et que l'utilisateur valide la recette de l'applie.
Pourtant il y avait une conception formalisé et "tout le bordel" (doc développeur d'environ 400 pages). Mais je suis par exemple tombé sur une fonction de 2 600 lignes (!) et avec un niveau d'intentation for-mi-da-ble (le tab=8 est inutilisable même avec une petite police de caractère).
</mode="ma vie">
> La doc pour developpeurs dans les projets libres c'est dramatiquement inexistant.
Le ticket d'entré dans un programme est toujours élevé.
Mets le code IE que je regarde s'il est facile de corriger tous ses bugs de non respect des standards. Même s'il est bien documenté, je vais ramer.
> CVS n'a rien d'obligatoire dans les LL, plein de projets en font un usage intensif, mais plein de projets ne le font pas
Troll detected : Trop vague.
La majorité des projets libres ont un CVS ou équivalent.
> la difference etant que dans qqe cas du libre il est ouvert
Troll detected : c'est tout simplement faux.
Dans la très grande majorité des cas c'est ouvert. Et s'il n'y a pas de bugzilla il y a une mailing public.
> cf. le bugzilla de Mozilla qui contient des bugs datant de plus d'un an ou deux
Troll detected : Aucun élément de comparaison disponible (Le bugzilla de IE n'est pas ouvert et IE n'est pas un modèle de qualité (ceux qui font des pages web peuvent le confirmer)).
Combien de développeurs il y a sur Mozilla ?
Combien de développeurs il y a sur IE ?
> d) Demandes aux dev de LL ici combien de gens se sont joints a leurs projets, tu vas etre decu du resultat.
Tu croyais qu'avec le logiciel libre il suffisait de "claquer des doigts" et "plop" t'as plein de développeurs/testeurs ?
La réponse va varier énormément. Linus Torvalds doit être très très satisfait. D'autres sont moins satisfaits.
Mais ce modèle marche extrèmement bien pour les projets "populaires". Évidemment, pour les projets peu populaire, peu demandé ou mal foutu, tu n'obtiendras pas beaucoup de testeurs/développeurs.
Encore une bien médiocre tentative de troller.
Si ça ne présentait pas un intérêt d'être "ouvert", pourquoi tant de gens le font ?
Pour la frime ? Pour que ton projet soit noyé parmis des milliers d'autres dans freshmeat ?
> En plus, je crois que le simple fait qu'un developpeur sache que l'on puisse lire son code le pique dans son amour propre et le force a produire plus propre que s'il a l'assurance que seuls des binaires seront distribués.
Juste pour dire que Nicolas Barcet a parfaitement raison. D'ailleur c'est aussi parfois utilisé en logiciel propriétaire (l'audite par un autre).
Personnellement, je fais plus attention à ce que je vais publier qu'à ce que je fais dans mon coin.
> mais ici il s'agit de cibler un probleme qui affecte le libre et qui est en directe contradiction avec le mythe qui veut que les LL soient mieux codes que des equivalents proprios.
Ce "mythe" n'en est pas un car c'est une réalité !
Prend une distribution généraliste typique (3 à 4 Go) 80 % du code vient de gros projets (Linux, libc, xorg, gnome, KDE, mozilla, tetex, etc). 95 % du code est d'exellente qualité.
Tu fais une fixation sur les 5 % restant pour faire une généralité (bref, un troll de plus).
Tu ignores une caractéristique du libre : libre
Donc chaqu'un est libre de faire un projet pourri et de le rendre public. Et chaqu'un est libre (notament ceux qui font des distributions) de ne pas l'utiliser.
Avec le proprio, n'est visible que ce qui "flatteur" ou vendeur de présenter.
Enfin, le libre ne "vend"/propose pas uniquement du "out of the box". Le libre propose de tout. Des projets finalisés, des projets en beta, des projets solides mais encore en beta (version < 1.0), etc. Par contre les distributions (et notament les distributions orienté entreprise) prendront soit a ne sélectionner que de bon projet et pas le "tout venant". Un petit exemple. Sur mailing Fedora était proposé un serveur de son pour remplacer esd (j'ai oublié le nom du projet). Le code a été rapidement audité et notament par Alan Cox. Conclusion: même si esd n'est pas actuellement activement maintenu, le petit nouveau bien que prometteur a été refusé car insuffisant en terme de qualité.
Compares Solaris à une distribution GNU/Linux "enterprise" et tu verras grosso-modo la même chose en terme de qualité. Pourtant une distribution GNU/Linux est composé à 99 % de logiciel libre minimum. Pourtant un distributeur GNU/Linux "enterprise" n'a pas l'infrastructure QA de Sun.
Et notes aussi que Solaris fournit aussi plein du logiciel libre (OOo évidemment, mais aussi emacs, Gnome, Mozilla, etc).
Tu trolles en comparant ce qui n'est pas comparable. Par essence Le libre (sans passer par le filtre d'un distributeur) propose de tout. Le proprio ne propose que ce qui est "présentable"/"vendable".
Il n'y a aucun critère de qualité dans la qualification libre d'un projet.
Compare le libre une fois filtré (par un distributeur) et le proprio (qui est filtré puisque pas toujours disponible).
[^] # Re: ha ?!??
Posté par pasBill pasGates . Évalué à 7.
C'est sur, mais avoir une doc c'est une aide non negligeable, et Mozilla a l'epoque n'avait rien de substantiel, IE c'est different, il y a des design doc, des specs, ... a disposition.
Dans la très grande majorité des cas c'est ouvert. Et s'il n'y a pas de bugzilla il y a une mailing public.
Et une ML publique contient un moyen simple de trouver la liste des bugs ? Parce que des newsgroups pour des softs proprios il y en a plein aussi, j'appelle pas ca un bugzilla.
> cf. le bugzilla de Mozilla qui contient des bugs datant de plus d'un an ou deux
Troll detected : Aucun élément de comparaison disponible (Le bugzilla de IE n'est pas ouvert et IE n'est pas un modèle de qualité (ceux qui font des pages web peuvent le confirmer)).
Quel troll ? Quel besoin de comparer ? J'ai dit depuis le debut que c'est la meme chose dans le monde proprio. Faut arreter de voir ca comme une comparaison proprio<->libre, des le debut j'ai dit que le probleme etait le meme dans les 2 mondes.
Combien de développeurs il y a sur Mozilla ?
Combien de développeurs il y a sur IE ?
Moi je suis pret a te parier qu'il y a plus de developpeurs sur Mozilla qu'IE aujourd'hui.
Prend une distribution généraliste typique (3 à 4 Go) 80 % du code vient de gros projets (Linux, libc, xorg, gnome, KDE, mozilla, tetex, etc). 95 % du code est d'exellente qualité.
Tu fais une fixation sur les 5 % restant pour faire une généralité (bref, un troll de plus).
Oh que non, plein de gros projets libres ont du code pourri, OpenSSH, sendmail., bind, ... sont des gros projets, et ils sont plein de bugs(comme IE oui), preuve qu'etre un gros projet libre ne suffit pas.
Par contre les distributions (et notament les distributions orienté entreprise) prendront soit a ne sélectionner que de bon projet et pas le "tout venant".
Explique moi alors pourquoi ces distrib ont OpenSSH, sendmail et autres sur leurs CD
Compare le libre une fois filtré (par un distributeur) et le proprio (qui est filtré puisque pas toujours disponible).
C'est un peu facile ca de prendre uniquement les meilleurs softs du LL(bref ceux choisis par une distrib selon toi) et les comparer a tous les softs proprios. Dans le proprio aussi il y a du bon et du mauvais, je vais pas m'amuser a faire une selection pour dire que le proprio c'est Mieux(TM)
[^] # Re: ha ?!??
Posté par fabb . Évalué à 2.
OpenSSh est effectivement un peu pourri dans la façon dont c'est codé. Par contre pour sendmail et bind, il semble que tu n'as jamais regardé et te bases uniquement sur les ragots. Ces deux projets sont extrèmement bien codés.
J'invite tout le monde à regarder les sources de sendmail et bind avant de troller.
Et par pitié ne compares pas les trous de sécurité de sendmail ou bind aux trous de sécurité de IE. Il y a une magnitude de 1000.
> et ils sont plein de bugs(comme IE oui)
T'es charmant.
Dis combien de bugs connus (via un équivalent de bugzilla que tu as cher MS) il y a dans IE, et je te dis combien de bugs connus il y a dans OpenSSH, SendMail, Bind.
N'oublies pas que tu as un avantage : tout le monde ne peut pas ajouter un rapport de bug pour IE.
> Explique moi alors pourquoi ces distrib ont OpenSSH, sendmail et autres sur leurs CD
Déjà openssh est petit. Le src.rpm fait ici : 906 Ko. C'est petit. Nombre de ligne de code "*.[ch]" : 71 670. C'est très petit et gérable même si c'est mal codé.
Pour info, sendmail : 1.9 Mo
bind : 4.3 Mo
A titre de comparaison, gtk2 : 8.9 Mo (sans glib , sans pango), firefox : 31 Mo, KDE 3.3.1 : 330 Mo (dont 180 de i18n).
> C'est un peu facile ca de prendre uniquement les meilleurs softs du LL(bref ceux choisis par une distrib selon toi) et les comparer a tous les softs proprios. Dans le proprio aussi il y a du bon et du mauvais, je vais pas m'amuser a faire une selection pour dire que le proprio c'est Mieux(TM)
Quand tu compares le libre avec le proprio, ne prends que du libre qui pourrait être du proprio et ne prend pas le "tout venant". Pour ton info, ça fait depuis très longtemps que les unix propriétaires fournissent sendmail et bind. Ces deux projets sont d'exellente qualité et font références dans leur domaine.
Donc, t'as trouvé openssh de mal codé. Il fait moins de 1 Mo en src.rpm. Les src.rpm d'une distribution type RHEL (basé sur FC) pèse plus de 2 Go. Tu parles de moins de 0.05 % du code qui constitue une distribution généraliste.
[^] # Re: ha ?!??
Posté par R4f . Évalué à 6.
Oui, et alors ?
En quoi la taille est-elle un critère pour évaluer la qualité ? Parmi les principes d'UNIX, par exemple, il y a celui de faire des petits logiciels (souvent en mode texte), mais qui font bien leur boulot. C'est en les interconnectant (par exemple dans des scripts) qu'on en tire des fonctionnalités avancées. OpenSSH est justement dans cette optique-là, et c'est tout à son honneur !
Pourquoi le logiciel libre devrait-il s'inspirer des mauvais exemples des bloatware du logiciel non libre ?
[^] # Re: ha ?!??
Posté par xavier philippon . Évalué à -1.
De mémoire, un degré de magnitude c'est X10.
Donc 3 c'est 1000 ce qui est déjà pas mal.
[^] # Re: ha ?!??
Posté par ZeroHeure . Évalué à 1.
OpenSSh est effectivement un peu pourri dans la façon dont c'est codé. Par contre pour sendmail et bind, il semble que tu n'as jamais regardé et te bases uniquement sur les ragots. Ces deux projets sont extrèmement bien codés.
Ouaf ouaf ouaf !
Bon je ne vais pas argumenter sur la qualité du code, je n'en suis pas capable. Je mets ta phrase en gras, parce que tu reproches des "ragots" à Te bille pas Gates. Chacun argumentes comme il veux hein, mais cette phrase toute seule comme ça...
Je rigole là-haut, parce que j'ai passé quelques années à me débattre avec sendmail et bind sur mes serveurs. OK, ils sont bien codés puisque tu le dis, mais ça veut dire quoi? Ils sont bogués comme tous les softs, sauf que les bugs de ces deux là sont des nids à pirates. Moi j'en étais venu à considérer sendmail et bind comme dangereux (et pénibles).
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: ha ?!??
Posté par fabb . Évalué à 3.
Les sources sont dispos, alors fait un petit effort.
> Ils sont bogués comme tous les softs, sauf que les bugs de ces deux là sont des nids à pirates. Moi j'en étais venu à considérer sendmail et bind comme dangereux (et pénibles).
C'est marrant car les histoires où un serveur sendmail ou bind ont été cracké sont rares. Très rare alors qu'ils sont très utilisés et depuis très longtemps.
Tu t'es fait abusé par les ragots.
[^] # Re: ha ?!??
Posté par ZeroHeure . Évalué à 3.
je suis incapable d'évaluer le code. Je ne suis pa programmeur et ne connais qu'un peu de Perl.
Tu t'es fait abusé par les ragots.
?? Certainement pas.
J'ai vu des tas d'attaques sur mes serveurs DNS, tous régulièrement patchés heureusement (et c'était casse-pied!).
Je suppose ne pas être le seul à appliquer les correctifs: aucun hébergeur de site n'a envie de perdre des clients parce qu'un DNS n'a pas été patché à temps.
Quant aux serveurs crackés, dans les années 90 j'ai au contraire entendu ou été témoin de plusieurs histoire (Rapidsite a souvent été victime, mais il me semble aussi Jussieu, l'IN2P3, ... - je cite au hasard de ce qui me revient).
Cela dit, il y avait beaucoup plus de compromissions de serveurs web à cette époque (les failles ASP, FI/PHP, les extensions FrontPage, etc. ont fait la joie des pirates pendant des années). Je veux bien croire que le nombre de bind compromis paraisse faible en comparaison.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: ha ?!??
Posté par fabb . Évalué à 1.
Il y a plein d'attaque sur les serveurs apaches et ce n'est pas pour autant qu'apache n'est pas sûr.
> tous régulièrement patchés heureusement (et c'était casse-pied!).
Les distributions font ça. Pour bind et sendmail t'as une à deux mise à jours par an maxi en correction de sécurité.
[^] # Re: ha ?!??
Posté par Sayena Yefka . Évalué à 6.
en nombre de tetes, peut etre, mais en jour-homme je n'en suis pas si sur.
[^] # Re: ha ?!??
Posté par totof2000 . Évalué à 5.
Euh .... comment dire pour qu'on comprenne bien ce que je tente d'exprimer ... Côté doc utilisateur et pages de manuel, un Solaris est de par sa nature beaucoup plus cohérent et mieux fait qu'un linux, car Solaris est un tout tandis qu'un GNU/linux est un ensemble d'utilitaires d'origines différentes réunis en un seul package.
Pour comparer quelque chose de comparable, il faudrait comparer la doc xBSD et Solaris.
Pourtant une distribution GNU/Linux est composé à 99 % de logiciel libre minimum. Pourtant un distributeur GNU/Linux "enterprise" n'a pas l'infrastructure QA de Sun.
Ceci expliqiue peut-être celà ....
Cependant, je suis assez d'accord sur le fait que la documentation (pas les commentaires dans le code, mais une vraie doc de développement) font souvent défaut dans les logiciels libres. C'est dommage car je pense que certains projets pourraient 'décoller' si les développeurs faisaient une doc expliquant l'architecture de leur soft ...
Côté doc utilisateur, ca manque parfois aussi de cohérence ... Cependant, rédiger une doc technique compréhensible est un métier à part entière, et c'est certainement ca qui manque dans beaucoup de projets libres.
Compare le libre une fois filtré (par un distributeur) et le proprio (qui est filtré puisque pas toujours disponible).
cf le premier paragraphe de mon post. On trouve de tout des deux côtés. Certains soft proprios très mal documentés, certains softs propriétaires très bien documentés .... Je ne parle pas non plus des messages dans les boites de dialogue ni des docs en ligne directement traduites par un traducteur automatique (devinez à qui je pense ...).
[^] # Re: ha ?!??
Posté par reno . Évalué à 4.
Maintenant coté Solaris, il y a des choix qui sont politiques et indéfendables techniquement: utilisation de CDE (stable certe, mais qui est une grosse m...: c'est le seul soft ou certaines appli ne marchent pas en export DISPLAY!!!), remplacement d'outils utile par des javateries lentes et nettement moins utilisables (ce qui m'a conduit a apprendre les lignes de commandes équivalentes pour éviter d'utiliser cette saleté de console java).
Bref, grosso-modo ça se vaut, le coté le plus génant dans Linux, c'est la doc: c'est un gros bordel entre les docs en info qui sont franchement mauvaise (1 paragraphe par page en moyenne, outil de lecture pourri..) et des docs parfois inexistante (2 journée entieres passée sur le web pour trouver comment faire pour faire des accents avec un clavier QWERTY sans l'histoire de changement de clavier), c'est le plus gros manque: Solaris est livré avec des classeurs entiers de doc, un peu trop verbeuse a mon gout, mais nettement mieux quand même.
Ceci dit comme tous le monde le sait la doc de Linux est quand meme supèrieure a celle de Windows qui prend l'utilisateur pour un imbècile et n'apporte rien..
[^] # Re: ha ?!??
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
> accents avec un clavier QWERTY
Euh, là, a mon avis, c'est que tu sais pas chercher.
http://www.google.com/search?q=qwerty+accents+linux(...)
La première page donne quelque chose de satisfaisant, non ?
[^] # Re: ha ?!??
Posté par Nicolas Schoonbroodt . Évalué à 3.
Bien évidement, je ne suis qu'une personne, avec une expérience sur un seul "projet". J'ai écrit un petit plugin pour gaim permettant d'afficher du LaTeX (en envoyant du texte, l'image est crée sur l'ordinateur ou l'image est affichée). Cela correspond à un seul fichier de code de quelque chose comme 300 lignes. Je n'ai fait aucune publicité (surement un tord), je l'ai juste mis sur sourceforge, mais pourtant, j'ai recu l'aide de deux personnes qui se sont joint (ponctuellement) à moi. (la premiere ne compte pas, c'était un testeur, un ami à moi, mais il a contribué en commantant le code et en ajoutant un détail ou deux)
Par contre la deuxieme personne est un "parfait inconnu" américain, qui m'a envoyé un mail un jour me disant : votre plugin ne marche pas avec gaim 1.x.y. Effectivement, j'avait fait ce plugin pour moi, et je n'étais pas encore passé à gaim 1.x.y, je n'était (vraiment) pas à jour. Je met à jour, je vérifie, je voit que c'est vrai, je lui envoit un mail en lui précisant que j'essayerait de le faire, mais que je suis fort occupé. Je lui donne quand même un délai d'un mois maximum, je savais qu'il me suffirait d'une ou deux heure, que ca devait pouvoir le faire.
Deux jours plus tard, il m'a lui même envyé la version corrigée de mon fichier. (par ailleurs j'ai recu quelque mails de différentes origines me remerciant, et je doit dire que ca fait assez plaisir)
</ma vie>
Mais d'autre part, je suis très mal placé pour parler sur un sujet tel que la qualité du code des LL, vu que mon logiciel est tres mal codé. (je connait même une facon de faire planter l'application, à cause d'incompatibilités avec (au moins) un autre plugin) (j'ai à moitié l'excuse de ne pas être informaticien, mais je sais que je devrais au moins reprendre mon code et en faire quelque chose de mieux structuré)
PS : si vous voulez vraiment voir, c'est http://sourceforge.net/projects/gaim-latex(...) . Mais si vous êtes dévelloper, n'y allez pas, c'est vraiement très mal codé. Par ailleurs il existe au moins un autre projet faisant la même chose sous gaim/amsn/msn(windows)( http://www.student.cs.uwaterloo.ca/~kzorin/texim.html(...) ), un plugin officiel kopete, et un patch pour psi( http://psi.affinix.com/forums/index.php?act=ST&f=4&t=2317(...) ). (le tout avec des marquage des chaines en LaTeX de facon différente, pour faciliter la communication entre les différent clients)
[^] # Re: ha ?!??
Posté par rootix . Évalué à 3.
- les petits logiciels (donc des logiciels libres souvent) qui n'ont pas besoin de CVS et qui ne sont pas assez importants
- et les grands logiciels (libre et proprio) genre mozilla, openoffice, ms office,...
Il faut comparer les trucs de même taille sinon ça ne veut rien dire.
Je pense que les grands logiciels ont souvent une démarche qualité mais les proprio sont limités par la contrainte de temps.
[^] # Re: ha ?!??
Posté par Éric (site web personnel) . Évalué à 10.
Faudrait arrêter de croire que les gens qui ne sont pas de votre avis sont forcément payés, pro-MS, recoivent des pots de vin ou ont un intérêt personnel. C'est vraiment lourd ce genre de remarque dès que quelqu'un n'encense pas le libre.
> Franchement, là, je suis dégouté à la lecture de cette "news" partial
C'est dans la catégorie "humeur", c'est une opinion d'un auteur, personne n'a présenté ça autrement. C'est par principe totalement subjectif.
> et qui apparement ne vise qu'a déstabiliser l'essort actuel du libre,
Mais oui, son unique but c'est bien entendu de déstabiliser le libre. Tu imagines ? quelqu'un qui ne dit pas *que* du bien en parlant de libre ... c'est forcément une taupe qui n'est parmi nous que pour déstabiliser le mouvement. Parano quand tu nous tiens ...
[^] # Re: ha ?!??
Posté par calandoa . Évalué à 5.
Désolé de te contredire, mais il existe une grande partie des projets open source qui sont peu documentés. J'ai pu me plonger dans le code de WindowMaker récemment, et le nombre de commentaires dans le code était pratiquement inexistant. J'ai donc fait des petites statistiques vu que tu dis bien aimer les arguments étayés (à défaut d'en sortir) à coup de grep "//" et "/*" et de wc :
- WindowMaker : 2300 commentaires pour 56300 lignes de code
- Sylpheed : 3300 pour 105000
- aMule : 4300 pour 21500 (c'est mieux!)
- valgrind : 7000 pour 59000
- recode : 12000 pour 50300 (waw!)
- dillo : 2600 pour 34300
- doxygen 18500 pour 184000
Voilà. J'ai l'impression que tu te fais beaucoup d'idées sur les projets libres qui seraient tous bien documentés... Ah, et puis au passage, la news abordait le sujet de la validation des LL, pas vraiment le débat LL/LP... si tu es « dégoutté » par celle ci, c'est que tu as du la lire de travers...
[^] # Re: ha ?!??
Posté par Philippe F (site web personnel) . Évalué à 10.
Exemple:
/* we call this function to check for incorrect syntax */
check_string_1( s );
/* we call this function to check for wrong attributes references */
check_string_2( s );
A comparer a
check_string_for_bad_syntax( s );
check_string_for_wrong_attribute( s );
Je prefere nettement la seconde version, bien qu'elle soit moins commentee.
[^] # Re: ha ?!??
Posté par totof2000 . Évalué à 3.
[^] # Re: ha ?!??
Posté par briaeros007 . Évalué à 2.
Sur une fonction de 1 page dont on connais les e/s et on sait ce qu'elle est censee faire; c'est deja un peu plus dur de pas mettre des commentaires redondants (enfin c'est mon point de vue).
Et un commentaire style doxygen ca compte que comme un commentaire par fonction...
il y a un best practice qq part?
[^] # Re: ha ?!??
Posté par CS . Évalué à 9.
C'est incroyable cette manie qu'ont les intégristes du libre de se sentir agréssés dès que qqn ose émettre le moindre début de critique d'un truc concernant le libre. C'est pénible, même. Et en plus, a chaque fois on a droit à le même liste de lieux communs pour justifier la supériorité du libre.
Je ne vois pas en quoi cette news est une attaque. Il y a plein de problèmes liés au développement du libre, on les poses et on en discutes. Ce problème de qualité existe. On ne peut pas dire : "le libre c'est super stable et de super bonne qualité" et deux lignes plus loin : "parce que tous les utilisateurs testent". Ou alors il faut quand même avoir une sacré dose de mauvaise foi.
Cette news présente un début de reflexion partielle et lance un débat. Point. Pas la peine de s'outrer, mieux vaux répondre sur le fond.
Sur le fond d'ailleurs, mon opinion est qu'on doute régulièrement des qualités du libre quand on travail avec. Je travaille sur Moz, et je remplis le bugzilla depuis pas mal de temps, je me débat sans docs, et quefois j'en ai plein le cul, passez moi l'expression. Dans ces moments là, je me souviens du temps ou j'ai dû utilise PowerBuilder, logiciel propriétaire dont les caractéristiques étaient finalement encore pire. Ceci étant, quand j'utilise nautilus qui plante tous les 15 mouvemetns de fichier, je me dit que MS Windows a progressé un peu mieux quand même, puisque mon explorateur ne plant qu'une fois toutes les 2 ou trois semaines.
Ce que je pense de cette news est qu'elle est mal posée. Le libre n'a pas plus de problème de qualité que le proprio. Mais :
- dans le libre certains projets phare sont de mauvaise qualités et ça craint
- dans le libre, en tant qu'utilisateur, il faut lire les changelog et autres README pour mesure éventuellemetn la qualité de la version qu'on s'apprête à installer, pour être sûr que ce n'est pas une version de test, une RC, et au final on peut faire des boulettes pas drôle, et c'est un peu le bordel, ce qui n'est pas le cas avec le prroprio. C'est donc plus un problème de "distribution" que de développement.
[^] # Re: ha ?!??
Posté par Raphaël SurcouF (site web personnel) . Évalué à -1.
C'est dommage, ton commentaire allait bien jusque-là...
[^] # Re: ha ?!??
Posté par fabb . Évalué à 2.
On ne peut pas dire que le LL est mal testé ou n'a pas assez de démarche qualité en disant seulement que les tests unitaires c'est bien(tm).
Lorsqu'on critique le logiciel libre dans un domaine où il a bonne réputation, il faut des arguments.
> - dans le libre certains projets phare sont de mauvaise qualités et ça craint
Exemple ?
Nautilus ?
> - dans le libre, en tant qu'utilisateur, il faut lire les changelog et autres README pour mesure éventuellemetn la qualité de la version qu'on s'apprête à installer, pour être sûr que ce n'est pas une version de test, une RC, et au final on peut faire des boulettes pas drôle, et c'est un peu le bordel
C'est le LIBRE. Prends une distribution "entreprise" et ne te pose pas de question.
C'est dingue ça, les gens "gueules" car lorsqu'il récupérère le premier logiciel venu sur le net (gentiment contributé, gratuit, etc) il n'est pas à leur gout et il pense que ça leur donne le droit de critiquer le libre dans son ensemble.
[^] # Re: ha ?!??
Posté par Philippe F (site web personnel) . Évalué à 5.
> leur gout et il pense que ça leur donne le droit de critiquer le libre dans son ensemble.
Je fais du logiciel libre et j'accepte les critiques. Je ne comprends pas pourquoi il n'en irait pas de meme de mes pairs developpeur. Refuser la critique, c'est toujours une forme d'extremisme. Accepter la critique et dire "ta critique est infondee" ou "ta critique est fondee mais ca restera comme ca", c'est de l'ouverture d'esprit.
Un logiciel est un outil, quand l'outil est pourri, il est juste de le critiquer. Si tu vois le logiciel comme une oeuvre d'art qu'il ne faut jamais executer parce qu'il plante, libre a toi. Mais si tu vois le logiciel comme un outil, tu dois etre pret a accepter la notion de critique, independamment de la facon dont ce soft a ete developpe.
[^] # Re: ha ?!??
Posté par fabb . Évalué à 1.
Bravo.
> Je ne comprends pas pourquoi il n'en irait pas de meme de mes pairs developpeur.
Une critique avec des arguments d'accord. Mais là il n'y a rien ou presque. Il y a quelques personnes qui se plaignent de quelques bugs sur des applis mineurs et un bug dans gconf. C'est maigre.
Imaginons que tu développes pour KDE.
Imagines que je fasse une news avec :
1- KDE n'est pas aussi fiable qu'on le dit.
2- Gnome fait mieux.
3- KDE devrait avoir une démarche qualité éprouvée comme Gnome.
4- KDE ne devrait pas seulement compter que les utilisateurs pour faire les tests sinon KDE va avoir un retard insurmontable sur Gnome.
6- dejagnu
7- et définition de "test unitaire" pour les abrutis
Évidement tout ça sans le moindre argument si ce n'est une "impression générale".
Si t'apprécie ce genre de truc, très bien.
Moi pas.
[^] # Re: ha ?!??
Posté par mdlh . Évalué à 1.
Car une critique sans argument est peut-etre inutile (dans le sens inexploitable), mais peut malgre tout avoir bon fond. Simplement crier au troll c'est finalement penser que le contraire de ce qui est dit est vrai.
[^] # Re: ha ?!??
Posté par _gp . Évalué à 3.
Je ne me sens pas très loin d'une bureaucratie digne des plus belles heures de l'union soviétique :) Une insulae remplie de services redondants qui se contredisent souvent les uns les autres.
Bref, loin des " techniques ayant fait leurs preuves dans l'industrie"...
Je sais bien sûr que ce n'est pas la règle partout., mais ça se passe comme ça chez moi :)
# Ah oui mais...
Posté par l_arpenteur_k . Évalué à 10.
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 !
[^] # Re: Ah oui mais...
Posté par Philippe F (site web personnel) . Évalué à 10.
Ce que je partage avec l'auteur de cette news comme point de vue, c'est que les tests unitaires ne sont pas assez utilise en logiciel libre. C'est un tort car ca permet de faire evoluer tres rapidement l'architecture d'un logiciel tout en conservant sa qualite. Si je prends une appli comme grisbi, il y a eu des versions completement inutilisables tellement elles etaient buggees. Pourtant, c'est pas dur d'ecrire des tests unitaires pour les fonctionnalites qui posaient probleme.
Depuis que je suis devenu un integriste du test unitaire, je constate que j'ai beaucoup moins de bugs sur mes projets et qu'ils sont beaucoup plus faciles a faire evoluer. Constation corroboree par d'autres convertis du test unitaire.
Alors le test unitaire, mangez-en. On peut en faire en C (cunit), en C++ (cppunit), en pyton (unittest), en java (junit, easymock), et C#, en ruby et en tout ce que vous voulez. L'important est d'avoir une suite de test automatisee.
Le contre-argument classique est "mais on ne peut pas tester cette partie-la". Avec un peu d'astuce, on peut tout tester mais il faut s'en donner les moyens. Par exemple, j'ai peu tester un protocole de communication radio ou il fallait simuler des conditions radio anormales. Je travail aussi sur du code embarque ou il faut tester le comportement d'un programme compile avec de l'overlay (pas de notion de fonctionr re-entrante, les variables locales ne sont pas sur la piles mais a des emplacements fixes). Ca aussi, on a put tester sans probleme a condition de reflechir a la facon d'aborder le probleme.
Ce qui est genial, c'est qu'une fois que les briques de bases ont beaucoup de tests unitaires, c'est tres tres facile de faire des tests fonctionnels de tres haut niveau, en assemblant des briques de tests unitaires.
Par exemple, une fois que j'ai eu mon protocole de communication debugge, j'ai pu teste l'ensemble de mon programme avec introdution de conditions radio anormales et autres petits problemes. J"etais doublement confiant dans sa qualite.
[^] # Re: Ah oui mais...
Posté par fabb . Évalué à -1.
Faire une news :
- le libre devrait faire ci ou ça
est naze (surtout avec aussi peu d'argument). Le libre est libre. T'es libre de faire des tests unitaires et je le suis aussi et je ne m'en prive pas.
S'il avait fait un article sur les avantages du test unitaire ou de la méthodologie "bidule" et la conseillait aux développeurs libres ce serait beaucoup plus "accèptable". Mais là on apprend rien.
Pour revenir au test unitaire, il y a différente catégorie de test unitaire. Lorsque je fais une fonction par exemple, je fais un test unitaire assez exhautif avec gdb ou autre.
Mais je mets plus rarement en place un test unitaire automatisé pour un module.
À ça, une bonne raison :
- c'est parfois le bordel à réaliser et si on a pris soin dans les unitaires lors du développement, les choses se passent bien.
Je suis un "accros" des :
#ifdef DEBUG
assert (....)
#endif
Je teste ainsi pratiquement toutes les entrées de fonction. Si la fonction a été bien testé durant le développement, c'est une aide plus que précieuse.
[^] # Re: Ah oui mais...
Posté par Philippe F (site web personnel) . Évalué à 3.
Plus tu testes mieux ca se passe. Pour moi, il n'y a pas de bonne raison de ne pas tester un module que tu pourrais tester.
<<
Je suis un "accros" des :
#ifdef DEBUG
assert (....)
#endif
>>
Moi j'en suis parvenu a la conclusion qu'il n'y a pas de raison de supprimer les assert en mode release. L'overhead est completement negligeable.
D'ailleurs, tu peut deja t'epargner quelques lignes de code avec un:
#ifdef DEBUG
#define ASSERT( toto ) assert( toto )
#else
#define ASSERT( toto )
#endif
et utiliser ASSERT() partout.
Perso, je suis plus dans une optique d'utiliser des logs pour les assert, qui ne seront pas affiches par defaut en mode release mais que je peux activer a tout moment. Si un client a un probleme, je lui dis de lancer le soft en mode debug et de m'envoyer le log.
[^] # Re: Ah oui mais...
Posté par ookaze . Évalué à 6.
Je pense que l'exemple de gconf donné dans la "news" est très mauvais. En effet, si on lit l'évolution du bug, on ne fait pas le même constat que ce que je lis dans la news.
Dans le rapport de bug, moi je vois qu'un problème a été identifié il y a longtemps, mais qu'on n'en connaissait même pas la cause. Il a fallu du temps pour comprendre que cela venait de gconf.
Pire, le problème se trouvait au niveau des chemins créés. Il aurait donc fallu créer un test unitaire validant des chemins (en UTF8 en plus).
Je veux bien croire que personne n'ait eu le temps ou le courage de réaliser un test de cette envergure.
Tous les éléments sont en place pour trouver le bug, puis le corriger.
Le seul problème que je vois dans cet exemple, ce sont les ressources.
Et AMHA, c'est pareil pour la plupart des autres bugs.
A la limite, citer ce bug c'est bien, mais ça sert à rien maintenant qu'il est corrigé.
Une news intéressante aurait pu être de deux types :
- Montrer ce qu'il aurait fallu faire avec les méthodologies citées, pour corriger rapidement ce bug.
- Prendre un autre bug aussi difficile à trouver et non corrigé, et appliquer ces méthodes pour nous montrer leur efficacité.
Et là je serai convaincu, surtout si au final ça prend peu de ressources.
[^] # Re: Ah oui mais...
Posté par Lucas . Évalué à 3.
Si une suite de tests unitaires avait été développée en même temps que gconf, ce bug aurait peut-être été révélé par les tests. Après, il faut voir si le temps passé à développer les tests unitaires est inférieur au temps passé à chercher le bug. J'imagine que dans ce cas, ça aurait été rentable. Ce n'est pas toujours le cas.
Disclaimer : le but n'était bien sûr pas de dire que GNOME est pourri et tout buggé. GNOME comporte extrèmement peu de bugs, surtout lorsqu'on regarde la taille du projet ... Et les développeurs GNOME font en général du très bon boulot.
[^] # Re: Ah oui mais...
Posté par Philippe F (site web personnel) . Évalué à 4.
J'utilise des tests unitaires depuis 4 ans et je n'ai pas encore vu de situation ou des bugs seraient plus long a corriger qu'ecrire une suite de test unitaire.
Une suite de test unitaire apporte beaucoup de choses en terme de fiabilite. C'est un atout enorme pour la maintenance.
Il faut aussi voir que meme sans test unitaires, les developpeurs ont ecrits des tests pour leur code. La difference, c'est que ces tests ne sont pas automatises et ne sont pas archives. Ils sont perdu des que le code est ecrit
[^] # Re: Ah oui mais...
Posté par Sebastien . Évalué à 2.
Normalement, ton programme ne doit pas planter.
La programmation par contrat c'est bien (enfin je trouve que c'est bien), mais le end-user (il fallait que je case un buzzword ;) lorsqu'il se retrouve avec un programme qui plante avec un sybilin
__FILE__:__FUNCTION__:__LINE__ : assertion m_data.empty() failed
... ca lui fait une belle jambe.
Je prefere de loin gerer ca via un try/catch.
Mes 2 centimes.
[^] # (HS) Re: Ah oui mais...
Posté par scylla . Évalué à 2.
Gagne plein de lignes de code avec :
#ifndef DEBUG
#define NDEBUG
#endif
[^] # Re: (HS) Re: Ah oui mais...
Posté par zeSixty4Douille . Évalué à 0.
J'aime vraiment pas les ASSERT de partout aussi, ainsi que les tests redondant sur les pointeurs NULL.
Si un probleme peut intervernir dans ton code qui n'implique pas forcement un crash, alors la OK. Tu ne deposeras jamais une ligne de code dans le noyau comme cela.
[^] # Re: (HS) Re: Ah oui mais...
Posté par fabb . Évalué à 1.
Y en a. Pour info c'est "kernel panic".
[^] # Re: Ah oui mais...
Posté par TImaniac (site web personnel) . Évalué à 5.
Non, il y a pas 15000 façon de faire des tests unitaires.
Y'a ceux qui font des tests unitaires, cad :
- qui SEPARENT les tests des classes/modules
- qui tests individuellement chaque classe/module avec son jeu de test
- qui propose une syntaxe permettant de rejouer ces tests
(et ceux qui vont jusqu'au bout, cad qui réalise leurs tests avant d'écrire le code)
Et y'a ceux qui dont des tests divers et variés, qui le mettent dans le code, qui ne test riende façon "unitaire", qui croivent qu'un assert dans le code est un test unitaire (le test unitaire est celui qui lève éventuellement une pré/post condition (en posant éventuellement d'autres conditions, mais ce n'est pas la condition en soit).
Alors pitié, le #ifdef DEBUG ce n'est pas du test unitaire.
Je teste ainsi pratiquement toutes les entrées de fonction.
Ca c'est bien mais celà n'a strictement rien à voir avec les tests unitaires.
[^] # Re: Ah oui mais...
Posté par golum . Évalué à 1.
Tout a fait d'accord ,il s'agit d'assertion qui permettent de déceler des situations (hors contrat) exceptionnelles à l'execution. Ca relève plus de la programmation par contrat dont les principes ne s'appliquent pas qu'au seul langage eiffel
http://en.wikipedia.org/wiki/Design_by_contract(...)
Maintenant, je ne me souviens pas avoir vu de beaux trolls sur DLFP à propos de la guerre Design By contract vs Unit Testing vs Static Typing et leur utlisation conjointe.
Un remplacant au défunt QT vs GPL ?
---> []
[^] # Re: Ah oui mais...
Posté par Philippe F (site web personnel) . Évalué à 2.
[^] # Re: Ah oui mais...
Posté par golum . Évalué à 2.
Dans un développement logiciel itératif on peut distinguer (grossièrement) une phase de réalisation des composants et une phase d'assemblage (intégration) de ces composants
Durant la première phase:
Les contrats definissent des invariants qui doivent être respectés lors de l'execution.
Les tests unitaires se comportent alors un peu comme des "injecteurs " qui permettent de vérifier que les contrats sont respectés de façon (quasi) exhaustive.
Lors de l'assemblage, les contrats garantissent que les composant s'emboîtent correctement
Le tests unitaires servent de base de non regression pour les itérations suivantes.
[^] # tests unitaires itératifs pour déclencher des ruptures de contrat
Posté par free2.org . Évalué à 2.
Les tests unitaires sont simplement des itérateurs pour tester le maximum de valeurs possibles pour les parametres. A chaque itération il y a appel de la fonction avec de nouveaux parametres, et ce sont alors les assertions incluses dans cette fonction qui font l'essentiel du travail de test.
[^] # Intro aux tests logiciels
Posté par totof2000 . Évalué à 2.
C'est un cours sur ada, mais dans le cours ada 3, il y a une partie sur les tests logiciels. Très intéressant.
[^] # Re: Intro aux tests logiciels
Posté par Lucas . Évalué à 2.
[^] # Re: Ah oui mais...
Posté par totof2000 . Évalué à 2.
[^] # Re: Ah oui mais...
Posté par l_arpenteur_k . Évalué à 2.
[^] # Re: Ah oui mais...
Posté par erik_lallemand . Évalué à 3.
On se la joue facon "jeu du pendu"? Est-ce que ca pourrait ressembler à:
P e _ _ _ e S _ f _
???
# d'une extrêmité à l'autre...
Posté par Jean Roc Morreale . Évalué à 10.
Généralités et lieux communs, bonjour !
[^] # Re: d'une extrêmité à l'autre...
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
De la façon dont il est rédigé, cet article est appel au troll. Au lieu de dire : "Cette idée répandue est généralement fausse.", il aurait mieux valu écrire :
"Cette idée n'est pas toujours vraie".
La gestion de la qualité est un souci majeur pour les logiciels libres et malgré l'aspect trollesque de l'article, les relecteurs et modérateurs l'ont mis en page principale car il est bon de revenir périodiquement sur le sujet.
La seule certitude, c'est qu'il reviendra éternellement. Les excès aussi, car il est difficile de quantifier la Qualité.
[^] # Re: d'une extrêmité à l'autre...
Posté par Anonyme . Évalué à 4.
Pour en revenir au sujet central : li'dée répandue (et fausse) est bien que "les logiciels libres sont de qualité supérieure grâce à leur énorme base d'utilisateurs-testeurs". C'est ce qui est évoqué dans La cathédrale et le bazar mais ça ne se vérifie que rarement, généralement sur les gros projets. Et encore, des méthodes éprouvées comme les tests unitaires apportent au moins autant de bénéfices. Peut-être que ce qui te choque le plus est l'évocation de logiciel propriétaire ?
[^] # Re: d'une extrêmité à l'autre...
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
# Un choix perso
Posté par TeXitoi (site web personnel) . Évalué à 2.
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 . Évalué à 9.
Voilà avec quoi peuvent être faits les tests en Java :
http://dmoz.org/Computers/Programming/Languages/Java/Development_To(...)
[^] # Re: Et Java
Posté par Xavier Poinsard . Évalué à 2.
il utilise JUnit pour avoir une batteries de tests qui combinés avec Ant permettent de tester la non-régression aussi facilement que de compiler.
# De la criticité des bugs
Posté par Florimond S. (site web personnel) . Évalué à 7.
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".
[^] # Re: De la criticité des bugs
Posté par M . Évalué à 4.
Qu'est ce que t'en sais ? Tout les users ne font pas des bugreports et peut etre qui a eu des consequences ailleurs.
De plus ce raisonnement tiens la route pour pour de la burautique, mais va dire ca a quelqu'un qui veut utiliser du linux dans du critique (embaque, gestion de donne, ...) Et puis tous les utilisateurs veullement jouer le moins possible a debugger.
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 ?
rapidement : http://bugzilla.gnome.org/show_bug.cgi?id=131381a(...) par exemple plus d'un an pour rester sur gnome. Je ne parle meme par du bugzilla du kernel dont certains reports n'ont aucun retour...
[^] # Re: De la criticité des bugs
Posté par Croconux . Évalué à 10.
Je pertinente. Je fais face à ça tous les jours au boulot : Des clients qui demandent des features à la con qui n'intéressent personne et que personne n'utilisera. Le pire c'est qu'on le voit venir ! On sent les fonctionnalités qui vont intéresser 2 pèlerins. Mais c'est "capital pour le client". Le client "n'acceptera pas le produit sans ça". Et régulièrement quand on tombe sur des fonctionnalités cassées, en regardant les archivages dans CVS on se rends compte que c'est comme ça depuis 6 mois. Donc personne n'a pu s'en servir et ça n'a gêné personne. L'origine du problème est que ceux qui réclament des fonctionnalités et ceux qui les utilisent ne sont pas les mêmes personnes. Coté client celui qui signe le chèque est souvent un advanced user (certains diraont un chieur) qui croit savoir ce dont les gens de sa boite ont besoin et qui demande des trucs super compliqués. Les utilisateurs, eux, ne demandent souvent pas grand chose et utilisent les fonctionnalités de base.
[^] # Re: De la criticité des bugs
Posté par Philippe F (site web personnel) . Évalué à 6.
Bah, les developpeurs s'en foutent. Pourtant le bugs a pas mal de votes, et j'ai rencontre plein de gens interesses par la fonctionnalite.
Au final, si personne ne veux corriger un probleme, il ne sera pas corrige. Le developpeur ne considere que ce n'est pas important et puis voila.
[^] # Re: De la criticité des bugs
Posté par reno . Évalué à 3.
Alors dans le logiciel propriétaire, même quand on peut voter pour des bugs, cela n'est pas forcément mieux.
# Appréciation des langages
Posté par Veiovis . Évalué à 0.
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 (site web personnel) . Évalué à 4.
# balle en argent
Posté par Antoine . Évalué à 8.
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 . Évalué à 8.
- 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.
[^] # Re: Je ne suis pas d'accord
Posté par fabb . Évalué à 3.
Pas d'accord. Je vais du test unitaire pour toutes les "unités" que je viens de faire. Quelles fasses 20 lignes ou 20 000 lignes.
[^] # Re: Je ne suis pas d'accord
Posté par Xavier . Évalué à 3.
J'ai toujours pu trouver des solutions à mes problèmes, que ce soit au niveau de l'os ou des applications dans les LL grâce à la richesse des informations disponibles.
My2 Icleandic Krona...
[^] # Re: Je ne suis pas d'accord
Posté par fabien . Évalué à 2.
hum, il me semble qu'il à ecrit en bon francais : " Dans le monde du Libre, deux comportements sont fréquents parmi les développeurs"
Il n'as pas dis "il n'y a QUE des hardcore et extremiste"
Ensuite, on peut diserter sur le "sont frequent",
par forcement dans de gros projet (kernel... OOo...)
mais il y a plein plein de projet dans le libre,
et beaucoups d'entre eux ne sont maintenu que par une seule personne (voir deux)... ca arrive tres souvant, en particulier avant que le projet ne soit tres connu... et là, ben ca arrive que ca soit codé sans commentaire/tests....
Donc, sur cette phrase, c'est pas faux ce qu'il écrit ;)
[^] # Re: Je ne suis pas d'accord
Posté par Lucas . Évalué à 2.
Bon, ok, si, quand même ...
-->[]
# ???
Posté par fabb . Évalué à 8.
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.
[^] # Re: ???
Posté par Robert VISEUR (site web personnel) . Évalué à 2.
Tu as des sources sur ce point ?
[^] # Re: ???
Posté par Lucas . Évalué à 2.
Apparemment Bull bosse sur ce genre de projets. Liens :
http://nfsv4.bullopensource.org/tools/testing_tools.html(...)
http://ltp.sourceforge.net/(...)
Mais ca se limite à un projet phare (Linux), et ca n'est pas vraiment représentatif de l'ensemble des LL.
[^] # Re: ???
Posté par fabb . Évalué à 2.
http://www.osdl.org/lab_activities/kernel_testing/(...)
Il y a Andrew et Linux qui c'étaient exprimés sur ça dans une interview que j'ai perdu. En gros, ils ne sont pas contre mais ce n'est pas le coeur de leur démarche qualité.
Linus insiste toujours sur le code. Par exemple il n'est pas emballé par les débuggueur.
[^] # Re: ???
Posté par Philippe F (site web personnel) . Évalué à 4.
Et tu n'a jamais de coup de fatigue ? De faute d'inattention ? D'erreur de frappe (oh, j'ai mis == eu lieu de =) ?
> Plus sérieusement, les tests ne sont qu'une toute petite partie d'un processus qualité global.
Alors la, je ne suis pas tu tout d'accord. Bien sur, une bonne conception est essentielle, mais une bonne conception ne va apporter que des garanties de bon fonctionnement globaux (le logiciel pourra faire X ou Y). Il y a toujours un moment ou tu codes et le [1] _seul_ moyen de valider du code, c'est des tests unitaires.
Donc les tests sont une partie essentielle et fondamentale du processus qualite.
Tu peux avoir une conception magnifique UML et tout le bazar, et un logiciel code comme les pieds qui plante toutes les 10 secondes. Oui, la conception etait bonne, mais l'implementation etait a chier.
<<
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.
>>
La, tu dis n'importe quoi. Tu assimiles erreur de conception et bug.
Un bug, c'est une fonctionnalite avec une erreur (= a la place de ==). Dans une bonne approche ou tu codes tes tests avant ou pendant que tu codes tes fonctionnalites, un bug a un cout de correction extremement faible. Tu es dans le code, tu vois tout de suite ce qui ne va pas, personne n'est impacte en dehors de toi, et tu corriges dans la minute ou dans la journee.
Au fur a mesure que tu avances dans la phase de vie du produit, un bug a un cout de correction exponentiel. Sur un produit deja sorti, c'est dramatique.
Je ne sais pas ou tu as vu qu'un bug decouvert en phase de test coutait cher, mais c'est n'importe quoi.
Une erreur de conception en revanche, ca coute tres cher, je suis d'accord. Mais l'avantage des tests unitaires, c'est que ca te permet de corriger ce type d'erreur a moindre cout. En effet, une erreur de conception te conduit a refaire l'architecture de ton soft. Et la, tu sors ta batterie de 300 tests unitaires qui marchait avec l'ancienne architecture. Tu la valides avec la nouvelle acrchitecture et tu es sur que tu n'as perdu aucune fcontionnalite ni introduit aucun nouveau bug. Des certitudes comme ca, ca n'a pas de prix.
1] je sens qu'on va me parler de preuve formelle. Aller, combien d'entre vous savent faire de la preuve formelle sur un logiciel ? Combien ont vu des logiciels libres avec des preuves formelles ? Connaissez vous le cout de mise en place d'une preuve formelle ? La preuve formelle, c'est super mais en pratique, pour des logiciels a la con, c'est pas la panacee.
[^] # Re: ???
Posté par fabb . Évalué à 2.
En phase de test ça coute cher car la phase de test (je ne parle pas de test unitaire) peut venir bien après la phase de développement. Donc le développeur il ne sait plus exactement ce qu'il a fait et si c'est un projet sur plusieurs mois/années il est même possible que le développeur qui a fait une code/module coupable ne soit plus disponible.
> Une erreur de conception en revanche, ca coute tres cher, je suis d'accord.
Idem pour un bug. Mais pour un bug c'est moins cher.
Pour les bugs "=" à la place de "==" c'est vraiment "petit". Il y a des bugs où il faut réécrire plusieurs centaines de lignes de code même si la conception est parfaite.
[^] # Re: ???
Posté par Philippe F (site web personnel) . Évalué à 2.
> (je ne parle pas de test unitaire)
Dans ce cas precise. Dans la plupart des projets, la phase de test fonctionelle et l'integration sont faites a la fin. C'est aussi une erreur qu'il faut essayer de corriger, meme si ce n'est pas toujours facile (pour la phase d'integration).
Sans meme faire reference a XP, toutes les methodes de developpement recommandent de faire des phases de tests intermediaires (water fall, cycles en plusieurs V).
Donc on peut reformuler ta phrase "dans le cas ou un projet ne respecte aucune methodologie qualite et fait des tests 3 ans apres le dev, on sait depuis tres longtemp qu'un bug decouvert en phase de test coute tres cher".
Ce qu'on sait surtout depuis tres longtemps, c'est que plus ton bug est decouvert tard, plus il coute cher. Donc il faut tester tres tot et plutot que de sortir une anerie pour decredibiliser les tests (les bugs decouverts en phase de test coutent cher), je pense que tu devrais integrer cette notion de tester le plus tot possible dans une demarche de qualite globale (qui va avec la demarche de bonne conception que tu sembles deja preconiser).
Et comme je l'ai deja dit, une fois que tu as beaucoup de tests unitaires, il est tres facile de monter des tests fonctionnels qui s'appuient sur ces tests unitaires, donc de lancer des tests fonctionnels tres tot sur le projet
[^] # Re: ???
Posté par fabb . Évalué à 2.
Mais ça arrive. Je l'ai vécu et ce n'est pas du suicide.
Puis les tests unitaires quand t'as 300 paramètres d'exécutions et tu dépends d'un automate qui t'envois 200 autres paramètres,etc c'est impossible à réaliser. Au mieux tu couvres quelques cas d'utilisations en lancant des tests qui représentent des utilisations "typiques". Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
> Donc on peut reformuler ta phrase "dans le cas ou un projet ne respecte aucune methodologie qualite et fait des tests 3 ans apres le dev, on sait depuis tres longtemp qu'un bug decouvert en phase de test coute tres cher".
Dans certain cas tu n'as pas le choix. Une équipe développe l'applis, une autre bosse sur un automate qui va utiliser des appareils à plusieurs millions d'euro qui sera disponible que lorsque les développements sont terminés.
Certe tu peux toujours faire des tests unitaires etc. Mais je ne me vois pas demander au boss d'avoir 6 mois de plus pour faire des tests unitaires exautifs sans que ça apporte un réel intérêt.
Dans ces cas, il faut s'appuier sur une bonne architecture. Il faut alors que les éléments critiques soient simples. Ainsi tu peux "blinder" les tests unitaires et faire des tests exautifs sur les éléments critiques.
J'utilise les tests unitaires. Mais les tests unitaire systématique et pour tout c'est l'enfer.
"Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Je te donne une mission :
- Faire un (ou des) test unitaire complet pour gecko
Combien de temps il te faut ?
Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Une fois que tu as évaluer les ressources nécessaires interroges si un développeur de plus uniquement pour faire de l'audit de code n'est pas un meilleur investissement.
> Donc il faut tester tres tot et plutot que de sortir une anerie pour decredibiliser les tests (les bugs decouverts en phase de test coutent cher)
Tu le fais exprès ?
Si je fais un module et que je le teste dans la semaine il n'y effectivement pas de problème pour corriger les bugs. Mais parfois un module développé n'est utilisé que bien des mois après.
Si les tests ont été exautifs (impossible sauf pour des trucs simples) il n'y a effectivement pas de problème. Mais suppose que les formats d'entrés aient légèrement changé et que lors des tests (pas des tests unitaires) ça plante un module développé il y a quelque mois. Ces "bricoles" ça arrive.
Ça arrive car les tests peuvent être erronés ou incomplet, car il y a eu un manque communication lors de l'évolution d'un module, etc.
C'est _courrant_.
Toi t'es dans le rève ou il n'y a pas d'erreurs de conception, il n'y a pas de manque de communication, le projet est parfaitement géré, les tests sont tous exautifs et parfait, les spécifications sont complètes et n'ont raté aucuns scénarios, etc.
Voilà pour ton rève.
Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Dans la "vraie vie" ça ne se passe pas comme ça.
> je pense que tu devrais integrer cette notion de tester le plus tot possible dans une demarche de qualite globale
T'es gentil.
Mais je vais te montrer un cas "spécial" et qui va te montrer que je ne suis pas contre les tests unitaires lorsque ça a un sens.
J'avais un projet sur 8 mois et ça me semblait impossible à tenir (je n'étais pas le seul à le penser). Heureusement tous les données étaient disponibles (ficher de test, moyen pour les générer, etc).
J'ai fait la conception du programme sur papier.
J'ai réalisé les procedures de tests exautives (car c'était possible et ça permettait aussi de faire le recette auprès du client).
J'ai fait validé les procédures de tests par le client.
J'ai réalisé les fichiers .h.
J'ai fait audité la conception et les fichiers .h.
J'ai "pissé" du code durant 6 mois sans rien compiler/exécuter ! Le code était blindé d'assert.
J'était en retard sur le planning car les 8 mois était écoulé. J'ai compilé, corrigé les tonnes d'erreur de syntaxe, etc qui restait.
J'ai exécuté. Corrigé les cas où le programme plantait sur les asserts.
J'ai passé les tests exautifs, corrigé les bugs. L'applis a été recetté par le client. Retard : 15 jours. Le client ne s'est jamais plaint d'un bug. Tous les tests ont été réalisés à la *fin* car pour *ce* projet c'était une bonne méthode.
Il n'y a pas de démarche qualité universel et il faut bien faire avec les ressources disponibles.
[^] # Re: ???
Posté par pasBill pasGates . Évalué à 5.
C'est peut-etre pas du suicide mais c'est une grosse connerie inefficace.
Puis les tests unitaires quand t'as 300 paramètres d'exécutions et tu dépends d'un automate qui t'envois 200 autres paramètres,etc c'est impossible à réaliser. Au mieux tu couvres quelques cas d'utilisations en lancant des tests qui représentent des utilisations "typiques". Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
Alors c'est quoi la solution ? Ne rien tester car on ne peut pas tout tester ? Tu crois qu'ils font ca de cette maniere sur les systemes critiques d'Ariane et autres ?
J'utilise les tests unitaires. Mais les tests unitaire systématique et pour tout c'est l'enfer.
"Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Niveau grosses applis je crois que chez MS on connait, et les tests unitaires sont la.
Combien de temps il te faut ?
Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Une fois que tu as évaluer les ressources nécessaires interroges si un développeur de plus uniquement pour faire de l'audit de code n'est pas un meilleur investissement.
Moi je te donnes deja la reponse :
a) Ca prend du temps
b) C'est bcp plus efficace qu'avoir un gars qui audite le code, auditer le code ne te donne pas la possibilite de resoudre les scenarios bases sur du multithreading pousse par exemple ou sur des cas de ressources limitees, car souvent trop complexe a analyser par un etre humain
c) Un audit de code ne te permet pas de confirmer que ton code fonctionne comme prevu, seul un test du code en question le permet
Mais suppose que les formats d'entrés aient légèrement changé et que lors des tests (pas des tests unitaires) ça plante un module développé il y a quelque mois. Ces "bricoles" ça arrive.
Ben tant mieux, c'est pour ca que le test a ete cree. Si les formats ont ete changes volontairement, il faut alors modifier le test.
Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Dans la "vraie vie" ça ne se passe pas comme ça.
Mon petit doigt me dit que ta vraie vie ne correspond pas du tout a la mienne, ni a celle de mes 25'000 collegues ici ni a celle de Philippe. C'est de cette maniere que les plus gros softs de la planete(y compris non-MS) sont developpes, et il y a une raison pour cela : c'est plus efficace.
[^] # Re: ???
Posté par fabb . Évalué à -5.
Fermes ta gueule.
Je n'ai pas dit que je ne testait jamais, je n'ai jamais dit de ne jamais faire de test unitaire.
Je teste et je fais aussi des tests unitaires.
> C'est de cette maniere que les plus gros softs de la planete(y compris non-MS) sont developpes, et il y a une raison pour cela : c'est plus efficace.
J'oubliais que MS est particuliairement brillant en terme de qualité et qu'il faut copier ses méthodes.
Si c'est parfait chez MS, pourquoi il y a tant de bug dans MS-Office et IE ?
Pourquoi leurs supers procédures qui roxent le marketing laissent passer des trous de sécurité béants à tour de bras ?
Si les tests unitaires et tout le "coincoin" déployé chez MS est indispensable pour un minimum qualité (selon toi), expliques comment fait Mozilla, KDE, Linux, etc qui ne font pas tous ces "tests unitaires et tout le "coincoin" déployé chez MS" ?
Merci pour les leçons, mais tu repasseras plus tard.
[^] # Re: ???
Posté par pasBill pasGates . Évalué à 6.
Enchante, moi c'est pasbill
J'oubliais que MS est particuliairement brillant en terme de qualité et qu'il faut copier ses méthodes.
Si c'est parfait chez MS, pourquoi il y a tant de bug dans MS-Office et IE ?
Des bugs il y en a, et je suis pas convaincu du tout qu'il y en a plus qu'ailleurs, specialement dans Office compare a OpenOffice.
Pourquoi leurs supers procédures qui roxent le marketing laissent passer des trous de sécurité béants à tour de bras ?
A tours de bras ? ah bon, j'en vois pas bcp sur WS03 par exemple. C'est dingue non ? Plus les procedures de tests s'ameliorent, moins il y a de bugs(NT4->W2K->WS03), plein de bugs trouves sur NT4/W2K voire meme XP n'affectent pas WS03 car il a subi des tests plus evolues et pousses.
Si les tests unitaires et tout le "coincoin" déployé chez MS est indispensable pour un minimum qualité (selon toi), expliques comment fait Mozilla, KDE, Linux, etc qui ne font pas tous ces "tests unitaires et tout le "coincoin" déployé chez MS" ?
Pas besoin de l'expliquer, plus Linux, KDE, Mozilla,... sont utilises plus on trouve de bugs(securite ou pas), original non ?
Je suis tres tres tres loin d'etre convaincu que ces projets libres ont moins de bugs que le code des dernieres versions de Windows.
Merci pour les leçons, mais tu repasseras plus tard.
Ah le coup de l'autruche... Tes critiques envers MS ne changent pas le fait que toute l'industrie du soft fonctionne de cette maniere, et il y a une raison a cela.
[^] # Re: ???
Posté par Philippe F (site web personnel) . Évalué à 4.
> tu dépends d'un automate qui t'envois 200 autres paramètres,etc
Je doute que tu arrives a gerer tes 300 parametres et tes 200 autres avec une seule fonction. Tu as forcement un decoupage du travail qui t'oblige a separer les taches. Une fois que tu as isole les taches, tu peux les tester individuellement.
> Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
En general c'est mieux d'avoir un simulateur sous la main, pour reproduire les cas pourris. J'en ai rarement vu dans le libre malheureusement.
> Dans certain cas tu n'as pas le choix. Une équipe développe l'applis, une autre bosse sur un automate qui va utiliser des
> appareils à plusieurs millions d'euro qui sera disponible que lorsque les développements sont terminés.
Parce que ca vaut plusieurs millions d'euro, tu crois qu'on ne peut pas faire de test ? Ou bien que je vais me dire "la vache, si ca vaut aussi cher, vaut mieux ne pas tester" ? Ton appareil, il a des entrees/sorties qui sont specifiees. Ben tu les utilises pour tes tests.
Tout ce qui a une api peut avoir un test.
> Mais je ne me vois pas demander au boss d'avoir 6 mois de plus
> pour faire des tests unitaires exautifs sans que ça apporte un réel intérêt.
Affabulation. Faire des tests unitaire te fait gagner du temps. Pas le jour ou tu les ecris, mais 6 mois plus tard, quand tu dois modifier le code que tu as ecrit. Tu es bien content de ne pas faire un audit complet de ton code pour verifier que le bug X n'a pas pete ton produit. Tu fais retourner ta suite de test, et hop, tu es tranquil. Les endroits ou ton produit est pete sont clairement isole.
Les tests unitaires, c'est une machine a gagner du temps. Je suis d'accord que c'est contre-intuitif comme idee, mais c'est vraiment le cas dans la pratique.
> Il faut alors que les éléments critiques soient simples.
C'est en effet la caracteristique d'une conception robuste.
> Ainsi tu peux "blinder" les tests unitaires et faire des tests exautifs sur les éléments critiques.
Ah, tu vois qu'on se comprend finalement.
> "Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Je ne suis pas d'accord. Pour tout projet de plus d'une heure, les tests unitaires te feront gagner du temps. Pour un projet typique, on code 80% du projet en 20% du temps. Les 20% restants sont les plus durs: bugs d'integration, ajustement de la conception, ...
Avec des tests unitaires, t'as plutot une progression lineaire de facteur 1: 20% du temps, 20% du projet. 50% du temps, 50% du projet. Evidemment, vous ne regardez que les 20 premiers % en disant "putain, je pourrai deja en etre a 80% et je n'en suis qu'a 20%". Mais au final, les dernier % sont torches a vitesse grand V. Tu peux meme te permettre de faire des changements majeurs dans le projet dans la phase finale pour integrer la derniere idee du mec marketing, sans avoir peur de miner ton produit. Alors qu'en general, les devs ne veulent plus toucher a rien dans la phase finale, parce qu'ils ont eu trop de bugs d'integration.
> - Faire un (ou des) test unitaire complet pour gecko
Comme je l'ai deja dit, les developpeurs de gecko font deja leurs tests. Ils ont plein de bouts de code qu'ils utilisent pendant leur dev. Seulement des qu'ils estiment que ca marche, au lieu d'integrer ces bouts de code dans une suite de non-regression, ils jettent.
C'est la qu'on perd du temps. Des choses qui sont developpees mais pas integree au produit. C'est sur que rajouter les tests apres, c'est tres difficile et tres couteux.
> Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Beaucoup moins que pour corriger les bugs de non- regression, pour relire le code et se prendre la tete a essayer de comprendre pourquoi la foncttion X est comme ca sans avoir le test qui explique et qui valide son comportement.
Il est evident cependant que les tests evoluent avec le soft. Mais c'est une bonne chose.
> Une fois que tu as évaluer les ressources nécessaires interroges si un développeur de plus uniquement pour faire
> de l'audit de code n'est pas un meilleur investissement.
Moi je m'interroge en terme de certitude.
- un developpeur qui audite le code: "je pense que ca marche"
- un test unitaire qui valide le code: "je suis sur que ca marche".
Il n'y a pas photo, je prend la 2e option.
> Mais parfois un module développé n'est utilisé que bien des mois après. [...] Mais suppose que les formats d'entrés aient légèrement
> changé et que lors des tests (pas des tests unitaires) ça plante un module développé il y a quelque mois. Ces "bricoles" ça arrive.
Non ? Tu m'apprend quelque chose, je croyais que tout marchait tout seul et que les tests ne servait qu'a valider la perfection du code que ton cerveau surpuissant avait deja garanti de toute facon.
Mais bien sur que ca arrive ! Et bien tu fais evoluer tes tests, en meme temps que ton module. Un principe de codage fondamental de XP, c'est "on ne code qqch qu'une seule fois". Si ton format change, tu modifies la fonction de lecture du format et le test correspondant. Hop. Si ta representaiton interne doit changer aussi, ben pareil, tu modifies les deux. Une fois que tu as fait ca, tu verifies que tous les modules affectes indirectement par tes changements fonctionnent encore. Tu fais un audit rapide de ta couverture de test sur ces modules. Si elle est bonne, voila, tu t'es economise quelques jours de prise de tete d'audit de tous les modules qui utilisaient ton code.
> Ça arrive car les tests peuvent être erronés ou incomplet, car il y a eu un manque communication lors de l'évolution d'un module, etc.
Bien sur, ca arrive tous les jours. Mais les tests ne sont pas graves dans la pierre, ils evoluent en meme temps que ton programme te que tes specs.
> Toi t'es dans le rève ou il n'y a pas d'erreurs de conception,
Pas du tout. Je passe meme une grande partie de mon temps a corriger mes erreurs de conception en faisant evoluer mes tests. Le fait d'etre un mauvais concepteur ne me gene pas, car j'ai de bonnes suites de tests.
> il n'y a pas de manque de communication, le projet est parfaitement géré, les tests sont tous exautifs et parfait, les
> spécifications sont complètes et n'ont raté aucuns scénarios, etc.
Si c'etait ca, je n'aurai pas besoin d'ecrire des tests. Au contraire, les tests m'aident a gerer tous les problemes classiques d'un projet de facon beaucoup plus zen:
- spec qui evolue => je fais evoluer mes tests
- module non encore dispo => je fais des tests et un simulateur pour le remplacer
- bug a la con decouvert => je fais un test pour encadrer le bug et je cherche tous ses cousins possibles, puis je corrige
- probleme d 'integration dans un autre module, on ne sait pas d'ou vient le probleme => je montre mes suites de test a l'autre developpeur, qui est ensuite convaincu que le probleme vient de son cote
- procedure ISO a suivre pour la validation des specs => j'associe a chaque fonctionnalite un test et mon rapport de test devient ma doc de validation
- je trouve un module super difficile a developper et a tester => c'est un signe de mauvaise conception, je le decoupe jusqu'a pouvoir le tester facilement
- on me dit que a la convergence de trois conditions tres tres rares, le soft ne marche pas => je modifie mon simulateur (pratique de l'avoir developpe avant) pour inclure ces conditions tres tres rares.
etc etc.
Les tests unitaires, c'est vraiment une methodologie de developpement qui me permet d'etre super zen dans ce que je fais et de gerer tous les problemes quotidiens avec du recul.
> Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Mon cauchemard, c'est les developpeurs qui pensent que leur cerveau demesure ne pond que du code correct.
Perso, je suis modeste et pessimiste. Je pense que le code que j'ecris ne marche pas. Alors, je cherche des preuves.
> Mais je vais te montrer un cas "spécial" et qui va te montrer que je ne suis pas contre les tests unitaires lorsque ça a un sens.
De fait, si tu les as utilise et que tu as vu leur valeur, je ne comprends pas pourquoi tu me critiques de facon aussi acharnee.
> J'ai réalisé les procedures de tests exautives (car c'était possible et ça permettait aussi de faire le recette auprès du client).
Ca rejoint ce que je disais sur la valeur des tests. Ca sert plus qu'au developpeur.
> Retard : 15 jours.
Chapeau!
> Le client ne s'est jamais plaint d'un bug.
C'est la caracteristique d'un programme avec de bons tests unitaires. Tres peu de bugs.
> Tous les tests ont été réalisés à la *fin* car pour *ce* projet c'était une bonne méthode.
Je pense que tu as pris des risques sur ton projet, que tu mesurais de facon consciente. Il aurait pu t'arriver des problemes, genre le client reviens au bout de 4 mois : "donnez nous ce que vous avez fait , et on arrete le projet. Puisque ca fait 4 mois que vous avez commence, vous en etes a la moitie. On paiera que pour ce qui marche uniquement".
Mais je ne critique pas ta demarche. C'est bien que tu aies reussie a faire ce qui paraissait impossible.
[^] # Re: ???
Posté par fabb . Évalué à 1.
D'ailleur j'ai fais un simulateur (sommaire) pour l'applis dont je parle. Ça simulait l'automate et le "truc" très cher. Pratique pour tracker les bugs et bosser avec le client.
> Parce que ca vaut plusieurs millions d'euro, tu crois qu'on ne peut pas faire de test ?
Il y avait trois fournisseurs :
- l'appli (ma boîte)
- l'automate (une autre boîte)
- le "truc" très cher (un autre boîte)
Ma boîte se s'occupait pas de tout. On a un budget (qui n'est pas de plusieurs millions d'Euro), il faut faire avec.
> Ah, tu vois qu'on se comprend finalement.
Je n'ai JAMAIS dit que j'était contre les tests (unitaire ou pas) et j'ai déjà dit 50 fois que je fais aussi des tests unitaires. Mais pas systématiquement.
> - un test unitaire qui valide le code: "je suis sur que ca marche".
Alors là tu rève (en tout cas pour les modules compliqués). Un test unitaire teste les scénarios que tu as prévus. Pas forcément ce qui arrive dans la réalité.
> De fait, si tu les as utilise et que tu as vu leur valeur, je ne comprends pas pourquoi tu me critiques de facon aussi acharnee.
CAR CE N'EST PAS LA PANACÉ TOUT LE TEMPS !!!
Tu milites pour des tests unitaire partout et tout le temps car selon toi c'est LA méthode qui permet d'assurer la qualité alors que c'est seulement une méthode parmis d'autre.
Linux marche bien sans test unitaire (ou très peu). J'imagine déjà que tu vas dire que si Linux utilisait plus les tests unitaires il serait encore "plus mieux bien", les développements iraient plus vite, et au aurait allégé le noyau en virant le fichier kernel/panic.c car devenu inutile.
[^] # Re: ???
Posté par Pooly (site web personnel) . Évalué à 2.
dans la tienne en tout cas.... (ca m'énerve ces gens qui généralisent...)
[^] # Re: ???
Posté par Dring . Évalué à 1.
Je rajouterais que si c'est découvert bien après le début des tests, la correction peut entraîner le redémarrage complet de la phase de test. D'où un surcoût énorme par rapport à une découverte en phase de développement.
[^] # Re: ???
Posté par pasBill pasGates . Évalué à 3.
[^] # Re: ???
Posté par zeSixty4Douille . Évalué à -1.
L'"article" confond facilite de pisser des tests de regression pour plaire a son manager avec savoir deboguer efficacement son code / communiquer sur les problemes en cours.
De meme, on peut comparer 105 ans la doc de Trolltech a celle de MSN, mais franchement je vois pas le rapport avec la qualite. Quand des dev cherchent une info, ils la cherchent dans les headers des lib la plupart du temps.
P. S. : j'ai rien contre les tests de regression. Mais je prefere un petit bug un peu genant plutot qu'un gros fixe crasseux.
[^] # Re: ???
Posté par Philippe F (site web personnel) . Évalué à 2.
Je sais pas d'ou tu sors ca, je ne suis pas d'accord. Dans le cas des lib pourries et mal documentees, le developpeur est contraint de chercher dans les headers.
Dans les libs que j'utilise, les docs sont bien faites et je ne vais jamais chercher dans les headers:
- boost
- qt
- python
- lua
- KDE
[^] # Re: ???
Posté par zeSixty4Douille . Évalué à -2.
Certe ca ne marche super quand c'est une API complexe, ou de haut niveau, quoique. J'ai appris OpenGL comme cela, et c'est surement plus optimise ce que je fais que ce que font les dev qui lisent toues les doc, sans rien comprendre (va leur demander de placer un prefetch, ou autre...).
Regarde Linus, il a commencer en regardant le code assembleur de petit jeu, puis les a ameliore.
Pour la question des tests que souleve l'article, je trouve cela VRAIMENT indignant sur la connaissance qu'on les modo des dev du libre. Il ne s'agit pas de ne pas faire de tests auto, il s'agit de comprendre l'interet d'avoir acces aux sources, de comprendre qu'il vaut bien mieux perdre du temps a faire du code vraiment clean, qui donne envi, portable, qui passe nickel sous valgrind, plutot que de perdre du temps a tester toutes les combinaisons de fonctionnalite betement. Encore une fois, je prefere un petit bug a du code pourri.
Imagine devoir faire des tests auto du release manager de KDE ... tu dois tester toutes les options de compilation, sur toutes les plateformes, avec toutes les CG du monde, sur plusieurs niveau de Xorg et de toutes les autres dependance (pour faire comme l'industriel de binaire). Ca t'avancera a quoi ? il n'y aura pas moins de bug. Par contre si ton code est lisible, en 20 minutes un utilisateur eclaire pourra t'aider. Ca plus une bonne communication.
[^] # Re: ???
Posté par pasBill pasGates . Évalué à 4.
Si t'as 3 ans pour apprendre comment fonctionne l'API t'as de la chance, mais c'est rarement le cas dans le monde informatique.
Pour la question des tests que souleve l'article, je trouve cela VRAIMENT indignant sur la connaissance qu'on les modo des dev du libre. Il ne s'agit pas de ne pas faire de tests auto, il s'agit de comprendre l'interet d'avoir acces aux sources, de comprendre qu'il vaut bien mieux perdre du temps a faire du code vraiment clean, qui donne envi, portable, qui passe nickel sous valgrind, plutot que de perdre du temps a tester toutes les combinaisons de fonctionnalite betement. Encore une fois, je prefere un petit bug a du code pourri.
Il y a un milieu, il est inutile de tester toutes les combinaisons, et ne rien tester et totalement stupide. Il s'agit d'utiliser ses connaissances pour choisir quoi tester, par exemple tester des configurations de softs que absolument personne n'utilise est totalement inutile.
tu dois tester toutes les options de compilation, sur toutes les plateformes, avec toutes les CG du monde, sur plusieurs niveau de Xorg et de toutes les autres dependance (pour faire comme l'industriel de binaire). Ca t'avancera a quoi ? il n'y aura pas moins de bug. Par contre si ton code est lisible, en 20 minutes un utilisateur eclaire pourra t'aider. Ca plus une bonne communication.
La tu compares un type qui fait des tests idiots avec un type qui developpe du code propre.
Moi je te proposes de prendre un type qui fait des tests intelligents et bien cibles a la place.
[^] # Re: ???
Posté par zeSixty4Douille . Évalué à -1.
1 - je n'ai jamais dit qu'il ne fallait pas faire des tests autos, j'ai simplement dis que c'est la demarche du nivellement par le bas. Les entreprises qui font du proprio utilisent principalement les testsautos pour tester les dependances (CORBA, Orcle, DB2, Java, la CG, le compilateur .......). Microsoft, pour certifier du HW, et pour eviter d'employer 150 indous.
2 - La meilleur chose a faire pour apprendre Qt si tu n'as pas de connaissances prealable :
1-> faire les tutoriaux,
2-> consulter rapidement la doc,
3 -> COPIER pour ne pas perdre de temps, voir mieux, tu regardes l'archi depuis le code deja compile (tu peux trouver la classe la composante qui fait le travaille dont tu as besoin, puis tu peux a nouveau consulter la doc).
Ne me dis pas que tu as appris la MFC depuis la doc ??? sans consulter qq exemples et que finalement, ce sont eux qui t'ont permis d'avancer ...
Je maintiens que les tests autos c'est une perte de temps pour le libre, cela dit, ca ne veut pas dire que c'est inutile, je consacre 40 % de mon temps a faire du code qui tests differents cas de figure, JE FAIS PAS LA LECON de morale , avec des arguments a 2 balles en vantant des bienfaits triviaux. Quand tu as acces aux sources, il y a autant de "release manager" que de presonne qui compile leur programme. Donc cet article n'a rien a faire en premiere page (mais j'en ai franchement rien a foutre qu'il y soit, mais j'avais une plus haute estime pour ce site).
[^] # Re: ???
Posté par pasBill pasGates . Évalué à 3.
Ca n'a _absolument_ rien a voir. Je vais te donner l'exemple MS histoire que tu te rendes compte de la difference :
Dans la division Windows, il y a facilement plus de 3'000 testeurs/developpeurs de tests qui ne font _que ca_
Les developpeurs de code eux-meme n'ecrivent que tres peu de code de tests, principalement le code suffisant pour voir que leur code marche correctement sans plus, ils se concentrent a ecrire du code de qualite, par contre ils donnent aux test/test-developers toutes les infos necessaires pour ecrire des tests performants.
Si les tests etaient inutile, crois moi MS s'amuserait pas a payer les salaires et immeubles utilises par ces 3'000 personnes. Les autres compagnies genre Cisco, Adobe, ... font toutes de meme. De loin la plupart des bugs trouves viennent de nos equipes de test, si on devait compter sur les utilisateurs(de beta, RC, ... et la beta de XP c'etait 500'000 personnes hein) pour les trouver on mettrait bcp plus de temps a sortir l'OS et bcp plus de bugs seraient trouves apres la sortie de la version finale, tout simplement car c'est la que la plupart des gens commencent a vraiment utiliser le systeme.
Ne me dis pas que tu as appris la MFC depuis la doc ??? sans consulter qq exemples et que finalement, ce sont eux qui t'ont permis d'avancer ...
J'ai jamais appris les MFC, donc non :+) Plus serieusement, oui je regardes bien evidemment des exemples pour pouvoir debuter, mais la doc c'est un element essentiel histoire de connaitre les effets de bord d'une fonction, les valeurs de retour possibles,...
Je maintiens que les tests autos c'est une perte de temps pour le libre, cela dit, ca ne veut pas dire que c'est inutile, je consacre 40 % de mon temps a faire du code qui tests differents cas de figure, JE FAIS PAS LA LECON de morale , avec des arguments a 2 balles en vantant des bienfaits triviaux. Quand tu as acces aux sources, il y a autant de "release manager" que de presonne qui compile leur programme.
Ben moi je maintiens que c'est exactement le contraire : qqe chose de tres utile, et j'en ai la preuve chaque jour au boulot vu le nombre de bugs trouves par les equipes de test.
[^] # Re: ???
Posté par zeSixty4Douille . Évalué à 0.
Entre le CVS de KDE, et ce que tu vas trouver dans ta distrib, il y a de tres nombreux intermediaires, et pas seulement ta distrib. Deplus, il n'y a moins de contraintes conscernant la compatibilite binaire.
Microsoft a des contraintes supplementaires par rapport aux logiciels libres. Ce que j'entends par tests autos, ce sont des tests qui vont te permettre de valider une modification. Dans leur contexte, ils n'ont pas le choix que de tout tester via des tests auto. Si tu prends une nouvelle CG, les drivers seront fait par NVidia, donc hors de question de ne pas tester dans tous les sens. Tu prends Sun, ils developpe eux meme leurs drivers, mais la contrainte est la meme conscernant la compatibilite binaire.
Le libre a d'autres contraintes, c'est d'etre portable, de limiter les dependances sur des techno ponctuelles, et d'interesser les developpeurs. Tu prends un truc comme "udev", qui s'est impose soudainement dans les distrib recentes, tu n'as pas de telles modifications dans un produit proprio en cours de vie, encore moins si c'est une version de Windows.
Donc la demarche de faire des tests autos dans le libre est moins utile, et plus chiante a mettre en oeuvre. De toutes facon, tu installes MySQL a la main, tu as un minimum de tests evidement, mais faire des tests exhaustifs, alors que c'est pas leur plateforme de dev, que le compilateur que tu utilises, c'est meme pas gcc, si tu veux que ca marche, il faut commencer par interesser le dev. Et pas tout miser sur les tests autos, car tu ne peux pas prevoir tous les problemes a l'inverse, chez Microsoft tu n'as pas cette incertitude.
L'article arrive comme un cheuveux sur la soupe, sans rien prendre en compte, et ne parle meme pas de l'existant conscernant la facon qu'on les releases de version majeur de ce faire.
[^] # Re: ???
Posté par pasBill pasGates . Évalué à 3.
Quel rapport avec les tests ?
Microsoft a des contraintes supplementaires par rapport aux logiciels libres. Ce que j'entends par tests autos, ce sont des tests qui vont te permettre de valider une modification. Dans leur contexte, ils n'ont pas le choix que de tout tester via des tests auto.
Et pourquoi donc ? La beta de XP a l'epoque a probablement ete utilisee par plus de gens qu'il n'y avait d'utilisateurs de Linux au total. Si laisser les gens trouver les bugs faisaient l'affaire, ca aurait suffit, mais la realite est que ce n'est pas suffisant.
Donc la demarche de faire des tests autos dans le libre est moins utile, et plus chiante a mettre en oeuvre. De toutes facon, tu installes MySQL a la main, tu as un minimum de tests evidement, mais faire des tests exhaustifs, alors que c'est pas leur plateforme de dev, que le compilateur que tu utilises, c'est meme pas gcc, si tu veux que ca marche, il faut commencer par interesser le dev
Ca n'a rien a voir, ecrire des tests automatises pour MySQL il n'y a rien de plus simple, et ils sont valables quel que soit le compilateur, quelle que soit la plateforme.
[^] # Re: ???
Posté par zeSixty4Douille . Évalué à -2.
Pourquoi tout ramener a Microsoft, par ton commentaire tu soulignes le probleme de la news, qui souligne que ce ne sont que les utilisateurs qui trouvent les bugs !!! limiter la detection de bug dans le libre a bugzilla, SUPER, tu merites de te faire plussoyer ....
C'est une mauvaise chose de ce baser sur des exemples (du style MySQL). Mais je peux t'assurer qu'un changement de compilateur peut reveler des problemes. Quand tu fais de la certification, tu certifies une appli, c'est par rapport a une plateforme, c.a.d un compilateur, un OS, et toutes les dependances de l'appli (pourquoi certains UNIX livre l'OS et le compilateur ensemble ??? essaye de linker KDE ExtraGears compiler en gcc 2.95 avec KDE compile avce gcc 3.4.3 )... mais c'est pas le sujet de la news.
# Préjugés
Posté par RuleZ . Évalué à 4.
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 . Évalué à 1.
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++ :)
[^] # Re: test unitaire en C:C++ et autre
Posté par iznogoud . Évalué à 1.
Pour C et C++ il est trés simple de tester .. [...]Tu vérifie tes fuites mémoires avec valgrind.
Ahem, attention à ne pas généraliser. Ou alors, je veux bien une version de valgrind pour PPC.
Bon, j'avoue, c'est un cas "particulier", mais quand même. Moi je développe sur PPC, quels sont les outils mis à ma disposition pour tester les fuites mémoire... Bah euuuuh en fait, pas grand chose.
Heureusement, je programme plus en perl qu'autre chose, et donc, les problèmes ne sont pas les mêmes.
Rentrons dans le troll, parce qu'on le vaut bien. Comme dit plus haut, tout ce qui est personnel, je le bacle souvent. Ca marche, très bien, je m'arrête là.
Ce qui l'est moins, en général, je fais plus attention. Notamment, je fais mes tests unitaires, ça ne mange pas de pain. Je commente plus mon code, à tel point qu'il pourrait presque servir de documentation développeur dans certains cas.
Plus concrètement, pour avoir vu du code proprio, et du code libre, j'avoue que la comparaison est très difficile. Le code proprio ne sera pas plus propre qu'un autre hein... Et des exemples, on peut en trouver, pour un peu qu'on ait eu un jour sous la main un bout de proprio.
[^] # Re: test unitaire en C:C++ et autre
Posté par Christophe Fergeau . Évalué à 3.
Voilà m'sieur, il suffit de demander ;) http://ozlabs.org/~paulus/(...)
[^] # Re: test unitaire en C:C++ et autre
Posté par iznogoud . Évalué à 2.
configure: error: Valgrind is operating system specific. Sorry. Please consider doing a port.
Je veux bien faire un port, mais bon, comment dire, faudrait m'allonger mes journées de quelques heures/jour sinon je pourrai pas trouver le temps.
Cela dit, je le garde dans un coin pour le jour où j'utiliserai mon Linux sur ppc :)
[^] # Re: test unitaire en C:C++ et autre
Posté par Christophe Fergeau . Évalué à 2.
# Droit de réponse
Posté par Lucas . Évalué à 9.
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.
[^] # Re: Droit de réponse
Posté par zerchauve . Évalué à -4.
[^] # Re: Droit de réponse
Posté par Lucas . Évalué à 2.
Sourceforge, c'est la poubelle du libre. T'as 90% de projets morts... C'est pas vraiment un bon endroit pour mesurer la popularité d'un langage.
Franchement, cite moi 10 projets importants (déf d'important : dont une partie non négligeable de la communauté a entendu parler) écrits en Java, et ne concernant pas le développement web (donc pas de Jonas, Jakarta, etc.)
L'utilisation de Java est anecdotique dans la communauté du LL, et je ne dis pas que ça en fait un mauvais langage, juste qu'il n'est pas très utilisé :-) Maintenant, j'ai oublié de citer Java, c'est aussi parce qu'il est difficile de développer des applis de haut niveau pour GNU/Linux en Java actuellement, à cause du manque de bindings pour pas mal d'autres librairies. (Oui, il y a des contre-exemples)
[^] # Re: Droit de réponse
Posté par iznogoud . Évalué à 2.
* jedit
* netbeans
Cela dit, voudrais-tu dire par ne concernant pas le développement web que le java est à mettre sur le même point que le... php par exemple, c'est à dire un langage plutôt utilisé pour le wouaib ?
Je veux dire, cite-moi 10 gros projets écrits en php, et ne concernant pas le développement web.
Absurde.
Pourquoi restreindre comme ça ? Pourquoi exclure de facto des gros projets parce que tu ne veux pas qu'on les cite ?
L'utilisation de java n'est pas anecdotique dans la communauté du LL. Simplement, comme tu le proposes, c'est plus souvent utilisé pour des "petits projets". Pour moi, ça n'en fait pas une utilisation anecdotique. Juste un usage différent.
Manque de bindings ? Vu sur freshmeat, on trouve des bindings pour GTK, SDL, OpenGL... Je n'appelle pas ça un manque. Ni des contre-exemples, ou alors, cela sous-entendrait que ces bindings sont "anecdotiques" et "inutiles" ?
[^] # Re: Droit de réponse
Posté par lasher . Évalué à 1.
Parce que si on le prend comme ça, cite-moi 10 projets issus PHP qui ne concernent pas les livres d'or, de webmail, de forums ... :-)
En ce moment Java brille beaucoup par sa capacité à faire tourner des applis métier (web ou pas, on s'en fiche), donc du coup tu as Struts, Ant, Junit, Tomcat, JBoss, etc. qui sortent du lot. Mais on pourrait aussi parler de Eclipse, de NetBeans, de Jext, etc...
[^] # Re: Droit de réponse
Posté par Sylvain Sauvage . Évalué à 2.
1. « je fais ma petite papage avec un blog et mes photos de vacances » ;
2. « j'utilise le protocole HTTP comme protocole de base pour mes applications distribuées » (cf. l'entrée « web services »).
De quoi parle-t-on ici ?
[^] # Re: Droit de réponse
Posté par zerchauve . Évalué à 0.
genre " j'utilise le web et les navigateurs comme un ensemble homogène de travail, en faisant abstraction des OS".
le navigateur en tant que plateforme toussaaaaaa.....
Quel mépris des fois.....
[^] # Re: Droit de réponse
Posté par Sylvain Sauvage . Évalué à 2.
Notamment la réaction « projets Java : utilisent HTTP (sens 2) = web (sens 1), donc pas des vrais projets »...
[^] # Re: Droit de réponse
Posté par fabb . Évalué à 3.
Dire "le proprio fait aussi des logiciels fiables" est très maigre comme argument. Actuellement (et depuis longtemps) et terme de fiabilité/qualité il n'y a que Unix qui arrive au niveau de Linux (et vice versa). Ce n'est pas nouveau, surtout lorsqu'on regarde du côté d'Unix, que le logiciel propriétaire peut faire du faible.
Windows commence à arriver au niveau de Unix/Linux. Et encore, côté qualité dans le domaine de la sécurité il reste encore du boulot.
Tu parles des applis propriétaires "populaires" qui sont fiables. Mais les applis "populaires" du logiciel libre sont fiables aussi. C'est indiscutable.
Si tu bases ton raisonnement sur la partie bureautique, il faut avoir en tête un élément important :
1- Le libre n'est pas "populaire" pour la bureautique.
Le libre fait son introduction petit à petit dans la bureautique (via firefox, OpenOffice, etc).
Le libre n'est pas au stade ou il peut prendre significativement en compte la fiabilité pour la partie bureautique (sauf pour les navigateurs web, les clients mails, etc).
Pour la partie bureautique, la "mission" principale est de faire évoluer vite. Actuellement la cible est le geek plus que les entreprises. Quand il y aura une solide base d'utilisateur bureautique alors un effort significatif sera mis en fiabilisation/qualité. L'utilisation bureautique du libre est encore marginale.
Regardes Mozilla/Firefox. Avant Mozilla n'était pas toujours au top côté fiabilité. Maintenant que Firefox est très populaire, la qualité est un enjeux majeur et il est pris en compte plus que sérieusement.
Si t'as gedit qui t'exploise à gueule une fois tous les semaines, les développeurs Gnome regarderons ça en fonction des disponibilités. Par contre avec vim, la base d'utilisateur étant importante, si tu remontes un bug il sera corrigé assez vite. Pour la partie bureautique il y a encore plein de chantier et il faut "profiter" du relativement faible taux d'utilisation pour faire évoluer vite avec les ressources disponibles (qui n'ont rien à voir avec la puissance de feu de MS). Si Gnome ou KDE change de version tout les 6 mois, ce n'est pas pour rien. Mais il est claire que lorsque la base d'utilisateur sera aussi importante que dans le domaine des serveurs le rythme va se calmer et la qualité fera parti des enjeux prioritaires.
Certe, on peut demander toujours plus. Plus fiable, plus de fonctionnalité, plus "budile".
Mais ça ne mène à rien et c'est ignorer le fonctionnement du libre qui fait en fonction des ressources (bonnes âmes) disponibles.
Si t'as downloadé la dernière version de "bidule" et que ça plante, c'est presque "normal". Pas de quoi faire un scandale. Compares Mandrake CS, ou SuSE Enterprise, ou RHEL etc à des OS propriétaire et pas en utilisant le derner coincoin à la mode fraichement downloadé.
Apparament t'as été déçu avec quelques logiciels. Mais lesquels ?
Des logiciels ou la qualité est un enjeux majeur ou avec gedit ?
Pour ton débat "C/C++ c'est mal, ça fait des bugs", c'est totalement nul et c'est le réveil d'un troll qu'on a trop vu. Il y a des programmes en perl ou python qui ne sont pas formidables et il y en a même beaucoup. Fais les rapports suivant :
- programmes/librairies en language au niveau qui sux sur l'ensemble des programmes haut niveau
- programmes/librairies en C/C++ qui sux sur l'ensemble des programmes en C/C++
Je ne serait pas étonné que les languages haut niveau l'emportent haut la main (comprendre qu'ils sont globalement de moins bonne qualité).
Notons que beaucoup de librairies de language haut niveau sont souvent des wrappeurs de librairie C/C++ et guère plus.
Il y a des tonnes de programmes et librairies C/C++ qui roxent des ours.
Oui, parfois les programmes en perl/python/java/C# plantent car le développeur a fait une connerie. Pareil avec C/C++. Rien de mistérieux. Le language qui permet de corriger les conneries des développeurs ça n'existe pas.
De plus tu ignores totalement les problèmes de ressources lors de l'utilisation de languages de haut niveau. Eclipse c'est bien beau mais c'est un gouffre à mémoire vive (et heureusement gtk+ est en C).
Images tout le bureau en java ou python et t'as une truc qui ne peut pas tourner sur une architecture 32 bits.
Je repose ma question :
- Sur quoi tu te bases ?
[^] # Re: Droit de réponse
Posté par Lucas . Évalué à 3.
Laissons un peu de côté la fiabilité et la comparaison libre/proprio.
Le test par des utilisateurs-testeurs est une démarche qualité incomplète. Ca permet de trouver certains bugs situés assez haut dans le programme, mais pas les bugs bien enfouis. Pourtant (à la louche) aucun logiciel libre n'est testé en profondeur, via tests unitaires par exemple. Ce qui me décoit, plus que la fiabilité générale de GNU/Linux, qui est plutot pas mauvaise, c'est qu'on tombe de temps en temps sur des bugs qui nécessitent un effort considérable CAR les logiciels n'ont pas été correctement testés.
A mon avis, pour passer à l'étape suivante, les logiciels libres ont besoin d'etre testés correctement, et ne peuvent plus se contenter de l'approche actuelle ("c'est mes utilisateurs qui font les tests, moi je code").
Beaucoup d'éditeurs de LP l'ont compris, donc la communauté du Libre prend du retard qui ne sera pas évident à rattraper.
[^] # Re: Droit de réponse
Posté par fabb . Évalué à 1.
> Le test par des utilisateurs-testeurs est une démarche qualité incomplète.
j'aimerais savoir depuis combien de temps tu utilises le libre. Car parfois on a l'impression que tu es un "petit nouveau".
Si tu ne veux pas être testeur, utilise une distribution qui répond à ce besoin.
Si tu veux donner un coup de main au libre et que tu as du temps pour faire des tests, alors fait des tests et remontes des bugs. Tu peux aussi rédiger des tests de non régression, personne n'est contre et ta contribution sera apprécié. Il n'y a pas que les tests pas les utilisateurs qui sont pris en compte.
Dans libre il y a libre. Les testeurs, les développeurs, les concepteurs etc sont libres de participer.
Regardes du côté de Windows qui sort des versions beta et Sun avec Solaris qui fait de même.
Pourquoi ils le font à ton avis alors que selon toi ils bétonnent en test unitaire et autres trucs fumants ?
Pourquoi tu ne veux pas que le libre fasse de même ?
De nombreux projets ont eu un "coup de fouet" en adoptant le model du "bazard" et en abandonnant la méthode de la cathédrale qui fait si bon effet dans les discours marketing.
> Beaucoup d'éditeurs de LP l'ont compris
Ce n'est pas récent. Ça remonte pratiquement au début de l'informatique. Apparament t'as jamais utilisé Unix.
> donc la communauté du Libre prend du retard qui ne sera pas évident à rattraper.
Quel retard ? En fiabilité/qualité et pour les serveurs, le libre est OK.
Pour la bureautique, le libre n'a plus qu'un concurrent : MS.
Actuellement le but est de rattraper le retard en fonctionnalité car le libre n'a jamais eu d'avance sur MS dans ce domaine. Après ce retard rattrapé, on verra pour le reste.
[^] # Re: Droit de réponse
Posté par Lucas . Évalué à 2.
Sur mon impression générale. Elle est peut-être fausse, je ne sais pas.
j'aimerais savoir depuis combien de temps tu utilises le libre.
1999
Bon, ma dépêche était trollesque, je l'admets. Oublie tout ce qui mentionne LP et fiabilité, concentre toi sur ce qui mentionne les tests, et relis.
Quand je parle de retard, je parlais de retard dans la DEMARCHE qualité, pas dans la QUALITE. Comme me l'a fait fort justement remarquer quelqu'un par mail (coucou Guillaume), le titre de la dépêche était probablement mal choisi : beaucoup de monde a problablement lu "Qualité et Logiciels Libres" au lieu de "Démarche Qualité et Logiciels Libres".
[^] # Re: Droit de réponse
Posté par fabb . Évalué à 1.
Fichtre ça mérite une première page. T'es une vedette, une star ? :-)
> Quand je parle de retard, je parlais de retard dans la DEMARCHE qualité, pas dans la QUALITE.
Car tu ne connais pas la démarche qualité. Car il n'y a pas un page de pub pour te la décrire.
Voilà un explication :
* les logiciels upstream : on trouve de tous et dans tous les états. C'est normal, c'est le libre, on ne cache rien. Ici il y a des tests en tout genre. Test unitaire, test de régression, branche de développement et branche stable, retour utilisateurs, etc. C'est très variable. Il y a aussi le "test suprême", c'est la communauté qui décide quand une applis est stable (mérite un 1.0). Ce n'est pas un planning ou l'équipe marketing qui fait pression.
* les betas des distributions : on ne trouve pas de tous mais ce qui reste est dans des états variables. C'est un lieux parfais pour les testeurs (surtout pour les gros trucs style gnome ou KDE). Prends Fedora ou Gentoo, la branche de développement ou les betas utilisent souvent des versions de développement. Chaque bug/correction sera remonté en upstream. Beaucoup de développeurs du libre bossent aussi sur une distribution et sont donc particulièrement à l'écoute des remontées des testeurs. C'est aussi ici qu'un distributeur peut décider de virer une fonctionnalité car elle est insatisfesante. Ça arrive assez souvent.
* les distributions "bleeding-edge" : là on a un état moins "bizarre". Il peut rester des bugs et ça peut être insatisfesant en entreprise. Il y a encore plus de remontée de bugs pour traquer les cas rares.
* les distributions "enterprise" : en général basée sur une distribution "bleeding-edge" (donc déjà massivement testé). Certaines distributions sont aussi testé par des acteurs commerciaux (Dell, Ibm, Oracle, etc) durant la phase beta.
Exemple :
- Après des tests sommaires dans Rawhide, FC3 test1 sort le 13 juillet 2004.
- Après de nombreux tests, FC3 sort le 8 novembre (plus de 3 mois et demi de test et correction de bug preque exclusivement).
À la sortie de FC3, il n'y a plus grand chose à faire, il faut "attendre" les retours d'expérience (comme le logiciel proprio fait).
En parallèle à FC3, la RHEL 4 est en préparation. Elle profite des corrections de FC3 en phase beta et finale. Elle profite aussi de test auprès d'autres sociétés qui "valident" le produit.
- Courant fevrier ou mars 2005, RHEL 4 sort.
Soit 7 mois (!) après la première mise à disposition. Et ceci est "plannifier". Ça fait parti d'une démarche qualité. Plus "fort". RHEL 4 va avoir SeLinux par défaut. C'est passé par :
- FC2 avec SeLinux désactivé par défaut
- FC3 avec SeLinux activé par défaut
Un an de test pour SeLinux.
Voilà un exemple de démarche qualité pour une distribution.
Pourquoi ce "bordel" marche. Simple : la communauté *aime* ça !
Elle aime jouer avec les dernières versions. Elle aime voir si la dernière version lui fait un joli "kernel panic". Elle aime donner un coup de main en corrigeant un bug, etc.
Pourquoi s'en priver ?
Tu planques à la communauté un soft en phase beta et elle se fache. Donc c'est très naturellement que le logiciel libre s'appuis plus sur les testeurs que le logiciel proprio. De même, c'est très naturellement que les distributeurs proposent des distributions gratuites ou accessible à un coût modique.
[^] # Re: Droit de réponse
Posté par Lucas . Évalué à 7.
Je n'ai pas demandé qu'on le mette en première page. Si les modérateurs pensent que passer en 2eme page permettrait d'augmenter le niveau des commentaires et d'éviter les attaques ad hominem blessantes, n'hésitez pas :-)
Car tu ne connais pas la démarche qualité. Car il n'y a pas un page de pub pour te la décrire.
Qui es-tu pour attaquer comme ça ? T'es une vedette, une star ? T'as jamais posté de dépêche, jamais posté de journaux, et t'es sur DLFP depuis 11 jours.
On ne parle pas de la même démarche qualité. Je parle de démarche qualité pendant le développement d'un LL, tu parles de démarche qualité pour la sortie d'une distro.
On ne parle pas non plus des mêmes tests. Tu parles des tests par des utilisateurs finaux, je parle des tests unitaires ou d'intégration.
Bref, mon pauvre, t'es complètement à coté de la plaque. Plutot que de poster 20 commentaires pour dire la même chose, tu ferais mieux de te servir de ce que tu as entre les deux oreilles.
[^] # Re: Droit de réponse
Posté par dab . Évalué à 3.
Je crois qu'on peut dire en effet que fabb est une star de linuxfr :-)
[^] # Re: Droit de réponse
Posté par Prosper . Évalué à 2.
D'une certaine facon oui , il est connu sous un autre pseudo , matiasf :)
[^] # Re: Droit de réponse
Posté par fabb . Évalué à 1.
J'ai donné un exemple de démarche qualité. Exemple tiré sur les distributions.
J'ai donné un réponse à ta question :
- pourquoi il y a plus de tests par les utilisateurs/testeurs dans le LL que dans le LP
J'ai indiqué que les démarches qualités varient beaucoup entre projet.
Par exemple subversion utilise massivement les test de non regression. PostgreSQL aussi. Par contre dans la bureautique ce n'est pas ou peut utilisé.
Ailleur, j'ai mis un lien sur les tests automatisés mis en place par OSDL et indiqué que les développeurs Linux n'y sont pas très attachés. Que Linux préfère l'audit et un code bien fait.
> Bref, mon pauvre, t'es complètement à coté de la plaque.
Toi, t'as toujours rien donnée comme info. Il y a un vague lien sur dejagnu et "impression général".
C'est maigre pour une news.
Désolé d'essayer de tenter de t'expliquer pourquoi le logiciel libre a une bonne qualité même pour des projets qui ne te satisfont pas intellectuellement dans leur démarche qualité.
> Plutot que de poster 20 commentaires pour dire la même chose
Fais déjà un commentaire avec un contenu intéressant dedans avant de critiquer mes 20 commentaires qui sont là pour compenser une news de merde.
[^] # Re: Droit de réponse
Posté par Éric (site web personnel) . Évalué à 5.
Il a donné son avis, son avis a paru intéressant aux modérateurs et aux relecteurs, il a été publié. À la limite ce n'est pas lui qui a choisit la page principale.
Maintenant rien n'empêche quelqu'un d'autre de faire lui aussi un billet d'humeur avec une autre opinion. S'il est intéressant il y a des chances qu'il soit publié de la même manière.
Pas besoin d'être une vedette pour avoir une opinion jugée intéressante à discuter.
[^] # Re: Droit de réponse
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
D'ailleurs, vu le nombre de trolls^Wcommentaires, il avait bien sa place en PP.
[^] # Re: Droit de réponse
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Erf. En gros, la qualité des logiciels libres serait bonnes mais leur démarche qualité qui n'est pas celle des logiciels propriétaires n'est pas bonne ? euh...
Comme dis beaucoup plus haut, le libre préfaire un pantalon bien taillé que devoir avoir ceinture et bretelle pour le tenir.
Travailler avec filet en permanence n'empèche pas de se casser la gueule.
Si tu travails à "iso force", quelle est le système le plus efficace ?
Le libre se fout d'un paramètre mais pas les boites : le temps et la compétence (qui coute chère). Cela change donc beaucoup la manière de voir.
Souvent les projets majeurs libre sont codé avec de très bon codeurs. Souvent les logiciels proprio, on a les meilleurs codeurs qui sont "architectes" et ceux qui ont les mains dans le camboui sorte de leur école. Donc, certe, tu peux préféré payer à faire des testes que de payer un gars qui sait coder proprement. Mais je suis convaincu que c'est la seconde solution qui donnera la meilleur qualité mais peut-être pas en étant le moins chère (à court terme, mais les boites ne voient que le court terme).
"La première sécurité est la liberté"
[^] # Re: Droit de réponse
Posté par Lucas . Évalué à 2.
C'est mal passé dans le texte de la dépêche (encore une fois, elle était mal rédigée et tout et tout).
Ce que je dis, c'est que la DEMARCHE qualité des LL est pas mauvaise, mais elle pourrait être meilleure. Après, écrire des tests, ca prend du temps. Ca en prend sur le temps de développement, et ca en fait gagner sur le temps de recherche des bugs plus tard. Parfois, c'est rentable (pt de vue temps) : on économise du temps en faisant des tests. Parfois, ça l'est pas.
Les tests unitaires ne sont pas la réponse à la vie, à l'univers et à tout. C'est un outil parmi d'autres, et parfois il faudrait les utiliser. Actuellement, quasiment personne ne les utilise dans le Libre.
[^] # Re: Droit de réponse
Posté par TeXitoi (site web personnel) . Évalué à 3.
On dit « La vie, l'univers et le reste », et de toute façon, il est de notoriété publique que la réponse est 42 et pas les tests unitaires.
Bon, ok, je sors.
[^] # Re: Droit de réponse
Posté par Lucas . Évalué à 2.
Ah, je savais plus. Du coup j'ai cherché sur Google, qui m'a dit : "The Answer to Life, the Universe, and Everything"
Merci
[^] # Re: Droit de réponse
Posté par lasher . Évalué à 3.
[^] # Re: Droit de réponse
Posté par Sylvain Sauvage . Évalué à 2.
[^] # Re: Droit de réponse
Posté par calandoa . Évalué à 9.
Je ne suis pas tellement d'accord... Je trouve au contraire que tu as abordé un point très intéressant. C'est par contre dommage qu'il n'y aie pas eu plus de détail sur les différents logiciels de tests. Par exemple donner plus d'info sur DejaGNU, plutôt qu'un simple lien, ou parler des différents outils de couverture de code et de détection de fuites memoire abordés dans un précédant message.
Maintenant en ce qui concerne ta remarque sur les logiciels proprios, rassure toi, elle n'avait pas grand chose de trollistique... il y a juste la horde d'intégriste de linuxfr qui au lieu de voir le thème de la news « test des LL : comment s'y prendre et avec quels softs », ont vu « les LL ça suxe, les LP ça roxore » et se sont précipités par la brèche... Effectivement c'est sûr que Linuxfr n'était pas vraiment le lieu pour le faire : ce genre de news s'adressait plus à des développeurs et à des contributeurs actifs plutôt qu'aux militants qui passent leur temps à discréditer le camp d'en face et à glorifier leur propre camp...
[^] # Re: Droit de réponse
Posté par fabb . Évalué à -4.
Ça vole haut comme argument.
[^] # [HS] UNIX et la qualité logicielle
Posté par lasher . Évalué à 1.
Actuellement (et depuis longtemps) et terme de fiabilité/qualité il n'y a que Unix qui arrive au niveau de Linux (et vice versa)
Je te conseille de chercher sur le net le "UNIX Haters Guide" :
http://www.simson.net/ref/ugh.pdf(...)
Il a été écrit par un ingé de chez MS (bon à la limite, tu pourrais dire que quelque part c'est pas très surprenant), mais aussi par l'un des co-auteurs de "UNIX & Internet Security" (d'ailleurs dans ce dernier bouquin, il y est dit que les logiciels proprio sont beaucoup plus enclins aux bugs en ce qui concerne UNIX que leur équivalent libre - c'était en 96, vu que j'ai la 2è édition seulement :-) ).
De plus il y a une "anti-préface" de D. Ritchie, qui vaut le détour ;-)
Je trouve que ce bouquin est intéressant à lire (ne serait-ce qu'en diagonale) pour comprendre les limitations d'UNIX à l'époque... Le "longtemps" que tu donnes n'est donc pas si vrai que ça (le UHG date de 94)
[^] # Re: Droit de réponse
Posté par iug . Évalué à 3.
Pour moi il faut regarder catégorie pâr catégorie :
Outils de développements : bien plus fiables en libre (Emacs, gcc.., incomparables à des JBuilder qui plantent tout le temps ou autres)
Système, et démons, serveur: bien plus fiables en libres
Window Manager, IHM : ben là je me demande si Gnome est plus fiable que Windows, malheureusement, je pense que le second a pris un léger avantage ces derniers temps, mais rien de dramatique.
Bureautique (OO vs MSO) : équivalent
Le reste : ça dépend, y'a surement du bon et du mauvais dans les deux environnements. Evidemment, un soft libre peu répendu (style cinelerra) va être moins validé que son concurrent vendu à prix d'or.
[^] # Re: Gnome vs. Windows
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Peux-tu développer, stp ?
[^] # Re: Droit de réponse
Posté par arnaudus . Évalué à 3.
En ce qui me concerne, je suis tout à fait d'accord sur un point : le (très) mauvais choix des langages de programmation de la plupart des LL. En 2005, le C est utilisé pour coder des drivers, des bilbiothèques de calcul... et des interfaces graphiques de jeux sous Linux. Je ne pense pas que le C soit fondammentalement plus générateur de bugs que d'autres langages, mais ce qui est sûr, c'est que quelqu'un qui utilise C pour faire des applets gnome, il va certainement coder plus de bugs que quelqu'un qui sait choisir ses outils de développement, parce qu'il n'a pas tout à fait la même compétence.
Au passage, C++ n'est pas pareil que C du tout du tout, et un bon spécialiste qui utilise la STL, les exceptions, les bilbiothèques réputées fiables, les pointeurs intelligents et qui sait faire une bonne conception objet, je ne vois pas pourquoi ses logiciels seraient plein de bugs...
[^] # Re: Droit de réponse
Posté par fabb . Évalué à 1.
Il y a critique et critique.
Si je critique le propriétaire car il n'y a pas les sources, c'est une critique nulle.
De plus Lucas ne donne pas d'argument. Le libre fait parmis les logiciels les plus fiables et Lucas critique sans avancer de réel argument à part de trucs qu'on trouve dans des discours marketeux bien rodés.
J'ai critiqué le logiciel libre dans ce thread. Je dis par exemple qu'au niveau bureautique le libre n'a jamais eu d'avance sur MS et que le libre en est encore au stade ou la principale préoccupation est de rattraper le retard (ce qui ne veut pas dire copier :-)).
Les critiques sont admises lorsqu'elles ont du sens.
[^] # Re: Droit de réponse
Posté par arnaudus . Évalué à 7.
Mais quels logiciels? Oui, Linux fait partie des logiciels les plus fiables. Certainement des trucs comme Apache ou sendmail aussi. Maintenant, 99% des logiciels libres sont encore bancals, mal codés, bourrés de bugs divers et variés. Tant mieux si tu peux passer ta vie à utiliser ggc, mais pour la plupart des gens, il faut des trucs variés, des démineurs, des calculatrices, des petits outils, des jeux, etc. Je me suis amusé l'autre jour à lancer un par un les jeux qui étaient dans le menu graphique de ma debian. Si 50% se lancent, c'est un exploit! Et la plupart qui se lancent sont réellement... pourris (je veux dire : lents, moches, pas de son, bugs d'affichage etc). Alors oui, le top du top du LL, c'est fiable, beau, sans bugs. Par contre, dire qu'en moyenne les LL sont fiables, c'est quand même gonflé.
D'ailleurs, à propos du retour des bugs, la communauté du LL a en général une attitude étrange. En effet, reporter un bug demande des compétences assez élevées, et finalement, rien n'est fait pour l'utilisateur lambda, ou alors ça ne sert à rien. Le dernier exemple que j'ai en tête est mon premier (et dernier) rapport de bug par bugbuddy, le truc automatique de Gnome. Je rentre toutes les infos qu'il me demande, et lui génère l'état de la pile au moment du crash, etc. Bref, je joue à l'utilisateur moyen. Deux heures après, je reçois un mail "The informations you sent are not useful for us. Please recompile Gnome using debug flags", quelque chose comme ça (en anglais correct, ça va de soi). Mon bug a été classé "aux oubliettes" (je ne sais plus le terme diplomatique), et ça s'est arrêté là. Pourquoi faire un outil de report de bugs automatique s'il faut que l'utilisateur lambda recompile Gnome? Bref, tant que le système n'est pas plus au point, seulement quelques % des milliers de bugs existants pourront être correctement reportés et corrigés.
[^] # Re: Droit de réponse
Posté par fabb . Évalué à 0.
Tu mélanges tous. T'as quoi comme programme "bancal" ?
Des bricoles ici et là. Ce n'est vraiment pas représentatif du libre.
De plus, et ça a déjà été dit, le libre donne aussi la liberté de faire des merdes faitent par de mauvais développeurs. T'es pas obligés de "faire les poubelles".
> des démineurs, des calculatrices, des petits outils, des jeux, etc.
Ça c'est claire que globalement les développeurs s'en foutent un peu.
> Par contre, dire qu'en moyenne les LL sont fiables, c'est quand même gonflé.
Ce n'est pas gonflé. Les jeux en logiciel libre, c'est rien ou presque. Faire des conclusion sur la fiabilité du libre en ne considérant que les jeux est ridicule. Regardes le "poid" que fait les jeux dans une distribution "normal" (évites debian pour les stats ils accèptent de tout :-) ; ce qui est normal compte-tenu de sa "philosophie"), c'est ridicule par rapport à tout le reste qui marche bien.
Exemple pour FC3 :
[root@one tmp]# rpm -q --queryformat "%{GROUP} %{NAME} %{SIZE}\n" --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ -a | sort | uniq | grep -i game
Amusements/Games bzflag 5638217
Développement/Bibliothèques kdegames-devel 423773
Divertissements/Jeux gnome-games 18501643
Divertissements/Jeux kdegames 16085867
Moins de 1 % par rapport à l'ensemble.
> Bref, tant que le système n'est pas plus au point, seulement quelques % des milliers de bugs existants pourront être correctement reportés et corrigés.
Fichtre, on est foutu.
[^] # Re: Jeux sous Linux
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
Par contre, dans ma lancée, jeme suis dit que j'allais tester un jeu propriétaire mais existant sous Linux. Commercial, il n'existait qu'une démonstration: et là, c'est le drame, la démo n'a jamais fonctionné et m'a surtout forcé à relancer XFree86... Pourtant, j'ai déjà joué à Torcs, Tuxracer ou même Billard-gl, pour preuve que la 3D fonctionne, quoi...
[^] # Re: Droit de réponse
Posté par Veiovis . Évalué à 1.
Oui, je l'ai indiqué moins durement avant. Résultat, le commentaire est descendu (on ne le voit plus:-)). Le tien aussi commence à l'être. C'est vrai que c'est plus facile que de répondre. J'ai l'habitude des commentaires mal vus (en général, je trouve que c'est bon signe -- mais je ne dirai pas pourquoi, sinon je me retrouve à -10); mais là, je ne comprends vraiment pas. Quelqu'un pourrait-il avoir l'amabilité d'expliquer rationnellement (please) le déclassement du C++?
[^] # Re: Droit de réponse
Posté par zeSixty4Douille . Évalué à -1.
[^] # Re: Droit de réponse
Posté par zeSixty4Douille . Évalué à -1.
Simplemenet, selon moi, si on pouvait deboguer directement du code optimise sur les distrib majeurs, ca vaudrait 1000 fois mieux que des tas de tests autos a maintenir.
[^] # Re: Droit de réponse
Posté par fabb . Évalué à 1.
On peut déjà. Fedora le fournissait mais ça bouffe trop de place (un gros problème pour les mirroirs).
Suffit de recompiler le paquet et tu obtient un toto-debuginfo-*.rpm.
Tu l'installes puis :
$ gdb /usr/bin/toto
[^] # Re: Droit de réponse
Posté par zeSixty4Douille . Évalué à -1.
moi je n'arrive meme pas a faire un dladdr ou un nm sur une lib, dans les distrib releasee. il faut juste se retrousser un peu les manche pour pouvoir le faire. Ca aurait ete bien d'avoir un article qui parle de ca au lieu de parler de gconf ....
# Libre...
Posté par Psychofox (Mastodon) . Évalué à 2.
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.
[^] # Re: Libre...
Posté par Lucas . Évalué à 2.
Une proportion non négligeable de développeurs de LL négligent les tests car ils considèrent que c'est aux utilisateurs de les faire. C'est ce comportement que je déplore.
Ensuite, l'excuse du "les LP sont pas fiables, pas de raison de faire des LL fiables", je trouve ça pas génial ;-)
# Motivation initiale
Posté par Thomas Petazzoni (site web personnel) . Évalué à 10.
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.
[^] # Re: Motivation initiale
Posté par Lucas . Évalué à 3.
- quelles sont les techniques et outils permettant d'automatiser le test des logiciels utilisant des interfaces graphiques ?
Les applis graphiques bien construitent utilisent en général une architecture MVC (Model View Controller). Google explique plutot bien ce que c'est, je ne vais pas tenter une explication foireuse détaillée ici. Juste en 2 lignes : il s'agit de séparer la "logique", le "moteur" de l'application de l'interface.
Une application construite ainsi est facile à tester :
- D'un coté, le Model peut être testé avec des tests unitaires, d'intégration, etc .... comme une appli "classique".
- D'un autre côté, l'interface graphique peut être testée à la main ou avec des outils spécialisés. Mais en général, les bugs ne concernant que l'interface sont assez faciles à trouver, une fois qu'on a bien débuggé le Model.
Cette architecture s'applique également très bien aux applis web, mais est malheureusement peu utilisée : beaucoup d'applis en PHP mélangent allègrement modele et interface (le code de LinuxFR, par exemple, est assez fort dans ce style).
- 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 ?
Je pense qu'il faut développer plus d'outils de test (le test peut être fun, c'est juste que pour l'instant, on a pas vraiment les bons outils pour ça). Pour DejaGNU par exemple (que je n'ai jamais utilisé), il y a extrèmement peu de documentation orientée introduction. Le lien que je donnais dans la dépêche n'est pas super probant, mais c'est le mieux que j'ai trouvé.
[^] # Re: Motivation initiale
Posté par Gawan . Évalué à 2.
< Ma vie >
Dans ma boite, on est passé pour le développement des applics web de php à Ruby on Rails ( "Rails is a full-stack, open-source web framework in Ruby" : http://www.rubyonrails.org(...) ) justement pour avoir une architecture MVC bien claire avec un code facile à maintenir. De plus, il intègre des outils de tests unitaires bien foutu.
</ Ma vie >
# Et Debian ?
Posté par R4f . Évalué à 4.
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...
[^] # Re: Et Debian ?
Posté par Lucas . Évalué à 4.
Ma dépêche totalement incomprise (incompréhensible ? ;) essayait de mettre l'accent sur les problèmes de qualité au moment du développement. Debian fait un boulot magnifique après coup. C'est probablement grâce au travail de groupes comme Debian que le manque de "profesionnalisme" dans le développement de la plupart des LL ne se fait pas plus sentir.
[^] # Re: Et Debian ?
Posté par R4f . Évalué à 4.
Mais alors pourquoi ne pas imaginer un autre modèle de gestion de la qualité logicielle, qui se fasse différemment des canons exhibés par la sphère non libre ?
Il ne faut pas oublier les motivations des développeurs de logiciels libres. Dans un tel cas, on peut orienter la gestion de la qualité à l'extérieur du projet, par la/les distrib(s) qui diffusent le logiciel, et pour lesquels la qualité est un axe prioritaire...
Le logiciel libre tient une partie de son succès à l'abaissement des barrières à l'entrée, justement. Lorsque le projet devient plus gros, plus adpoté, et souvent lorsqu'il intéresse plus des groupes qui en font un usage professionnel, on voit généralement des processus de qualité se mettre en place (et les outils idoines par ailleurs).
A propos de ces outils, en passant, n'oublions pas qu'il restent des outils. Seule leur bonne utilisation mène à la qualité. Utiliser des outils relativement pauvres pour gérer la qualité peut mener à de meilleurs résultats qu'un usage superficiel d'outils puissants, ne l'oublions pas ! Ce sont les processus (organisationnels, et les chartes de qualité), lorsqu'ils existent et sont respectés, qui priment sur les outils !
[^] # Re: Et Debian ?
Posté par zeSixty4Douille . Évalué à -7.
# Pourquoi tant de haine
Posté par Guillaume Knispel . Évalué à 0.
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
[^] # Re: Pourquoi tant de haine
Posté par Thomas Petazzoni (site web personnel) . Évalué à 6.
L'auteur a déjà précisé plus haut que ce n'est pas parce qu'il y a des bouses dans les logiciels propriétaires que cela ne nous autorise pas à nous questionner sur l'amélioration de la qualité des Logiciels Libres.
Lis les explications de l'auteur de la news, il explique clairement que son but n'est pas de dire que le Logiciel Libre est plus mauvais en qualité que le logiciel propriétaire, mais bien de s'interroger sur comment on peut améliorer la démarche qualité des Logiciels Libres, avec quels outils et techniques, pour quels projets, etc...
Plutôt que d'esquiver la vraie problématique en disant ouououoauouahh c'est un gros troll qui n'a rien à faire en première page, ne serait-il pas intéressant de donner ton avis sur le vrai fond de la question, qui au delà de la présentation trollesque, me semble tout à fait intéressante ?
[^] # Re: Pourquoi tant de haine
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Pourquoi tant de haine
Posté par Lucas . Évalué à 3.
Donc les tests unitaires n'auraient rien décelé.
Lucas, qui a oublié ses tests d'adéquation
[^] # Re: Pourquoi tant de haine
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Le code, les tests, toussa, ça ne devrait pas prendre plus de 10% du projet.
# Choisir un cycle de dev
Posté par Franck Hanot . Évalué à 5.
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 (site web personnel) . Évalué à 1.
URL :
- http://developpeur.journaldunet.com/news/010530rats.shtml(...)
- http://www.dwheeler.com/flawfinder/(...)
- http://www.zataz.com/documentation/6902/documentation-audit-code-ra(...)
[^] # Re: Tests sur la sécurité du code
Posté par Thomas Petazzoni (site web personnel) . Évalué à 3.
Un ancien article de Linux Weekly News parle également de l'analyse statique de code pour le noyau : http://lwn.net/Articles/87538/(...) .
La page de Dawson Engler à Stanford, un des fondateurs de Coverity, contient des références vers des papiers sur le sujet : http://www.stanford.edu/~engler/(...) .
Ces outils d'analyse statique du code peuvent donc s'appliquer sur du code réel, éventuellement annoté. Ceci le rend utilisable relativement aisément sur de grands projets.
Pour aller plus loin, il faut passer par de la vérification formelle, dont l'objectif est de prouver formellement le fonctionnement correct du logiciel. David Mentré maintient sur http://www.gulliver.eu.org/ateliers/fv-tools/fv-tool-list.html(...) une liste de ces outils. Évidemment, ils sont beaucoup plus lourds à utiliser sur de gros projets, et sont pour l'instant réservés à des applications vraiment critiques.
# La démarche qualité existe - elle est seulement différente
Posté par herodiade . Évalué à 4.
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.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Philippe F (site web personnel) . Évalué à 4.
C'est pas vrai du tout. Tout bug attrape par un test unitaire est un bug de la vie reelle, qui aurait pose un probleme a un moment ou a un autre.
Ensuite, il n'y a pas que le kernel dans la vie, il y a plein de logiciels libres qui seraient tres faciles a tester avec des tests unitaires et qui auraient beaucoup a y gagner, mais qui ne le font pas.
> La qualité d'une fonction d'une ou d'un groupe de fonction n'induit pas le bon fonctionnement du logiciel !
C'est faux aussi. Le driver dedie purement a un materiel est plus dur a tester (mais c'est pas du tout impossible) que d'autres parties. Cependant, la qualite d'un groupe de fonction induit grandement la qualite globale d'un logciel. Si on prend l'exemple du kernel:
- la qualite des fs est independante de la qualite des drivers de disque dur. C'est tres facile de tester un FS et c'est d'ailleurs ce qui est fait poru ext3 et reiser
- il y a d'autres parties du noyau facile a tester mais qui ne le sont pas ou du moins pas via des tests unitaires : scheduler, gestion de la memoire.
Il faut voir que des que tu n'es plus a 1 cm du materiel, c'est a dire des que tu sors d'un drivers, tout est testable. Il suffit de faire un pseudo driver dont tu modfifieras le comportement dans tes tests et via lequel tu verifieras que le reste du systeme se comporte correctement.
> Les LL misent généralement sur la période d'incubation
Pour des tres gros projets, c'est peut-etre le cas. Mais la periode d'incubation, ca veut bien dire que tu laisse aux utilisateurs le soin de trouver des bugs. C'est pas une bonne demarche a mon sens, il vaut mieux trouver toi-meme un max de bugs pendant le dev et c'est a ca que servent les tests unitaires.
> Mais c'est la condition pour un débug pertinent:
Je ne suis pas d'accord du tout. Seul une tres petite minorite de bug ne peut etre decouvert que dans des conditions reelles. Une tres grande majorite de bug peut-etre decouvert durant la phase de dev. Le noyau ne fait pas exception. C'est l'argument typique des gens qui ne veulent pas tester: "Je ne peux pas tester ca". Apres, tu leurs presentes des methodes pour qu'ils puissent tester ce qu'ils ne peuvent pas tester mais ils refusent en general des les utiliser parce que ca les obligerait a changer leurs habitudes et a faire evoluer un poil leur architecture.
> 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.
C'est vrai qu'on a tout le temps pour attendre les nouvelles versions stables de debian, ca ne decredibilise pas du tout le projet .
<<
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.
>>
Ceci est vrai sur un certain nombre de tres gros projets, mais pas sur beaucoup. Typiquement, pour le noyau, Linus relit les patchs mais l'inverse est rarement vrai.
La relecture s'attache en general a trouver des erreurs de conception. C'est rare qu'on leve des purs bugs comme ca.
Ce que tu dis est complementaire des tests unitaires, mais ne peut en aucun cas s'y substituer.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Lucas . Évalué à 3.
Ca s'appelle "stub" ou "bouchon" dans la littérature.
Typiquement, pour le noyau, Linus relit les patchs mais l'inverse est rarement vrai.
Tu veux dire que les patchs ne relisent que rarement Linus ?
=>[]
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Philippe F (site web personnel) . Évalué à 2.
cf www.easymock.org pour une solution en java. Pour python, on peut trouver ca dans le python cookbook, sur le site d'active state. Une implementation de mock en moins de 100 lignes, impressionnant.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par v_atekor . Évalué à 2.
1/ Il est évident qu'une démarche qualité est necessaire dans l'industrie logicielle
2/ La démarche qualité ne dépend pas des stratégies d'entreprises utilisées (Logiciel libre/propriétaire)
3/ Un bon logiciel est testé
Pour le monde des logiciels libres, il y a de très nombreux tests. Pour ce qui concerne Linux (noyau), prennons un sujet en cours de développement sur le noyau Linux : NFSv4.
Les outils:
1/ http://nfsv4.bullopensource.org/tools/testing_tools.html
Pour des tests plus génériques:
http://ltp.sourceforge.net
http://lse.sf.net/
Au vues des documents trouvés sur internet il est évident que certains logiciels/couches logicielles subissent des campagnes de tests complètes. Sur le même sujet:
http://developer.osdl.org/dev/nfsv4/
http://developer.osdl.org/dev/nfsv4/test_matrix.sxc
On lit sur la première page...
-61 tests fonctionnels,
-11 tests d'interopérabilité,
-38 tests de robstesse,
-30 tests de performances et
-16 tests de sécurité....
Un joli travail de tests, hein?
Enfin, quelque soit la stratégie d'entreprise choisie (Ouverture ou non du code) un logiciel entièrement testé est beaucoup beaucoup plus cher qu'un logiciel non testé... Et la limite de la rentabilité existe. Il vaut mieux souvent ignorer des tests et rester rentable :)
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Philippe F (site web personnel) . Évalué à 4.
Prend un exemple, le support des materiels exotiques. Il devrait y avoir une suite de tests unitaires qu'on pourrait faire tourner sur un driver quelconque. Pour l'instant, la facon de tester un driver du noyau, c'est soit de faire tourner le noyau de facon normale, soit pour chaque developpeur de s'ecrire une ou deux fonctions de test. Je suis choque de ne pas voir de repretoire test dans les sources du noyau.
Par exemple, je suis dans une situation similaire au cas du driver : je dois supporter plusieurs lecteurs de carte a puce sans-contact. A chaque fois que je rajoute un lecteur, je fais tourner une suite de test generique qui va tester toutes les fonctionnalites generiques du lecteur et va donc valider que mon implementation du support du lecteur est correct dans tout
Pourquoi on ne retrouve pas ce genre de chose dans les sources du noyau ? Avec ca, on pourrait avoir une suite de test revue et amelioree par tout le monde, donc qui serait de tres bonnes qualites.
Et quand un materiel exotique ne marche pas, le developpeur du driver pourrait dire au mec: fait tourner la suite de test et envoie-moi les resultats. Ca l'aiderait surement a faire un diagnostic plus precis du probleme.
Je prends un autre exemple que je connais bien : KDE. Combien de suties de test dans KDE ?
- une suite de test pour kurl
- une suite de test pour taglib
- une suite de test introduite recemment pour khtml.
C'est plutot pathetique. Ca change doucement mais faut pas etre presse.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par v_atekor . Évalué à 3.
- NTPL : http://nptl.bullopensource.org/(...)
- CKRM -> ltp
- VMM -> ltp
- VFS -> ltp
- schedullers -> ltp
- POSIX conformance -> ltp
- systèmes de fichiers (tous) -> ltp + tests spécifiques au systèmes de fichiers
http://nfsv4.bullopensource.org/tools/testing_tools.html(...)
....
...
Pourquoi les tests ne sont pas dans les sources?
La bonne question est : qu'est ce que les outils de tests feraient avec les sources linux?
Il y a de _nombreuses_ suites de tests dédiés, qui elles sont regroupées dans le Linux Tests Projects:
http://ltp.sf.net/(...)
http://ltp.sourceforge.net/tooltable.php(...)
Un oeil sur le travail de l'OSDL serait aussi le bienvenu.
http://www.osdl.org/lab_activities/lab_projects(...)
... Ainsi que ceux de ses membres...
http://www.bullopensource.org/(...)
http://www.ibm.com(...) ... Mais la majorité des tests sont centralisés sur le LTP.
Bref, pour une personne interressée pour tester linux, il lui faut 1 seconde pour tomber sur l'ensemble des tests disponible, et il lui reste des années de travaill pour passer les tests et étudier les résultats. C'est ce que font de nombreuses entreprises travaillant dans les logiciels libres.
Dans les logiciels libres la démarche qualité existe, et n'est même pas différente que pour les autres logiciels.
Quant à KDE, je ne pratique pas la programmation userland, désolé, et mais connaissances en tests d'applications userland sont exactement nulles.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par herodiade . Évalué à 3.
> Tout bug attrape par un test unitaire est un bug de la vie reelle, qui aurait pose un probleme a un moment ou a un autre.
Je voulai dire que le test unitaire n'attrapent en général que les bugs triviaux: on sait ce que doit faire une fonction/un groupe de fonctions dans telle situation, et elle ne le font pas, c'est un bug.
Les programmeurs attentifs font rarement ce genre de bugs (du moins ça ne passe pas, à la relecture). Surtout dans les langages qui nécessitent une plus grande attention amha (ceux où l'on utilise moins de tests unitaires).
Les bugs pernicieux (en particulier les bugs affectant la sécurité) sont ceux qui se manifestent quand un morceau de code est exposé à une situation non prévue : buffer overflows, sql injections, xss, ou bien telle fonction d'apache qui dérape lorsqu'elle reçoit un type particulier d'url encodée en unicode, hardware qui ne réagit pas comme prévu (pour le kernel) etc. Dès que le code est exposé à la vie réelle en somme - et non aux attendues du developpeur (tests unitaires).
Je suis les Changelogs / commits cvs d'un certains nombres de projets, et je peut te dire que les correctifs du type "Telle fonction n'a pas rempli son contrat" sont rarissimes, et noyés derrière les "on est confronté à une situation limite qui pose problème".
Comme ces bugs se manifestent dans les cas d'utilisation non prévusn il est intéressant de démultiplier le nombres de testeurs (si possible, des testeurs travaillant dans des conditions différentes), et c'est surtout là qu'un audit du code attentif (par des programmeurs plus "experts") est nécessaire.
Les outils de detection "automatique" (tests unitaires, mais aussi valgrind, splint, efence, boehm gc, dmalloc etc) interceptent les erreurs les plus triviales, celles des developpeurs débutants. Ils ne sont pas tout à fait inutiles, mais secondaires par rapport à d'autres facteurs.
> Mais la periode d'incubation, ca veut bien dire que tu laisse aux utilisateurs le soin de trouver des bugs.
> C'est pas une bonne demarche a mon sens, il vaut mieux trouver toi-meme un max de bugs pendant le dev
Ce n'est pas exclusif bien entendu. Les devs doivent faire tout leur possible pour detecter les bugs. Mais ça n'est jamais suffisant.
> La relecture s'attache en general a trouver des erreurs de conception. C'est rare qu'on leve des purs bugs comme ca.
Pas d'accord.
Dans de nombreux projets on trouve des developpeurs "senior" dont la tache se résume quasi exclusivement à la relecture du code. Ces gens sont devenus experts dans ce domaine, et leur coup d'oeil vaut de l'or.
De plus ce travail de validation permet d'imposer le respect de regles de developpement strictes, qui facilitetent ensuite la relecture, qui obligent le dev à être attentif, etc. bref qui assurent une certaine qualité logicielle.
Un autre effet de cette phase de relecture/commentaires, surtout lorsqu'elle est publique, c'est qu'elle oblige le dev qui propose un patche à faire très attention: car ici on ne developpe pas pour gagner son beefsteack, ni avec des délais intenables, mais (un petit peu) "pour la gloire" ; et rien n'est plus désagréable qu'une appreciation désobligeante d'un expert sur son code.
Jette un oeil aux mailing-lists (par exemple de grub ou gcc) pour t'en rendre compte. On a dépassé la limite de l'enculage de mouches.
Cet aspect social du developpement libre prend aussi d'autres aspects. Par exemple le projet OpenBSD n'admet de nouveaux developpeurs que ceux qui ont détécté et corrigé de nombreux bugs (donc ceux qui savent _vraiment_ relire du code, pas seulement en pisser).
La délégation de confiance se fait au mérite et aux compétences, pas au diplome. ça aussi ça joue sur la qualité finale.
> Linus relit les patchs mais l'inverse est rarement vrai.
Alan Cox (au moins) relis aussi tout le code commité (dont celui de Linus).
Et encore, je trouve que Linux est un assez mauvais exemple dans le domaine.
Bon maintenant pour être tout à fait honnete ;)
Je trouve aussi que les petits projets (mal) developpés par des débutants se démultiplient dangeureusement en ce moment.
Il y a aussi de gros projets qui amha veulent aller très vite (mozilla, openoffice en particulier).
Mais de manière générale la démarche qualité des gros projets libre est amha imprenable par rapport aux logiciels propriétaires courants (je ne parle pas du soft propriétaire embarqué, ou dans l'aérospatiale etc évidement).
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Philippe F (site web personnel) . Évalué à 2.
>>
C'est un stereotype courant. Tout depend bien sur de l'attention que tu portes a tes test unitaires. Mais si tu lis les bouquins sur XP, tu verras que dans les exemples, ils testent toujours les conditions limites.
Si je devais ecrire un test pour strcmp, je ne commencerai pas par verifier que srcmp("toto","toto") renvoie 0. Je commencerai par verifier que strcmp( NULL, "toto" ) ne plante pas, ainsi que strmp( NULL, NULL) et strcmp( "toto", NULL).
Il est evident qu'on ne peut pas penser a toutes les situations dans les tests unitaires. Mais il est parfois bien plus facile de simuler des situations tordues via des tests unitaires que via le logiciel, et donc de trouver des bugs subtils. Je l'ai vu dans la pratique, avec des situations que j'ai cree de toute piece sous forme de test, que je n'aurai jamais pu trouver dans la pratique.
Dans l'exemple que tu donnes, une URL tordue dans apache. Ok, le test unitaire initial ne contenait pas ce cas. Une fois le bug reporte, tu modifies le test unitaires pour inclure un certain nombre d'url tordues. Et c'est beaucoup plus facile a faire que d'essayre de rentrer les url tordues dans apache.
En ce qui concerne les tests de securite et de buffer overflow, en general, ces problemes sont adresses par des regles de codage et de conception plus que par des tests unitaires.
> non aux attendues du developpeur (tests unitaires).
Les bon developpeurs ont des attentes tres tres pessimistes sur leurs entrees et vont le refleter dans leur test.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par herodiade . Évalué à 1.
Sauf que ce n'est pas "un certains nombres d'urls tordues" qui reproduiron le bug. Ce sont des urls tordues de façon très très précises ; tordues d'une façon que les devs n'auraient pas imaginé à l'implémentation. Ils ne l'auraient pas imaginé non plus à l'écriture de tests. On en revient toujours là.
Et les devs d'apache, ne font pas deux fois la même erreur: ils sont attentifs (donc la batterie de tests codée après coup ne servira à rien par la suite).
Dans ce genre de projets les tests unitaires ne pourrainet guère servir qu'à rassurer (au mieux) (Idéal pour les chefs de proj' préssés ...) car l'exigence de qualité est bien au delà de telles trivialités.
Je me permet d'intervenir dans ce bazard parceque je travaille justement dans le soft proprio sous tests unitaires. Et c'est clair (le choix du langage n'aide pas d'ailleur) que très peut d'attention est accordée à l'implémentation (à la différence de la modélisation, des tests etc). Dans ces conditions évidement ...
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Philippe F (site web personnel) . Évalué à 2.
Et oui, mais l'equipe des developpeurs change. Les anciens s'en vont, ces nouveaus les remplacent. C'est encore plus vrai en entreprise. La suite de test garantit que le qualite demeure dans le projet et pas seulement dans l'individu qui l'a code.
> (donc la batterie de tests codée après coup ne servira à rien par la suite).
C'est pas vrai. A la prochaine attaque sur URL, le code gerant les URL sera encore change. Il se peut qu'a ce moment, un developpeur introduise par megarde une modif qui enleve la correction precedente. Ca n'arrivera peut-etre pas mais tu n'as aucune garanti. Avec ta suite de test, tu as une garantie.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Pierre Tramonson . Évalué à 3.
Seuls les jeux de tests unitaires et l'automatisation de tout ça (Ant+JUnit par exemple), peut te le garantir.
L'informatique est réellement entrée dans une phase d'industrialisation depuis que ces scénarios de tests existent. Avant c'était du bricolage.
# Complexité
Posté par Giboyle . Évalué à 2.
- 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 :-)
[^] # Re: Complexité
Posté par Philippe F (site web personnel) . Évalué à 3.
C'est l'argument typique des mecs qui ne veulent pas tester. On parle de test unitaire. Si ta fonctionnalite unitaire a plus de 50 etats possibles, il y a un tres tres gros probleme de conception et je te conseille de separer ta fonctionnalite dans plusieurs classes contenant chacune des fonctinnalites elementaires. On appelle ca de l'encapsulation dans le monde de la programmation objet.
C'est pas toi qui parlait de bonne conception ?
> dès que le logiciel en question peut être mis en oeuvre dans des situations très variées
Si le logiciel doit etre soumis a des situations tres tres variees, il y a de grandes chances que le cerveau du developpeur n'arrive pas a lui tout seul a ecrire du code qui resistera a toutes ces situations. Dans ce cas, il est imperatif:
- d'essayer d'isoler separement la variation de ces situations (en general, c'est possible)
- de mettre en place des tests pour reproduire ces differentes situation. Dans un cas aussi complexe que tu le decris, il est naif de se dire "le developpeur a pense a tout", alors que le developpeur lui-meme sera bien plus rassure si il est en mesure de tester son code dans les situations variees.
> dès que la latitude des utilisateurs est très importante.
Ben voyons. Comme l'utilisateur peut tout faire, tu ne peux rien tester ? L'utilisateur fonctionne par taches elementaires donc tu peux tester chacune des taches elementaires.
> 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 ?
Un seul environnement de test suffit. Tu decoupes tes tests en hierarchie de facon a pouvoir selectionner ceux que tu veux faire tourner pendant que tu touches a une fontionnalite specifique.
Pour thunderbird, c'est plutot facile. Tu decoupes en fonctionnalite:
- les filtres: je cree un filtre X, un message qui doit etre filtre et un message qui doit passer a traver, je verifie que c'est le cas.
- recherche de msg : laisse a titre d'exemple
- pop3: tu montes un serveur pop3 de test ou mieux, tu en simules un (quelques lignes de python suffisent) et tu verifies que un message stocke sur le serveur est bien rapatrie par ton client, et surtout, qu'il a envoye les bonnes requets dans l'ordre. Apres, tu elabores, sur ton serveur pipo, tu mets un mauvais message, tu supprimes le message, tu reponds des conneries au requetes et tu verifie que thunderbird ne perd pas les pedales.
- smtp : tu montes un serveur smtp ou tu en ecris un reduit. Tu verifies que si tu envoies un message, il arrive bien sur le serveur smtp
- imap: idem
....
Pour OpenOffice, c'est pareil. Le seul truc que tu ne peux pas tester, c'est le rendu exact d'une police a l'ecran et a l'impression. En dehors de ca, tu peux tout tester. Je te donne des exemples de test:
- je selectionne un texte dans un paragraphe, je lance "mise en italique" et je verifie quand dans la representation interne du document, ce morceau de texte est mis en italique
- je selectionne un texte avec un style donne dans mon document et j'active la fonction "appliquer au style courant". Je verifie ensuite que les parametres de style du style courant ont ete mis a jour avec le style que j'ai selectionne
- j'ouvre un document sxw, je le sauve en word, je le recharge en word, je le re-sauve en sxw: le document final et le document initial doivent avoir le meme contenu modulo un nombre de champs _identifies_ qui ne sont pas pris en compte dans le format word
- j'ecrie un mot mal orthographie, je verifie que la fonction de correction va me sortir un mot correctement orthographie du dictionnaire.
etc, etc.
Comme tu vois, rien d'insurmontable.
Apres, sur l'explosion combinatoire des tests, ca ne s'applique pas aux tests unitaires : d'une part les fonctionnalites testees sont petites, d'autre part c'est le developpeur qui ecrit le test. Il sait quelle partie de son code il faut cibler pour lui chercher des embrouilles.
En terme de quantite de code, j'ai en general autant de code de teste que de code de programme. Mais ca ne me prend pas plus de temps a ecrire qu'un programmeur normal, car le programmeur normal aussi fait des tests. Sauf que les siens ne sont pas automatises et integre dans le projet.
C'est sur que tester un projet existant, c'est dur puisque tu as perdu tous les tests ecrits par le developpeur pendant sa phase de dev. Mais integrer les tests au dev, ca ne coute pas grand chose.
Le gain vient surtout au fur a mesure que le projet avance, ou tu peux completement te reposer sur les test unitaires. De facon non surprenantes, quand je decide de ne pas faire de test unitaire sur un morceau de programme, c'est justement la que je vais trouver des bugs par la suite et regrette ma decision.
> 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 ?
Non. Le cout de correction d'un bug croit exponentiellement en fonction du temps entre lequel il est decouvert et le moment ou la fonctionnalite a ete codee. On gagne donc un temps precieux a detecter les bugs tres tot et a s'eviter des rapports de bug qu'il faut gerer, reproduire, discuter, fermer.
J'ajoute que quand tu as des suites de tests unitaires, il est facile de s'appuyer dessus pour faire des suites de tests fonctionelles. Quand on te reporte un bug, au lieu de corriger, tu construits d'abord un test dans ta suite fonctionelle pour mettre le bug en evidence, puis tu corriges. Tu es sur que le bug ne reviendra _jamais_, tu as un test pour le prouver.
Qui plus es, tu as mentionne la notion de logiciel actif et bien maintenu. Un logiciel qui bouge, c'est un logiciel dont l'architecture evolue souvent dans le temps. Tu peux meme voir que tous les projets majeurs sont re-ecrits tous les deux ou trois ans (Gnome 1 -> Gnome 2, KDE 1 -> KDE 2, gimp1 -> gimp2, apache -> apache2, ...). Les tests unitaires prennent alors une valeur encore plus grande : on peut tout peter a l'architecture, en garantissant que les fonctionnalites sont encore la.
<< 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
>>
Je ne peux pas dire, je ne l'ai pas utilisee depuis deux ans.
# Stop !
Posté par Anonyme . Évalué à 10.
- 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"...
[^] # Re: Stop !
Posté par Philippe F (site web personnel) . Évalué à 4.
Je ne rajouterai qu'une chose : les tests unitaires, essayer les avant de les critiquer. Vous serez surpris de voir a quel point ca vous fait gagner du temps.
[^] # Re: Stop !
Posté par zeSixty4Douille . Évalué à -3.
[^] # Re: Stop !
Posté par zeSixty4Douille . Évalué à -3.
C'est evident qu'il faut tester ce que l'on fait.
Le probleme c'est que l'article c'est :
"ouuuiiinn, y a pas de techniques triviales pour faire des tests de regression dans le libre. Sachez mes enfants que dans les entreprises serieuses, il y a ce que l'on appelle des tests. Important les tests me direz-vous, mais oui, qu'en pensez-vous? sachez aussi que la doc c'est important !"
"je suis de bonne humeur ce matin!"
Allons de ce pas implementer VB dans KDE pour faire ouvrir des URL a Konqueror.
Vite, gerons correctement les exceptions et testons les pointeurs NULL.
Ce qui compte dans le libre, c'est la qualite du code. Et pas se reposer sur des techniques pour prevoir comment prevoir la meteo.
[^] # Re: Stop !
Posté par fabb . Évalué à 0.
Développer, coder n'est pas du bricolage. Un "#ifdef" n'est pas du bricolage. Il a un fonction très précise. Un "p++" n'est pas du bricolage. C'est du code ! C'est du bricolage si c'est du code mal foutu. Coder demande beaucoup de réflexion. Quand on développe, on ne pense pas seulement à "pisser du code". On se demande si ça va marcher ! C'est l'objectif non ? Quand on développe (et surtout dans le libre) on n'a pas avis d'avoir des utilisateurs sur le dos qui se plaignent de bugs.
On n'attent pas les test du département QA pour prendre en compte la qualité. Dans la majorité des projets libres, le développeur c'est aussi le département QA.
Toi tu penses que le codeur n'apporte aucune valeur à la qualité et que tout ce qui compte c'est ces "foutus" test.
Regardes Linux, la qualité est assuré à 90 % par les développeurs et pas par des tests unitaire ou autres trucs funants.
J'espère que tu apprécies leur "bricolage".
> 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"...
Tu mélanges tout. Le logiciel libre est gratuit. Pour MS, ce que n'aiment pas les gens, c'est payer pour être testeur (et sans avoir la possibilité de fouiller les sources et avoir la satisfaction de fixer un bug).
Tu comprends la nuance ?
Le libre c'est libre et personne te demande de faire des rapports bugs. On te le conseille, on t'y invite, mais tu n'a pas d'obligation.
Je vois un truc "marrant". Les "fans" des tests unitaires, qui semblent nombreux, font rarement du logiciel libre sinon il y aurait plus de tests unitaires dans le logiciel libre.
[^] # Re: Stop !
Posté par Philippe F (site web personnel) . Évalué à 2.
> libre sinon il y aurait plus de tests unitaires dans le logiciel libre.
Affirmation gratuite et mechante. Va voir sur ma page web, je fais du logiciel libre. Meme si ce n'est pas la prochaine killer app, je suis content et fier de ce que je fais. Et yzis a le potentiel pour etre la killer vim app.
L'engouement pour les tests unitaire est recent. Perso, j'ai decouvert ca il y a 3 ans avec XP. Je pense que c'est un peu similaire pour les autres ici. Donc je n'ai integre la notion dans mes projets libres que depuis 3 ans.
Mais depuis que je m'interesse au sujet, il y a plus de test unitaires dans le monde du logiciel libre. J'ai fait un qtunit (pas forcement mon meilleur projet), une suite de test unitaires pour lua (c'est deja mieux).
J'ai fait tous les tests unitaires et leur conception pour l'OS open source pour carte a puce jayacard (jayacard.sf.net).
Yzis beneficies d'une suite de test en C++ et d'une suite de test en lua, devines de qui elle vient ? C'est d'ailleurs une des raisons pour lesquelles il sera un meilleur editeur que vim a terme.
[^] # Re: Stop !
Posté par Anonyme . Évalué à 1.
Bla bla bla. J'évoquais les gens qui expliquent ici que leurs tests ce sont des bouts de code écrits à la va-vite dans leur coin pour être effacés après. Ou encore quelques petits 'if' placés dans des "#ifdef". La compilation conditionnelle c'est très bien, mais c'est pas fait pour faire des tests. Tu déformes vite les propos.
Je n'ai pas dit ça. J'ai simplement dit que les tests unitaires apportent une sacré floppée de bénéfices (gain de temps, passage à l'échelle, souplesse, ...). Tu déformes vraiment beaucoup les propos. Ah et puis laisse les développeurs de Linux où ils sont. Il font du très bon boulot, mais ça n'empêche pas de se prendre de sacrées régressions de temps à autre. Les tests unitaires ne sont pas la solution miracle, mais ce n'est pas parceque Linux n'a pas de tests unitaires que ça ne sert à rien dans les autres projets.
Oh une confusion libre / gratuit ! Le logiciel libre est souvent disponible gratuitement, mais la notion de prix est hors de sa définition. Maintenant je me plie devant la grandeur de ton esprit. Après tout je ne connais rien au logiciel libre ainsi qu'à son développement. Toi tu sais mieux que les autres de toute façon :-)
Les tests unitaires avec des frameworks adéquats sont une pratique qui se développe sérieusement depuis relativement peu (~2 ans). Pour un nouveau projet il est de très bon goût de s'en servir. En revanche pour un projet existant c'est plus difficile. On peut tester du nouveau code, mais difficilement écrire une suite efficace pour le reste de la base de code existante (fort couplage entre autres). Ce sera donc moins efficace.
Pour le reste, tu racontes vraiment n'importe quoi. Tes commentaires font pitié à lire, tu fais preuve d'une fermeture d'esprit hors-norme et la seule chose que tu sais faire pour tenter de crédibiliser ton discours est de te racrocher comme tu le peux à des références universelles (le Libre, Linux, ...).
Au fond tu es comme le 'H' dans 'Hawai' ...
[^] # Re: Stop !
Posté par TeXitoi (site web personnel) . Évalué à 2.
[^] # Re: Stop !
Posté par Anonyme . Évalué à 1.
# Il faudrait comparer ce qui est comparable...
Posté par jch . Évalué à 1.
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 (site web personnel) . Évalué à 2.
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
http://about.me/straumat
# distinguer logiciel OpenSource et logiciel OpenSource
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à 1.
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
[^] # Re: distinguer logiciel OpenSource et logiciel OpenSource
Posté par erik_lallemand . Évalué à 2.
Je te rejoins sur ce point de vue. Ayant bossé 70 heures par semaine en moyenne (*snifff*) pendant plus de 7 mois, dans une équipe de 3 personnes, je revendique le fait que la tenue des objectifs contractuels et la qualité de conception/développement constituent des données qui méritent des compromis mais qui ne sont pas toujours compatibles. Alors questions tests... ben non! pas de vrais tests. On développe une version très simplifiée du module final. Si on arrive a faire marcher "le truc", on continue le développement pour complexifier. Lorsque toutes les fonctionnalités sont présentes, on ouvre l'interface... on clique sur chaque bouton 1 ou 2 fois, et si ca marche... hop! validé! module suivant!
(...) mais peut être negatif si des crackers profitent du source pour rechercher des failles dans le but de les exploiter
C'est une question difficile à décider, donc probablement du domaine de l'opinion. Que le code soit ouvert ou non, l'existence d'une faille permet à une personne mal intentionnée de mal agir. J'ai tendance a rapprocher cette ouverture du code à l'ouverture des algorithmes de crypto. On permet à tout le monde d'éprouver la robustesse. Si ca tient, on considère que c'est bon. Si ca tient pas, on le sait rapidement, on (ré)agit rapidement, et on éprouve à nouveau la robustesse. Si la sécurité se limite à la détention d'un secret, on doit avoir rudement confiance dans les personnes qui détiennent le secret.
# Martin Michlmayr
Posté par imalip . Évalué à 6.
Plus de details sur son site : http://www.cyrius.com/research/index.html(...)
# Haute teneur en troll
Posté par XHTML/CSS inside (site web personnel) . Évalué à 1.
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).
# Entièrement d'accord, il faut augmenter la qualité des développements
Posté par David Mentré (site web personnel) . Évalué à 4.
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.linuxfr-france.org.invalid/~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 (site web personnel) . Évalué à 2.
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 . Évalué à -5.
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.
[^] # Re: je m'appelle pohrteukoi et je suis un nain
Posté par gc (site web personnel) . Évalué à 1.
# Si je peux me permettre
Posté par Wolf Ben . Évalué à -4.
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.
[^] # Re: Si je peux me permettre
Posté par dab . Évalué à 7.
Je suis vraiment gavé de devoir lire 2-3 fois les phrases d'une personne qui rédige n'importe comment pour la comprendre, tout en sachant qu'elle écrit sur un site fortement fréquenté.
# Les outils de tests
Posté par Cédric Girard (site web personnel) . Évalué à 4.
http://xp-france.net/cgi-bin/wiki.pl?ListeDesOutilsDeTest(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.