(Courriels de diversion: <eclatante@refermez-insoupconnable.com> <obeiriez@louche-banaliserez.com> <transpercer@intriguiez-recupererent.com> <gagneras@clayonner-non-conformistes.com> <messies@fongibilite-battaient.com> <calligraphies@emouvante-luxera.com> <allouerais@allumerai-octroyee.com> <catapulterons@azyme-speculerez.com> <stabilises@sauvagine-merises.com> <demandera@parquees-resoudras.com> )
Bonsoir, marc Thirion a écrit : | Mais négliger les processus de dev, c'est salement risqué quand | même. Certes, mais le problème dans le libre est que chaque équipe fixe ses propres règles de développement... lorsque qu'elle s'en fixe. Déjà qu'il est difficile de rallier à sa cause des contributeurs, si on se montre trop exigeant et psycho-rigide sur le code soumis, on fait fuir les plus motivés et on se forge une réputation de geek associal. Il faut vraiment que la sécurité (ou la sûreté de fonctionnement) soit une problématique essentielle du projet pour que l'exigence de respect des normes de codage soit comprise et acceptée. Mais même lorsque ces règles sont fixées et soit-disant respectées, aucune entité de contrôle ne vérifie l'application stricte et effective de ces règles, ni même leur pertinence ou leur complétude. Dès lors, on ne peut se fier à la méthodologie de développement annoncée pour s'assurer de la fiabilité d'un logiciel libre. A titre d'exemple, j'ai effectué l'audit du serveur ProFTPd pour le compte d'une banque (utiliser du FTP pour des transactions bancaires est a priori une ineptie mais c'était au sein d'un réseau coupé du monde et chiffré). Au delà du code, il m'a justement semblé utile d'évaluer l'organisation de l'équipe de développement, ses méthodes de travail et ses règles de publication. Au départ, j'ai plutôt été agréablement surpris car le logiciel est bien architecturé, un ramasse-miette se charge de libérer en toute circonstance l'ensemble des ressources allouées et les développeurs de la « core team » exigent que les contributeurs utilisent les API mises à disposition et validées dans leurs modules. Ajoutons à cela moult petits détails bien sentis et ma première impression a été très positive. Par la suite, j'ai constaté qu'à plusieurs reprises dans l'histoire du projet, deux publications s'étaient succédées à 24 ou 48 heures d'intervalle, la seconde corrigeant une faille béhante de la première, décelée en quelques minutes par les premiers utilisateurs. Que fallait-il en conclure ? Que la validation du code par la core team était bien moins pointilleuse qu'annoncée et qu'aucune batterie de tests automatiques ne précédait la publication ou ne validait les développements à un instant ou un autre. Bref, entre la parole et le geste, il y avait un fossé et la méthodologie était perfectible. | L'idéal serait d'avoir un process raisonnablement lisible et | vérifiable pour produire le code, même en logiciel libre. « vérifiable », ce mot résume bien l'ampleur du problème. | Je ne vois pas de crontradiction là-dedans. Pas de contradiction mais un voeux pieux dans la mesure où, justement, je ne pense pas que dans la plupart des projets libres, le processus de production de code soit vérifiable (on peut faire une exception pour la core team d'OpenBSD dont la paranoïa est notoire ! (c;) | L'intuition que j'ai d'un moyen raisonnable de conjuguer tout ça est | de faire porter les efforts sur les phases amont et aval, en | choisissant de sacrifier la phase de codage, ce qui correspond au | processus de LL. Là, je ne vous suis plus. En amont et en aval de quoi ? Que veut dire « sacrifier la phase de codage » ? Cette expression me fait peur tellement j'ai souffert dans ma vie professionnelle de code bâclé ! J'ai déjà croisé une belle brochette d'applications spécifiées à outrance (mais mal à propos) et codées avec les pieds. Bonjour les dégâts ! | Mais, corrélativement, il faudrait un sas costaud sur les phases | aval, automatisé au max pour que ça ne coûte pas la peau des | couilles (à la portée de toutes les bourses, cependant) : normes de | programmation, contrôle qualité et tout ça. Ca existe : - d'un point de vue statique, on peut se faire peur en utilisant SPLint (ne pas utiliser sans avis médical ni sur un projet déjà bien avancé). - d'un point de vue dynamique, il faut exiger des batteries de tests unitaires et de charge automatisés (grâce à de tels tests, j'ai pu développer un cache applicatif complexe qui est maintenant exploité de manière intensive sans qu'un seul bug n'ait été signalé depuis sa livraison, voici presqu'un an). | Sans négliger la cohérence globale par une insistance sur la | traçabilité du code final vis-à-vis des exigences initiales. Là encore, on a un choc des cultures. Lorsqu'on demande à une SSII de développer un système embarqué pour l'Airbus A380, le cahier des charges est fixé au début du projet et le sprectre fonctionnel, minutieusement spécifié, devient quasiment inaltérable. Dans le libre, c'est bien connu, c'est le besoin des utilisateurs qui guide les développements. Or, ces utilisateurs sont progressivement acquis et les besoins sont donc progressivement établis (sans compter les ajouts jugés « funs » par les développeurs). | L'exigence d'automation permettrait d'infiltrer sans douleur les | contraintes dans la phase de codage (si c'est la machine qui | bosse...), puisque les rejets ultérieurs potentiels seraient | détectés au plus tot. C'est ce que je disais : vive les tests unitaires de validation et de non régression automatisés ! A ce sujet, j'ai une certitude qui donnerait des sueurs froides à toute entité habituée aux approches classiques de la validation de code : je suis persuadé que l'on peut obtenir une application d'une grande fiabilité en pilotant le projet à la sauce eXtreme Programming ! Sébastien -- Sébastien Dinot, sdinot@april.orgSecrétaire de l'APRIL (http://www.april.org) Association pour la Promotion et la Recherche en Informatique Libre -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>