>> 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).
[^] # 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).