<<< 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 !" >>>
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.
# Je ne suis pas d'accord
Posté par Guy Thiry . En réponse à la dépêche Démarche qualité et Logiciel Libre. É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.