Pour ma part, je suis entièrement d'accord avec toi : la plupart du temps, que ce soit pour du proprio ou du libre, on développe toujours comme on faisait du soft dans les années 70. Il faut absolument que les développeurs de logiciel libre s'efforcent de faire un soft sans bugs, avec toutes les techniques possibles.
Par exemple, pour demexp, on utilise :
- un langage de haut niveau, OCaml, avec des fonctionnalités qui évitent certaines classes de bug (un garbage collector pour les bugs mémoires, l'inférence de type pour les bugs sur les structures de données, des exceptions pour les cas d'erreur, ...) ;
- 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.
# Entièrement d'accord, il faut augmenter la qualité des développements
Posté par David Mentré (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. É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.