> tu modifies le test unitaires pour inclure un certain nombre d'url tordues
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 ...
>> Le probleme c'est que les tests unitaires n'attrapent pour ainsi dire jamais les bugs de la vie réelle.
> 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).
Le probleme c'est que les tests unitaires n'attrapent pour ainsi dire jamais les bugs de la vie réelle. Eg, tu peut testunitairiser autant que tu veut les fonctions du noyau linux, vérifier qu'elles font ce qu'on attend d'elles, ça ne les aidera en rien à mieux supporter tel ou tel materiel. La qualité d'une fonction d'une ou d'un groupe de fonction n'induit pas le bon fonctionnement du logiciel !
Les LL misent généralement sur la période d'incubation (elle est souvent très longue) durant laquelle, effectivement les utilisateurs ont leur role à jouer. Mais c'est la condition pour un débug pertinent: un débug en conditions réelles.
Et ça (une longue période d'incubation) c'est très précisément ce que les sociétés developpant des logiciels propriétaires ne peuvent quasiment jamais se permettre.
Une autre méthode très généralement utilisé est la relecture et validation systèmatique des modifications du code source proposées. Relecture par non pas par une ou deux personnes (comme avec la méthode XP), mais par un grand nombre de developpeurs très pointus. Je te recommande à ce sujet de jetter un oeil au fonctionnement de la communauté de developpement d'OpenBSD ou d'Apache.
Je crois avoir lu récement (hum...) que les developpeurs mozilla/firefox étaient maintenant majoritairement du monde windows.
Je suis sur que le monde du shareware/freeware va s'éteindre progressivement car c'est un reste de l'époque pré-internet (dev non collaboratif) et surtout, à mesure que les LL leur offriront des opportunités (entendez: des projets motivants, comme l'ont étés mozillas et openoffice).
Dans tout les cas, les devs sous windows sont nombreux, et n'ont pas autant de projets que nous auquels participer.
Sans parler de la suite pf/pfsyn/carp/ifstated (intégrés dans les autres BSD), de sudo, de systrace (un patch existe pour le noyau linux), de spamd, ou encore des fonctions sécurisées de la libc (parfois reprises dans la glibc) comme mkdtemp, strlcat, strlcpy ...
En fait ils réimplémentent les services quand la qualité/sécurité du code existant ne leur convient pas.
Pas exactement. Ils ne synchronisent plus leur copie des sources avec celles d'apache.org (du fait du changement de licence).
Mais leur copie des sources d'apache évolue énormément, dans le sens de leurs objectif : améliorer la sécurité de l'ensemble (privsep, facilitation de l'audit etc.).
cf. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src/main/(...)
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par herodiade . En réponse à la dépêche Démarche qualité et Logiciel Libre. É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 herodiade . En réponse à la dépêche Démarche qualité et Logiciel Libre. É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).
# La démarche qualité existe - elle est seulement différente
Posté par herodiade . En réponse à la dépêche Démarche qualité et Logiciel Libre. É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: et wxWidgets dans tout ça ?
Posté par herodiade . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 0.
[^] # Re: Est-ce un bien ou un mal ?
Posté par herodiade . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 5.
heu ???
Et quelques autres unices aussi (au hasard, les *BSD). Halte au linuxocentrisme ;)
[^] # Re: Est-ce un bien ou un mal ?
Posté par herodiade . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 5.
Je suis sur que le monde du shareware/freeware va s'éteindre progressivement car c'est un reste de l'époque pré-internet (dev non collaboratif) et surtout, à mesure que les LL leur offriront des opportunités (entendez: des projets motivants, comme l'ont étés mozillas et openoffice).
Dans tout les cas, les devs sous windows sont nombreux, et n'ont pas autant de projets que nous auquels participer.
[^] # Re: openospfd.org et openhttpd.org
Posté par herodiade . En réponse à la dépêche OSPF débarque chez OpenBSD. Évalué à 4.
En fait ils réimplémentent les services quand la qualité/sécurité du code existant ne leur convient pas.
[^] # Re: openospfd.org et openhttpd.org
Posté par herodiade . En réponse à la dépêche OSPF débarque chez OpenBSD. Évalué à 2.
Pas exactement. Ils ne synchronisent plus leur copie des sources avec celles d'apache.org (du fait du changement de licence).
Mais leur copie des sources d'apache évolue énormément, dans le sens de leurs objectif : améliorer la sécurité de l'ensemble (privsep, facilitation de l'audit etc.).
cf. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src/main/(...)