Je suis 100% d'accord avec tout ce que JPz vient de dire.
Je ne rajouterai qu'une chose : les tests unitaires, essayer les avant de les critiquer. Vous serez surpris de voir a quel point ca vous fait gagner du temps.
Rien n'empeche de mettre des contrats et de faire quand meme des tests unitaires. Bon, ca devient plus lourd en terme de dev mais ca n'est pas impensable.
<< 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.
>>
C'est un stereotype courant. Tout depend bien sur de l'attention que tu portes a tes test unitaires. Mais si tu lis les bouquins sur XP, tu verras que dans les exemples, ils testent toujours les conditions limites.
Si je devais ecrire un test pour strcmp, je ne commencerai pas par verifier que srcmp("toto","toto") renvoie 0. Je commencerai par verifier que strcmp( NULL, "toto" ) ne plante pas, ainsi que strmp( NULL, NULL) et strcmp( "toto", NULL).
Il est evident qu'on ne peut pas penser a toutes les situations dans les tests unitaires. Mais il est parfois bien plus facile de simuler des situations tordues via des tests unitaires que via le logiciel, et donc de trouver des bugs subtils. Je l'ai vu dans la pratique, avec des situations que j'ai cree de toute piece sous forme de test, que je n'aurai jamais pu trouver dans la pratique.
Dans l'exemple que tu donnes, une URL tordue dans apache. Ok, le test unitaire initial ne contenait pas ce cas. Une fois le bug reporte, tu modifies le test unitaires pour inclure un certain nombre d'url tordues. Et c'est beaucoup plus facile a faire que d'essayre de rentrer les url tordues dans apache.
En ce qui concerne les tests de securite et de buffer overflow, en general, ces problemes sont adresses par des regles de codage et de conception plus que par des tests unitaires.
> non aux attendues du developpeur (tests unitaires).
Les bon developpeurs ont des attentes tres tres pessimistes sur leurs entrees et vont le refleter dans leur test.
> Après, il faut voir si le temps passé à développer les tests unitaires est inférieur au temps passé à chercher le bug. J'imagine que dans ce cas, ça aurait été rentable. Ce n'est pas toujours le cas.
J'utilise des tests unitaires depuis 4 ans et je n'ai pas encore vu de situation ou des bugs seraient plus long a corriger qu'ecrire une suite de test unitaire.
Une suite de test unitaire apporte beaucoup de choses en terme de fiabilite. C'est un atout enorme pour la maintenance.
Il faut aussi voir que meme sans test unitaires, les developpeurs ont ecrits des tests pour leur code. La difference, c'est que ces tests ne sont pas automatises et ne sont pas archives. Ils sont perdu des que le code est ecrit
> les phases de tests qualité c'est bien gentil [...] ça marche très mal dès que la combinatoire est importante
C'est l'argument typique des mecs qui ne veulent pas tester. On parle de test unitaire. Si ta fonctionnalite unitaire a plus de 50 etats possibles, il y a un tres tres gros probleme de conception et je te conseille de separer ta fonctionnalite dans plusieurs classes contenant chacune des fonctinnalites elementaires. On appelle ca de l'encapsulation dans le monde de la programmation objet.
C'est pas toi qui parlait de bonne conception ?
> dès que le logiciel en question peut être mis en oeuvre dans des situations très variées
Si le logiciel doit etre soumis a des situations tres tres variees, il y a de grandes chances que le cerveau du developpeur n'arrive pas a lui tout seul a ecrire du code qui resistera a toutes ces situations. Dans ce cas, il est imperatif:
- d'essayer d'isoler separement la variation de ces situations (en general, c'est possible)
- de mettre en place des tests pour reproduire ces differentes situation. Dans un cas aussi complexe que tu le decris, il est naif de se dire "le developpeur a pense a tout", alors que le developpeur lui-meme sera bien plus rassure si il est en mesure de tester son code dans les situations variees.
> dès que la latitude des utilisateurs est très importante.
Ben voyons. Comme l'utilisateur peut tout faire, tu ne peux rien tester ? L'utilisateur fonctionne par taches elementaires donc tu peux tester chacune des taches elementaires.
> Combien de milliers de pages faudrait-il pour décrire un plan de test complet sur un client de messagerie façon Thunderbird ou sur
> Open Office Writer ? Quelques millions ? Et combien d'environnements de test ?
Un seul environnement de test suffit. Tu decoupes tes tests en hierarchie de facon a pouvoir selectionner ceux que tu veux faire tourner pendant que tu touches a une fontionnalite specifique.
Pour thunderbird, c'est plutot facile. Tu decoupes en fonctionnalite:
- les filtres: je cree un filtre X, un message qui doit etre filtre et un message qui doit passer a traver, je verifie que c'est le cas.
- recherche de msg : laisse a titre d'exemple
- pop3: tu montes un serveur pop3 de test ou mieux, tu en simules un (quelques lignes de python suffisent) et tu verifies que un message stocke sur le serveur est bien rapatrie par ton client, et surtout, qu'il a envoye les bonnes requets dans l'ordre. Apres, tu elabores, sur ton serveur pipo, tu mets un mauvais message, tu supprimes le message, tu reponds des conneries au requetes et tu verifie que thunderbird ne perd pas les pedales.
- smtp : tu montes un serveur smtp ou tu en ecris un reduit. Tu verifies que si tu envoies un message, il arrive bien sur le serveur smtp
- imap: idem
....
Pour OpenOffice, c'est pareil. Le seul truc que tu ne peux pas tester, c'est le rendu exact d'une police a l'ecran et a l'impression. En dehors de ca, tu peux tout tester. Je te donne des exemples de test:
- je selectionne un texte dans un paragraphe, je lance "mise en italique" et je verifie quand dans la representation interne du document, ce morceau de texte est mis en italique
- je selectionne un texte avec un style donne dans mon document et j'active la fonction "appliquer au style courant". Je verifie ensuite que les parametres de style du style courant ont ete mis a jour avec le style que j'ai selectionne
- j'ouvre un document sxw, je le sauve en word, je le recharge en word, je le re-sauve en sxw: le document final et le document initial doivent avoir le meme contenu modulo un nombre de champs _identifies_ qui ne sont pas pris en compte dans le format word
- j'ecrie un mot mal orthographie, je verifie que la fonction de correction va me sortir un mot correctement orthographie du dictionnaire.
etc, etc.
Comme tu vois, rien d'insurmontable.
Apres, sur l'explosion combinatoire des tests, ca ne s'applique pas aux tests unitaires : d'une part les fonctionnalites testees sont petites, d'autre part c'est le developpeur qui ecrit le test. Il sait quelle partie de son code il faut cibler pour lui chercher des embrouilles.
En terme de quantite de code, j'ai en general autant de code de teste que de code de programme. Mais ca ne me prend pas plus de temps a ecrire qu'un programmeur normal, car le programmeur normal aussi fait des tests. Sauf que les siens ne sont pas automatises et integre dans le projet.
C'est sur que tester un projet existant, c'est dur puisque tu as perdu tous les tests ecrits par le developpeur pendant sa phase de dev. Mais integrer les tests au dev, ca ne coute pas grand chose.
Le gain vient surtout au fur a mesure que le projet avance, ou tu peux completement te reposer sur les test unitaires. De facon non surprenantes, quand je decide de ne pas faire de test unitaire sur un morceau de programme, c'est justement la que je vais trouver des bugs par la suite et regrette ma decision.
> Après il faut faire des choix : les ressources consommées par l'assurance qualité seraient-elles mieux utilisées à faire des revues de codes, des re-codage le cas échéant, le tri et l'analyse des rapport de bogues ?
Non. Le cout de correction d'un bug croit exponentiellement en fonction du temps entre lequel il est decouvert et le moment ou la fonctionnalite a ete codee. On gagne donc un temps precieux a detecter les bugs tres tot et a s'eviter des rapports de bug qu'il faut gerer, reproduire, discuter, fermer.
J'ajoute que quand tu as des suites de tests unitaires, il est facile de s'appuyer dessus pour faire des suites de tests fonctionelles. Quand on te reporte un bug, au lieu de corriger, tu construits d'abord un test dans ta suite fonctionelle pour mettre le bug en evidence, puis tu corriges. Tu es sur que le bug ne reviendra _jamais_, tu as un test pour le prouver.
Qui plus es, tu as mentionne la notion de logiciel actif et bien maintenu. Un logiciel qui bouge, c'est un logiciel dont l'architecture evolue souvent dans le temps. Tu peux meme voir que tous les projets majeurs sont re-ecrits tous les deux ou trois ans (Gnome 1 -> Gnome 2, KDE 1 -> KDE 2, gimp1 -> gimp2, apache -> apache2, ...). Les tests unitaires prennent alors une valeur encore plus grande : on peut tout peter a l'architecture, en garantissant que les fonctionnalites sont encore la.
<< A titre d'info, je trouve les dernières versions de la suite bureautique d'un-grand-éditeur-américain-que-nous-connaissons-bien _truffées_ de bogues
>>
Je ne peux pas dire, je ne l'ai pas utilisee depuis deux ans.
Ok, nfs v4 est bien teste. J'en suis super content et je prends ca comme un signe que les mentalites evoluent lentment. Mais a cote de nfsv4, combien de pans entier du noyau sans aucune suite de test automatisee ?
Prend un exemple, le support des materiels exotiques. Il devrait y avoir une suite de tests unitaires qu'on pourrait faire tourner sur un driver quelconque. Pour l'instant, la facon de tester un driver du noyau, c'est soit de faire tourner le noyau de facon normale, soit pour chaque developpeur de s'ecrire une ou deux fonctions de test. Je suis choque de ne pas voir de repretoire test dans les sources du noyau.
Par exemple, je suis dans une situation similaire au cas du driver : je dois supporter plusieurs lecteurs de carte a puce sans-contact. A chaque fois que je rajoute un lecteur, je fais tourner une suite de test generique qui va tester toutes les fonctionnalites generiques du lecteur et va donc valider que mon implementation du support du lecteur est correct dans tout
Pourquoi on ne retrouve pas ce genre de chose dans les sources du noyau ? Avec ca, on pourrait avoir une suite de test revue et amelioree par tout le monde, donc qui serait de tres bonnes qualites.
Et quand un materiel exotique ne marche pas, le developpeur du driver pourrait dire au mec: fait tourner la suite de test et envoie-moi les resultats. Ca l'aiderait surement a faire un diagnostic plus precis du probleme.
Je prends un autre exemple que je connais bien : KDE. Combien de suties de test dans KDE ?
- une suite de test pour kurl
- une suite de test pour taglib
- une suite de test introduite recemment pour khtml.
C'est plutot pathetique. Ca change doucement mais faut pas etre presse.
Si t'as une phase de test qui vient plusieurs annees apres la phase de developpement, c'est du suicide. Avec un raisonnement comme ca, meme les bugs decouverts en phase de developpement sont couteux puisque c'est du code qui a ete developpe il y a 5 ans.
> (je ne parle pas de test unitaire)
Dans ce cas precise. Dans la plupart des projets, la phase de test fonctionelle et l'integration sont faites a la fin. C'est aussi une erreur qu'il faut essayer de corriger, meme si ce n'est pas toujours facile (pour la phase d'integration).
Sans meme faire reference a XP, toutes les methodes de developpement recommandent de faire des phases de tests intermediaires (water fall, cycles en plusieurs V).
Donc on peut reformuler ta phrase "dans le cas ou un projet ne respecte aucune methodologie qualite et fait des tests 3 ans apres le dev, on sait depuis tres longtemp qu'un bug decouvert en phase de test coute tres cher".
Ce qu'on sait surtout depuis tres longtemps, c'est que plus ton bug est decouvert tard, plus il coute cher. Donc il faut tester tres tot et plutot que de sortir une anerie pour decredibiliser les tests (les bugs decouverts en phase de test coutent cher), je pense que tu devrais integrer cette notion de tester le plus tot possible dans une demarche de qualite globale (qui va avec la demarche de bonne conception que tu sembles deja preconiser).
Et comme je l'ai deja dit, une fois que tu as beaucoup de tests unitaires, il est tres facile de monter des tests fonctionnels qui s'appuient sur ces tests unitaires, donc de lancer des tests fonctionnels tres tot sur le projet
Boah, Gtk est maintenu principalement par des gens payes par Redhat, donc je pense qu'il continuera a etre maintenu, car Redhat n'a pas l'intention de passer a Qt.
Moi je connaissais le terme de mock. C'est plus qu'un bouchon dans ce cas et je pense plus que l'equivalent du "stub". Le but est de faire evoluer le comportement du morceau remplace.
cf www.easymock.org pour une solution en java. Pour python, on peut trouver ca dans le python cookbook, sur le site d'active state. Une implementation de mock en moins de 100 lignes, impressionnant.
D'un autre cote, le commentaire n'est pas necessairement le reflet de la qualite d'un logiciel. Avec des fonctions bien nommes un chemin algorithmique clair, on arrive a de bien meilleur resultats qu'un commentaire. Si tu as besoin de mettre 5 lignes de commentaire pour expliquer ce que tu fais, c'est un peu louche.
Exemple:
/* we call this function to check for incorrect syntax */
check_string_1( s );
/* we call this function to check for wrong attributes references */
check_string_2( s );
A comparer a
check_string_for_bad_syntax( s );
check_string_for_wrong_attribute( s );
Je prefere nettement la seconde version, bien qu'elle soit moins commentee.
> Le probleme c'est que les tests unitaires n'attrapent pour ainsi dire jamais les bugs de la vie réelle.
C'est pas vrai du tout. 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.
Ensuite, il n'y a pas que le kernel dans la vie, il y a plein de logiciels libres qui seraient tres faciles a tester avec des tests unitaires et qui auraient beaucoup a y gagner, mais qui ne le font pas.
> La qualité d'une fonction d'une ou d'un groupe de fonction n'induit pas le bon fonctionnement du logiciel !
C'est faux aussi. Le driver dedie purement a un materiel est plus dur a tester (mais c'est pas du tout impossible) que d'autres parties. Cependant, la qualite d'un groupe de fonction induit grandement la qualite globale d'un logciel. Si on prend l'exemple du kernel:
- la qualite des fs est independante de la qualite des drivers de disque dur. C'est tres facile de tester un FS et c'est d'ailleurs ce qui est fait poru ext3 et reiser
- il y a d'autres parties du noyau facile a tester mais qui ne le sont pas ou du moins pas via des tests unitaires : scheduler, gestion de la memoire.
Il faut voir que des que tu n'es plus a 1 cm du materiel, c'est a dire des que tu sors d'un drivers, tout est testable. Il suffit de faire un pseudo driver dont tu modfifieras le comportement dans tes tests et via lequel tu verifieras que le reste du systeme se comporte correctement.
> Les LL misent généralement sur la période d'incubation
Pour des tres gros projets, c'est peut-etre le cas. 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 et c'est a ca que servent les tests unitaires.
> Mais c'est la condition pour un débug pertinent:
Je ne suis pas d'accord du tout. Seul une tres petite minorite de bug ne peut etre decouvert que dans des conditions reelles. Une tres grande majorite de bug peut-etre decouvert durant la phase de dev. Le noyau ne fait pas exception. C'est l'argument typique des gens qui ne veulent pas tester: "Je ne peux pas tester ca". Apres, tu leurs presentes des methodes pour qu'ils puissent tester ce qu'ils ne peuvent pas tester mais ils refusent en general des les utiliser parce que ca les obligerait a changer leurs habitudes et a faire evoluer un poil leur architecture.
> 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.
C'est vrai qu'on a tout le temps pour attendre les nouvelles versions stables de debian, ca ne decredibilise pas du tout le projet .
<<
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.
>>
Ceci est vrai sur un certain nombre de tres gros projets, mais pas sur beaucoup. Typiquement, pour le noyau, Linus relit les patchs mais l'inverse est rarement vrai.
La relecture s'attache en general a trouver des erreurs de conception. C'est rare qu'on leve des purs bugs comme ca.
Ce que tu dis est complementaire des tests unitaires, mais ne peut en aucun cas s'y substituer.
Et tu n'a jamais de coup de fatigue ? De faute d'inattention ? D'erreur de frappe (oh, j'ai mis == eu lieu de =) ?
> Plus sérieusement, les tests ne sont qu'une toute petite partie d'un processus qualité global.
Alors la, je ne suis pas tu tout d'accord. Bien sur, une bonne conception est essentielle, mais une bonne conception ne va apporter que des garanties de bon fonctionnement globaux (le logiciel pourra faire X ou Y). Il y a toujours un moment ou tu codes et le [1] _seul_ moyen de valider du code, c'est des tests unitaires.
Donc les tests sont une partie essentielle et fondamentale du processus qualite.
Tu peux avoir une conception magnifique UML et tout le bazar, et un logiciel code comme les pieds qui plante toutes les 10 secondes. Oui, la conception etait bonne, mais l'implementation etait a chier.
<<
On sait depuis _très_ longtemps qu'un bug découvert en phase de test coûte _très_ cher. Donc depuis bien longtemps, les bons chefs de projets mise à 90 % sur la conception et le développement.
>>
La, tu dis n'importe quoi. Tu assimiles erreur de conception et bug.
Un bug, c'est une fonctionnalite avec une erreur (= a la place de ==). Dans une bonne approche ou tu codes tes tests avant ou pendant que tu codes tes fonctionnalites, un bug a un cout de correction extremement faible. Tu es dans le code, tu vois tout de suite ce qui ne va pas, personne n'est impacte en dehors de toi, et tu corriges dans la minute ou dans la journee.
Au fur a mesure que tu avances dans la phase de vie du produit, un bug a un cout de correction exponentiel. Sur un produit deja sorti, c'est dramatique.
Je ne sais pas ou tu as vu qu'un bug decouvert en phase de test coutait cher, mais c'est n'importe quoi.
Une erreur de conception en revanche, ca coute tres cher, je suis d'accord. Mais l'avantage des tests unitaires, c'est que ca te permet de corriger ce type d'erreur a moindre cout. En effet, une erreur de conception te conduit a refaire l'architecture de ton soft. Et la, tu sors ta batterie de 300 tests unitaires qui marchait avec l'ancienne architecture. Tu la valides avec la nouvelle acrchitecture et tu es sur que tu n'as perdu aucune fcontionnalite ni introduit aucun nouveau bug. Des certitudes comme ca, ca n'a pas de prix.
1] je sens qu'on va me parler de preuve formelle. Aller, combien d'entre vous savent faire de la preuve formelle sur un logiciel ? Combien ont vu des logiciels libres avec des preuves formelles ? Connaissez vous le cout de mise en place d'une preuve formelle ? La preuve formelle, c'est super mais en pratique, pour des logiciels a la con, c'est pas la panacee.
> - c'est parfois le bordel à réaliser et si on a pris soin dans les unitaires lors du développement, les choses se passent bien.
Plus tu testes mieux ca se passe. Pour moi, il n'y a pas de bonne raison de ne pas tester un module que tu pourrais tester.
<<
Je suis un "accros" des :
#ifdef DEBUG
assert (....)
#endif
>>
Moi j'en suis parvenu a la conclusion qu'il n'y a pas de raison de supprimer les assert en mode release. L'overhead est completement negligeable.
D'ailleurs, tu peut deja t'epargner quelques lignes de code avec un:
#ifdef DEBUG
#define ASSERT( toto ) assert( toto )
#else
#define ASSERT( toto )
#endif
et utiliser ASSERT() partout.
Perso, je suis plus dans une optique d'utiliser des logs pour les assert, qui ne seront pas affiches par defaut en mode release mais que je peux activer a tout moment. Si un client a un probleme, je lui dis de lancer le soft en mode debug et de m'envoyer le log.
Fournir les sources d'un logiciel, cela a un interet si il y a un retour en terme de contribution, diffusion, correction de bugs. Si ca n'apporte aucun des ces elements, il n'y a aucun interet a fournir les sources.
On le voit dans le cas de TheKompany. Non seulement les gens ont hurles parce que le logiciel n'etait pas gratuit, mais en plus il n'y a aucun retour positif.
Donc je ne vosi pas pourquoi je donnerai les sources de mon logiciel commercial a mon client. Lui permettre de se passer de moi, d'installer mon produit sur 7000 postes en ne payant qu'une seule licence, lui permettre de contacter une boite de service pour faire la maintenance a ma place sur mes propres sources, ce ne sont pas des choses qui m'`interessent. Au contraire, ca va faire couler ma boite et mettre tous mes employes au chomage.
Les seuls modeles viables commerciaux + libres sont ceux ou le libre fait vraiment partie du business model et ne vient pas en plus. Dans le cas de trolltech, la version libre leur sert de support de promotion de leur toolkit aupres des developpeurs.
Si je fais un logiciel qui me prend 3 ans a developper et que je vends 100 kF par licence, imagine combien j'ai a perdre en le mettant en libre.
J'avoue que les qstring, c'est en effet parfois un peu lourd. Je me suis deja fait mordre une ou deux fois.
[Sous-classer en C++]
Je vois pas trop ce que tu veux dire par la. Sous Qt, sous-classer est une technique utilisee tres tres couramment. Ca correspond a la realite d'un besoin : tu as souvent besoin de specialiser un composant pour une utilisation legerement differente de l'utilisation de base. C'est une des forces de Qt que de permettre ce genre de chose tres facilement.
J'ai vu des toolkits ou on ne peut jamais modifier le comportement des widgets de base, et ou on est donc obliger de les recoder a la main quand on veux les specialiser.
Par contre, je ne comprends pas ta remarque sur le C++. En PyQt, tu peux tout faire en python, pas besoin de C++.
Sinon, pour le futur de PyQt, je pense que Phil Thompson va s'aligner mais ce n'est pas sur.
Honnetement, au lieu de sauter sur le troll proprio/libre, vous devriez reflechir a la facon d'augmenter la qualite des logiciels libres.
Ce que je partage avec l'auteur de cette news comme point de vue, c'est que les tests unitaires ne sont pas assez utilise en logiciel libre. C'est un tort car ca permet de faire evoluer tres rapidement l'architecture d'un logiciel tout en conservant sa qualite. Si je prends une appli comme grisbi, il y a eu des versions completement inutilisables tellement elles etaient buggees. Pourtant, c'est pas dur d'ecrire des tests unitaires pour les fonctionnalites qui posaient probleme.
Depuis que je suis devenu un integriste du test unitaire, je constate que j'ai beaucoup moins de bugs sur mes projets et qu'ils sont beaucoup plus faciles a faire evoluer. Constation corroboree par d'autres convertis du test unitaire.
Alors le test unitaire, mangez-en. On peut en faire en C (cunit), en C++ (cppunit), en pyton (unittest), en java (junit, easymock), et C#, en ruby et en tout ce que vous voulez. L'important est d'avoir une suite de test automatisee.
Le contre-argument classique est "mais on ne peut pas tester cette partie-la". Avec un peu d'astuce, on peut tout tester mais il faut s'en donner les moyens. Par exemple, j'ai peu tester un protocole de communication radio ou il fallait simuler des conditions radio anormales. Je travail aussi sur du code embarque ou il faut tester le comportement d'un programme compile avec de l'overlay (pas de notion de fonctionr re-entrante, les variables locales ne sont pas sur la piles mais a des emplacements fixes). Ca aussi, on a put tester sans probleme a condition de reflechir a la facon d'aborder le probleme.
Ce qui est genial, c'est qu'une fois que les briques de bases ont beaucoup de tests unitaires, c'est tres tres facile de faire des tests fonctionnels de tres haut niveau, en assemblant des briques de tests unitaires.
Par exemple, une fois que j'ai eu mon protocole de communication debugge, j'ai pu teste l'ensemble de mon programme avec introdution de conditions radio anormales et autres petits problemes. J"etais doublement confiant dans sa qualite.
Moi j'ai des contre-exemples. Par exemple, depuis 2 ans, il y a un bug avec patch attache sur kmail pour utiliser le composant editeur de KDE au lieu d'utiliser systematiquement l'editeur de kmail. Ca nous permettrait d'utiliser yzis ou vi dans kmail.
Bah, les developpeurs s'en foutent. Pourtant le bugs a pas mal de votes, et j'ai rencontre plein de gens interesses par la fonctionnalite.
Au final, si personne ne veux corriger un probleme, il ne sera pas corrige. Le developpeur ne considere que ce n'est pas important et puis voila.
> Entretenir la confusion, c'est propager l'idee que le libre veut dire gratuit,et forcement gratuit. Malheureusement, c'est souvent l'idee que le grand public a du libre.
Oui, bien sur. Je sais que tout le monde ici est persuade que c'est le cas mais quand on regarde les cas concrets on se marre.
Combien de boite font du libre commercial ? Disons MySql, Trolltech, Mandrake, Red Hat, Suse pour les tres gros. En cherchant parmi les petits, on doit arriver a une 20aine ou une 30aine.
A cote de ca, combien de logiciels libres ? Tu ne sens pas comme un decalage ?
Combien de gens savent que quelques produits de TheKompany sont GPL mais dont les sources ne sont pas distribuees ? Dans ce cas, ces softs sont des bides, les gens ont hurle parce que ce n'etait pas gratuit mais GPL et personne n'a jamais contribue.
J'ai cree avec succes deux entreprises et ca fait aussi pas mal d'annees que je fais du logiciel libre. Je suis intimement persuade que faire de l'argent avec du libre reste extremement difficile et ne peut se faire quand des conditions tres particulieres sont reunies.
Le commercial + libre reste une exception exceptionelle, et j'en suis desole mais c'est comme ca. Dans mes boites on fait entre 100% et 95% de logiciel proprio et c'est ce qui nous permet de vivre.
> Les développeurs d'applications GPL seraient bien marrons si Trolltech décidait de passer les prochaines versions de QT en non libre !
Ben non, Qt passerai automatiquement en licence BSD. cf commentaire plus bas et cf la Free-Qt Foundation.
Gtk est la, donc c'est un peu bete de se dire qu'on ne doit plus l'utiliser. Cela dit, je reste persuade qu'ecrire un toolkit graphique en C est une anerie et fait perdre un temps monstreux en dev aux developpeurs.
Si MDI et consorts poussent d'autres langage de programmation (mono, java, python, ...) c'est bien parce qu'il semble que le C soit un peu depasse.
Ca me faisait marrer de lire le blog de MDI qui etait epate de la vitesse avec laquelle ils developpaient en C# + gnome. Et oui, bienvenu de le monde de l'objet, du polymorphisme, des garbage collector, des constructeurs et des destructeurs et de l'heritage.
Si vous voulez vous marrer un jour, regardez la quantite de code Gtk qu'il faut pour ecrire l'equivalent:
class MyWidget: public QWidget
{
public:
MyWidget( QWidget * p) : QWidget(p) {}
public slots:
void my_slot(int p1, int p2, int p3);
};
D'apres mes souvenirs (en gtk1), ca tape dans les 50 lignes de code, dont la moitie compose de macro sur des structures sans aucune verification de type.
> Trolltech fait l'amalgame entre "commecial" et "proprietaire"
Mouai. Prenons le nombre d'applis open source commerciales et divisons le par le nombre d'appli open source benevoles. Maintenant, faisons la meme operation avec le nombre d'appli open source commerciale que nous divisons par le nombre d'appli close source commerciales.
Je serai surpris qu'un seul de ces chiffres depasse les 0.01% . Certe, Trolltech fait un amalgame, mais il peut se defendre par les chiffres.
> Concernant la gestion des evenements (cf. lien) Fox offre plus de souplesse (mais moins que Gnustep & co : Aie un troll est laché) pour des langages comme python
Mouai. Je code tous les jours en PyQt (c'est mon boulot) et je n'ai pas eu la sensation de manquer de souplesse, au contraire. Le systeme signal/slot porte a python est beaucoup plus souple que celui du C++ puisque n'importe quelle methode ou fonction python peut servir de slot (callback).
<< b) Si tu savais utiliser CreateProcess et avais la la doc de cet API, tu saurais que nombre de ces arguments peuvent etre a NULL et qu'au final c'est pas plus complique a utiliser qu'un API equivalent sur Linux
>>
Desole, mais meme si tous les arguments sont a NULL, l'api reste plus compliquee. C'est un probleme de l'api windows que tu ne peux pas nier.
Sous qt, je peux lancer un processus sans consuler la doc. Sous windows, je dois la relire trois fois pour etre sur que j'ai pas mis un NULL au mauvais endroit.
<<c) CreateProcess c'est un des nombreux APIs te permettant de lancer des processus, t'es libre d'utiliser d'autres APIs qui te permettent de faire des choses plus simples, plus simplement. >>
Ah ouai ? Et tu peux me dire ou on trouve cette api miracle ? Parce que quand on cherche sur le msdn, on tombe toujours sur CreateProcess.
[^] # Re: Stop !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 4.
Je ne rajouterai qu'une chose : les tests unitaires, essayer les avant de les critiquer. Vous serez surpris de voir a quel point ca vous fait gagner du temps.
[^] # Re: Ah oui mais...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
>>
C'est un stereotype courant. Tout depend bien sur de l'attention que tu portes a tes test unitaires. Mais si tu lis les bouquins sur XP, tu verras que dans les exemples, ils testent toujours les conditions limites.
Si je devais ecrire un test pour strcmp, je ne commencerai pas par verifier que srcmp("toto","toto") renvoie 0. Je commencerai par verifier que strcmp( NULL, "toto" ) ne plante pas, ainsi que strmp( NULL, NULL) et strcmp( "toto", NULL).
Il est evident qu'on ne peut pas penser a toutes les situations dans les tests unitaires. Mais il est parfois bien plus facile de simuler des situations tordues via des tests unitaires que via le logiciel, et donc de trouver des bugs subtils. Je l'ai vu dans la pratique, avec des situations que j'ai cree de toute piece sous forme de test, que je n'aurai jamais pu trouver dans la pratique.
Dans l'exemple que tu donnes, une URL tordue dans apache. Ok, le test unitaire initial ne contenait pas ce cas. Une fois le bug reporte, tu modifies le test unitaires pour inclure un certain nombre d'url tordues. Et c'est beaucoup plus facile a faire que d'essayre de rentrer les url tordues dans apache.
En ce qui concerne les tests de securite et de buffer overflow, en general, ces problemes sont adresses par des regles de codage et de conception plus que par des tests unitaires.
> non aux attendues du developpeur (tests unitaires).
Les bon developpeurs ont des attentes tres tres pessimistes sur leurs entrees et vont le refleter dans leur test.
[^] # Re: Ah oui mais...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 4.
J'utilise des tests unitaires depuis 4 ans et je n'ai pas encore vu de situation ou des bugs seraient plus long a corriger qu'ecrire une suite de test unitaire.
Une suite de test unitaire apporte beaucoup de choses en terme de fiabilite. C'est un atout enorme pour la maintenance.
Il faut aussi voir que meme sans test unitaires, les developpeurs ont ecrits des tests pour leur code. La difference, c'est que ces tests ne sont pas automatises et ne sont pas archives. Ils sont perdu des que le code est ecrit
[^] # Re: Complexité
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.
C'est l'argument typique des mecs qui ne veulent pas tester. On parle de test unitaire. Si ta fonctionnalite unitaire a plus de 50 etats possibles, il y a un tres tres gros probleme de conception et je te conseille de separer ta fonctionnalite dans plusieurs classes contenant chacune des fonctinnalites elementaires. On appelle ca de l'encapsulation dans le monde de la programmation objet.
C'est pas toi qui parlait de bonne conception ?
> dès que le logiciel en question peut être mis en oeuvre dans des situations très variées
Si le logiciel doit etre soumis a des situations tres tres variees, il y a de grandes chances que le cerveau du developpeur n'arrive pas a lui tout seul a ecrire du code qui resistera a toutes ces situations. Dans ce cas, il est imperatif:
- d'essayer d'isoler separement la variation de ces situations (en general, c'est possible)
- de mettre en place des tests pour reproduire ces differentes situation. Dans un cas aussi complexe que tu le decris, il est naif de se dire "le developpeur a pense a tout", alors que le developpeur lui-meme sera bien plus rassure si il est en mesure de tester son code dans les situations variees.
> dès que la latitude des utilisateurs est très importante.
Ben voyons. Comme l'utilisateur peut tout faire, tu ne peux rien tester ? L'utilisateur fonctionne par taches elementaires donc tu peux tester chacune des taches elementaires.
> Combien de milliers de pages faudrait-il pour décrire un plan de test complet sur un client de messagerie façon Thunderbird ou sur
> Open Office Writer ? Quelques millions ? Et combien d'environnements de test ?
Un seul environnement de test suffit. Tu decoupes tes tests en hierarchie de facon a pouvoir selectionner ceux que tu veux faire tourner pendant que tu touches a une fontionnalite specifique.
Pour thunderbird, c'est plutot facile. Tu decoupes en fonctionnalite:
- les filtres: je cree un filtre X, un message qui doit etre filtre et un message qui doit passer a traver, je verifie que c'est le cas.
- recherche de msg : laisse a titre d'exemple
- pop3: tu montes un serveur pop3 de test ou mieux, tu en simules un (quelques lignes de python suffisent) et tu verifies que un message stocke sur le serveur est bien rapatrie par ton client, et surtout, qu'il a envoye les bonnes requets dans l'ordre. Apres, tu elabores, sur ton serveur pipo, tu mets un mauvais message, tu supprimes le message, tu reponds des conneries au requetes et tu verifie que thunderbird ne perd pas les pedales.
- smtp : tu montes un serveur smtp ou tu en ecris un reduit. Tu verifies que si tu envoies un message, il arrive bien sur le serveur smtp
- imap: idem
....
Pour OpenOffice, c'est pareil. Le seul truc que tu ne peux pas tester, c'est le rendu exact d'une police a l'ecran et a l'impression. En dehors de ca, tu peux tout tester. Je te donne des exemples de test:
- je selectionne un texte dans un paragraphe, je lance "mise en italique" et je verifie quand dans la representation interne du document, ce morceau de texte est mis en italique
- je selectionne un texte avec un style donne dans mon document et j'active la fonction "appliquer au style courant". Je verifie ensuite que les parametres de style du style courant ont ete mis a jour avec le style que j'ai selectionne
- j'ouvre un document sxw, je le sauve en word, je le recharge en word, je le re-sauve en sxw: le document final et le document initial doivent avoir le meme contenu modulo un nombre de champs _identifies_ qui ne sont pas pris en compte dans le format word
- j'ecrie un mot mal orthographie, je verifie que la fonction de correction va me sortir un mot correctement orthographie du dictionnaire.
etc, etc.
Comme tu vois, rien d'insurmontable.
Apres, sur l'explosion combinatoire des tests, ca ne s'applique pas aux tests unitaires : d'une part les fonctionnalites testees sont petites, d'autre part c'est le developpeur qui ecrit le test. Il sait quelle partie de son code il faut cibler pour lui chercher des embrouilles.
En terme de quantite de code, j'ai en general autant de code de teste que de code de programme. Mais ca ne me prend pas plus de temps a ecrire qu'un programmeur normal, car le programmeur normal aussi fait des tests. Sauf que les siens ne sont pas automatises et integre dans le projet.
C'est sur que tester un projet existant, c'est dur puisque tu as perdu tous les tests ecrits par le developpeur pendant sa phase de dev. Mais integrer les tests au dev, ca ne coute pas grand chose.
Le gain vient surtout au fur a mesure que le projet avance, ou tu peux completement te reposer sur les test unitaires. De facon non surprenantes, quand je decide de ne pas faire de test unitaire sur un morceau de programme, c'est justement la que je vais trouver des bugs par la suite et regrette ma decision.
> Après il faut faire des choix : les ressources consommées par l'assurance qualité seraient-elles mieux utilisées à faire des revues de codes, des re-codage le cas échéant, le tri et l'analyse des rapport de bogues ?
Non. Le cout de correction d'un bug croit exponentiellement en fonction du temps entre lequel il est decouvert et le moment ou la fonctionnalite a ete codee. On gagne donc un temps precieux a detecter les bugs tres tot et a s'eviter des rapports de bug qu'il faut gerer, reproduire, discuter, fermer.
J'ajoute que quand tu as des suites de tests unitaires, il est facile de s'appuyer dessus pour faire des suites de tests fonctionelles. Quand on te reporte un bug, au lieu de corriger, tu construits d'abord un test dans ta suite fonctionelle pour mettre le bug en evidence, puis tu corriges. Tu es sur que le bug ne reviendra _jamais_, tu as un test pour le prouver.
Qui plus es, tu as mentionne la notion de logiciel actif et bien maintenu. Un logiciel qui bouge, c'est un logiciel dont l'architecture evolue souvent dans le temps. Tu peux meme voir que tous les projets majeurs sont re-ecrits tous les deux ou trois ans (Gnome 1 -> Gnome 2, KDE 1 -> KDE 2, gimp1 -> gimp2, apache -> apache2, ...). Les tests unitaires prennent alors une valeur encore plus grande : on peut tout peter a l'architecture, en garantissant que les fonctionnalites sont encore la.
<< A titre d'info, je trouve les dernières versions de la suite bureautique d'un-grand-éditeur-américain-que-nous-connaissons-bien _truffées_ de bogues
>>
Je ne peux pas dire, je ne l'ai pas utilisee depuis deux ans.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 4.
Prend un exemple, le support des materiels exotiques. Il devrait y avoir une suite de tests unitaires qu'on pourrait faire tourner sur un driver quelconque. Pour l'instant, la facon de tester un driver du noyau, c'est soit de faire tourner le noyau de facon normale, soit pour chaque developpeur de s'ecrire une ou deux fonctions de test. Je suis choque de ne pas voir de repretoire test dans les sources du noyau.
Par exemple, je suis dans une situation similaire au cas du driver : je dois supporter plusieurs lecteurs de carte a puce sans-contact. A chaque fois que je rajoute un lecteur, je fais tourner une suite de test generique qui va tester toutes les fonctionnalites generiques du lecteur et va donc valider que mon implementation du support du lecteur est correct dans tout
Pourquoi on ne retrouve pas ce genre de chose dans les sources du noyau ? Avec ca, on pourrait avoir une suite de test revue et amelioree par tout le monde, donc qui serait de tres bonnes qualites.
Et quand un materiel exotique ne marche pas, le developpeur du driver pourrait dire au mec: fait tourner la suite de test et envoie-moi les resultats. Ca l'aiderait surement a faire un diagnostic plus precis du probleme.
Je prends un autre exemple que je connais bien : KDE. Combien de suties de test dans KDE ?
- une suite de test pour kurl
- une suite de test pour taglib
- une suite de test introduite recemment pour khtml.
C'est plutot pathetique. Ca change doucement mais faut pas etre presse.
[^] # Re: ???
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
> (je ne parle pas de test unitaire)
Dans ce cas precise. Dans la plupart des projets, la phase de test fonctionelle et l'integration sont faites a la fin. C'est aussi une erreur qu'il faut essayer de corriger, meme si ce n'est pas toujours facile (pour la phase d'integration).
Sans meme faire reference a XP, toutes les methodes de developpement recommandent de faire des phases de tests intermediaires (water fall, cycles en plusieurs V).
Donc on peut reformuler ta phrase "dans le cas ou un projet ne respecte aucune methodologie qualite et fait des tests 3 ans apres le dev, on sait depuis tres longtemp qu'un bug decouvert en phase de test coute tres cher".
Ce qu'on sait surtout depuis tres longtemps, c'est que plus ton bug est decouvert tard, plus il coute cher. Donc il faut tester tres tot et plutot que de sortir une anerie pour decredibiliser les tests (les bugs decouverts en phase de test coutent cher), je pense que tu devrais integrer cette notion de tester le plus tot possible dans une demarche de qualite globale (qui va avec la demarche de bonne conception que tu sembles deja preconiser).
Et comme je l'ai deja dit, une fois que tu as beaucoup de tests unitaires, il est tres facile de monter des tests fonctionnels qui s'appuient sur ces tests unitaires, donc de lancer des tests fonctionnels tres tot sur le projet
[^] # Re: GTK et Gnome n'ont plus de raison d'être !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
cf www.easymock.org pour une solution en java. Pour python, on peut trouver ca dans le python cookbook, sur le site d'active state. Une implementation de mock en moins de 100 lignes, impressionnant.
[^] # Re: ha ?!??
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 10.
Exemple:
/* we call this function to check for incorrect syntax */
check_string_1( s );
/* we call this function to check for wrong attributes references */
check_string_2( s );
A comparer a
check_string_for_bad_syntax( s );
check_string_for_wrong_attribute( s );
Je prefere nettement la seconde version, bien qu'elle soit moins commentee.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 4.
C'est pas vrai du tout. 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.
Ensuite, il n'y a pas que le kernel dans la vie, il y a plein de logiciels libres qui seraient tres faciles a tester avec des tests unitaires et qui auraient beaucoup a y gagner, mais qui ne le font pas.
> La qualité d'une fonction d'une ou d'un groupe de fonction n'induit pas le bon fonctionnement du logiciel !
C'est faux aussi. Le driver dedie purement a un materiel est plus dur a tester (mais c'est pas du tout impossible) que d'autres parties. Cependant, la qualite d'un groupe de fonction induit grandement la qualite globale d'un logciel. Si on prend l'exemple du kernel:
- la qualite des fs est independante de la qualite des drivers de disque dur. C'est tres facile de tester un FS et c'est d'ailleurs ce qui est fait poru ext3 et reiser
- il y a d'autres parties du noyau facile a tester mais qui ne le sont pas ou du moins pas via des tests unitaires : scheduler, gestion de la memoire.
Il faut voir que des que tu n'es plus a 1 cm du materiel, c'est a dire des que tu sors d'un drivers, tout est testable. Il suffit de faire un pseudo driver dont tu modfifieras le comportement dans tes tests et via lequel tu verifieras que le reste du systeme se comporte correctement.
> Les LL misent généralement sur la période d'incubation
Pour des tres gros projets, c'est peut-etre le cas. 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 et c'est a ca que servent les tests unitaires.
> Mais c'est la condition pour un débug pertinent:
Je ne suis pas d'accord du tout. Seul une tres petite minorite de bug ne peut etre decouvert que dans des conditions reelles. Une tres grande majorite de bug peut-etre decouvert durant la phase de dev. Le noyau ne fait pas exception. C'est l'argument typique des gens qui ne veulent pas tester: "Je ne peux pas tester ca". Apres, tu leurs presentes des methodes pour qu'ils puissent tester ce qu'ils ne peuvent pas tester mais ils refusent en general des les utiliser parce que ca les obligerait a changer leurs habitudes et a faire evoluer un poil leur architecture.
> 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.
C'est vrai qu'on a tout le temps pour attendre les nouvelles versions stables de debian, ca ne decredibilise pas du tout le projet .
<<
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.
>>
Ceci est vrai sur un certain nombre de tres gros projets, mais pas sur beaucoup. Typiquement, pour le noyau, Linus relit les patchs mais l'inverse est rarement vrai.
La relecture s'attache en general a trouver des erreurs de conception. C'est rare qu'on leve des purs bugs comme ca.
Ce que tu dis est complementaire des tests unitaires, mais ne peut en aucun cas s'y substituer.
[^] # Re: ???
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 4.
Et tu n'a jamais de coup de fatigue ? De faute d'inattention ? D'erreur de frappe (oh, j'ai mis == eu lieu de =) ?
> Plus sérieusement, les tests ne sont qu'une toute petite partie d'un processus qualité global.
Alors la, je ne suis pas tu tout d'accord. Bien sur, une bonne conception est essentielle, mais une bonne conception ne va apporter que des garanties de bon fonctionnement globaux (le logiciel pourra faire X ou Y). Il y a toujours un moment ou tu codes et le [1] _seul_ moyen de valider du code, c'est des tests unitaires.
Donc les tests sont une partie essentielle et fondamentale du processus qualite.
Tu peux avoir une conception magnifique UML et tout le bazar, et un logiciel code comme les pieds qui plante toutes les 10 secondes. Oui, la conception etait bonne, mais l'implementation etait a chier.
<<
On sait depuis _très_ longtemps qu'un bug découvert en phase de test coûte _très_ cher. Donc depuis bien longtemps, les bons chefs de projets mise à 90 % sur la conception et le développement.
>>
La, tu dis n'importe quoi. Tu assimiles erreur de conception et bug.
Un bug, c'est une fonctionnalite avec une erreur (= a la place de ==). Dans une bonne approche ou tu codes tes tests avant ou pendant que tu codes tes fonctionnalites, un bug a un cout de correction extremement faible. Tu es dans le code, tu vois tout de suite ce qui ne va pas, personne n'est impacte en dehors de toi, et tu corriges dans la minute ou dans la journee.
Au fur a mesure que tu avances dans la phase de vie du produit, un bug a un cout de correction exponentiel. Sur un produit deja sorti, c'est dramatique.
Je ne sais pas ou tu as vu qu'un bug decouvert en phase de test coutait cher, mais c'est n'importe quoi.
Une erreur de conception en revanche, ca coute tres cher, je suis d'accord. Mais l'avantage des tests unitaires, c'est que ca te permet de corriger ce type d'erreur a moindre cout. En effet, une erreur de conception te conduit a refaire l'architecture de ton soft. Et la, tu sors ta batterie de 300 tests unitaires qui marchait avec l'ancienne architecture. Tu la valides avec la nouvelle acrchitecture et tu es sur que tu n'as perdu aucune fcontionnalite ni introduit aucun nouveau bug. Des certitudes comme ca, ca n'a pas de prix.
1] je sens qu'on va me parler de preuve formelle. Aller, combien d'entre vous savent faire de la preuve formelle sur un logiciel ? Combien ont vu des logiciels libres avec des preuves formelles ? Connaissez vous le cout de mise en place d'une preuve formelle ? La preuve formelle, c'est super mais en pratique, pour des logiciels a la con, c'est pas la panacee.
[^] # Re: Ah oui mais...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.
Plus tu testes mieux ca se passe. Pour moi, il n'y a pas de bonne raison de ne pas tester un module que tu pourrais tester.
<<
Je suis un "accros" des :
#ifdef DEBUG
assert (....)
#endif
>>
Moi j'en suis parvenu a la conclusion qu'il n'y a pas de raison de supprimer les assert en mode release. L'overhead est completement negligeable.
D'ailleurs, tu peut deja t'epargner quelques lignes de code avec un:
#ifdef DEBUG
#define ASSERT( toto ) assert( toto )
#else
#define ASSERT( toto )
#endif
et utiliser ASSERT() partout.
Perso, je suis plus dans une optique d'utiliser des logs pour les assert, qui ne seront pas affiches par defaut en mode release mais que je peux activer a tout moment. Si un client a un probleme, je lui dis de lancer le soft en mode debug et de m'envoyer le log.
[^] # Re: c'est toujours pas libre ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 4.
On le voit dans le cas de TheKompany. Non seulement les gens ont hurles parce que le logiciel n'etait pas gratuit, mais en plus il n'y a aucun retour positif.
Donc je ne vosi pas pourquoi je donnerai les sources de mon logiciel commercial a mon client. Lui permettre de se passer de moi, d'installer mon produit sur 7000 postes en ne payant qu'une seule licence, lui permettre de contacter une boite de service pour faire la maintenance a ma place sur mes propres sources, ce ne sont pas des choses qui m'`interessent. Au contraire, ca va faire couler ma boite et mettre tous mes employes au chomage.
Les seuls modeles viables commerciaux + libres sont ceux ou le libre fait vraiment partie du business model et ne vient pas en plus. Dans le cas de trolltech, la version libre leur sert de support de promotion de leur toolkit aupres des developpeurs.
Si je fais un logiciel qui me prend 3 ans a developper et que je vends 100 kF par licence, imagine combien j'ai a perdre en le mettant en libre.
[^] # Re: et wxWidgets dans tout ça ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
J'avoue que les qstring, c'est en effet parfois un peu lourd. Je me suis deja fait mordre une ou deux fois.
[Sous-classer en C++]
Je vois pas trop ce que tu veux dire par la. Sous Qt, sous-classer est une technique utilisee tres tres couramment. Ca correspond a la realite d'un besoin : tu as souvent besoin de specialiser un composant pour une utilisation legerement differente de l'utilisation de base. C'est une des forces de Qt que de permettre ce genre de chose tres facilement.
J'ai vu des toolkits ou on ne peut jamais modifier le comportement des widgets de base, et ou on est donc obliger de les recoder a la main quand on veux les specialiser.
Par contre, je ne comprends pas ta remarque sur le C++. En PyQt, tu peux tout faire en python, pas besoin de C++.
Sinon, pour le futur de PyQt, je pense que Phil Thompson va s'aligner mais ce n'est pas sur.
[^] # Re: GTK et Gnome n'ont plus de raison d'être !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 4.
Une appli proprio n'etait pas libre mais le deviendra peut-etre. Je vois pas le rapport ni avec gtk, ni avec qt, ni avec la choucroute.
[^] # Re: Ah oui mais...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 10.
Ce que je partage avec l'auteur de cette news comme point de vue, c'est que les tests unitaires ne sont pas assez utilise en logiciel libre. C'est un tort car ca permet de faire evoluer tres rapidement l'architecture d'un logiciel tout en conservant sa qualite. Si je prends une appli comme grisbi, il y a eu des versions completement inutilisables tellement elles etaient buggees. Pourtant, c'est pas dur d'ecrire des tests unitaires pour les fonctionnalites qui posaient probleme.
Depuis que je suis devenu un integriste du test unitaire, je constate que j'ai beaucoup moins de bugs sur mes projets et qu'ils sont beaucoup plus faciles a faire evoluer. Constation corroboree par d'autres convertis du test unitaire.
Alors le test unitaire, mangez-en. On peut en faire en C (cunit), en C++ (cppunit), en pyton (unittest), en java (junit, easymock), et C#, en ruby et en tout ce que vous voulez. L'important est d'avoir une suite de test automatisee.
Le contre-argument classique est "mais on ne peut pas tester cette partie-la". Avec un peu d'astuce, on peut tout tester mais il faut s'en donner les moyens. Par exemple, j'ai peu tester un protocole de communication radio ou il fallait simuler des conditions radio anormales. Je travail aussi sur du code embarque ou il faut tester le comportement d'un programme compile avec de l'overlay (pas de notion de fonctionr re-entrante, les variables locales ne sont pas sur la piles mais a des emplacements fixes). Ca aussi, on a put tester sans probleme a condition de reflechir a la facon d'aborder le probleme.
Ce qui est genial, c'est qu'une fois que les briques de bases ont beaucoup de tests unitaires, c'est tres tres facile de faire des tests fonctionnels de tres haut niveau, en assemblant des briques de tests unitaires.
Par exemple, une fois que j'ai eu mon protocole de communication debugge, j'ai pu teste l'ensemble de mon programme avec introdution de conditions radio anormales et autres petits problemes. J"etais doublement confiant dans sa qualite.
[^] # Re: De la criticité des bugs
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 6.
Bah, les developpeurs s'en foutent. Pourtant le bugs a pas mal de votes, et j'ai rencontre plein de gens interesses par la fonctionnalite.
Au final, si personne ne veux corriger un probleme, il ne sera pas corrige. Le developpeur ne considere que ce n'est pas important et puis voila.
[^] # Re: GPL != Libre
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
[^] # Re: c'est toujours pas libre ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
Oui, bien sur. Je sais que tout le monde ici est persuade que c'est le cas mais quand on regarde les cas concrets on se marre.
Combien de boite font du libre commercial ? Disons MySql, Trolltech, Mandrake, Red Hat, Suse pour les tres gros. En cherchant parmi les petits, on doit arriver a une 20aine ou une 30aine.
A cote de ca, combien de logiciels libres ? Tu ne sens pas comme un decalage ?
Combien de gens savent que quelques produits de TheKompany sont GPL mais dont les sources ne sont pas distribuees ? Dans ce cas, ces softs sont des bides, les gens ont hurle parce que ce n'etait pas gratuit mais GPL et personne n'a jamais contribue.
J'ai cree avec succes deux entreprises et ca fait aussi pas mal d'annees que je fais du logiciel libre. Je suis intimement persuade que faire de l'argent avec du libre reste extremement difficile et ne peut se faire quand des conditions tres particulieres sont reunies.
Le commercial + libre reste une exception exceptionelle, et j'en suis desole mais c'est comme ca. Dans mes boites on fait entre 100% et 95% de logiciel proprio et c'est ce qui nous permet de vivre.
[^] # Re: Desole, certaines entreprises programment encore en C
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
Aujourd'hui demarrer un projet non embarque en C est une pure aberration dans l'industrie, en pariculier dans le cas de logiciels graphiques.
Meme le C++ devient obsolete.
[^] # Re: GTK et Gnome n'ont plus de raison d'être !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 6.
Ben non, Qt passerai automatiquement en licence BSD. cf commentaire plus bas et cf la Free-Qt Foundation.
Gtk est la, donc c'est un peu bete de se dire qu'on ne doit plus l'utiliser. Cela dit, je reste persuade qu'ecrire un toolkit graphique en C est une anerie et fait perdre un temps monstreux en dev aux developpeurs.
Si MDI et consorts poussent d'autres langage de programmation (mono, java, python, ...) c'est bien parce qu'il semble que le C soit un peu depasse.
Ca me faisait marrer de lire le blog de MDI qui etait epate de la vitesse avec laquelle ils developpaient en C# + gnome. Et oui, bienvenu de le monde de l'objet, du polymorphisme, des garbage collector, des constructeurs et des destructeurs et de l'heritage.
Si vous voulez vous marrer un jour, regardez la quantite de code Gtk qu'il faut pour ecrire l'equivalent:
class MyWidget: public QWidget
{
public:
MyWidget( QWidget * p) : QWidget(p) {}
public slots:
void my_slot(int p1, int p2, int p3);
};
D'apres mes souvenirs (en gtk1), ca tape dans les 50 lignes de code, dont la moitie compose de macro sur des structures sans aucune verification de type.
[^] # Re: c'est toujours pas libre ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
Mouai. Prenons le nombre d'applis open source commerciales et divisons le par le nombre d'appli open source benevoles. Maintenant, faisons la meme operation avec le nombre d'appli open source commerciale que nous divisons par le nombre d'appli close source commerciales.
Je serai surpris qu'un seul de ces chiffres depasse les 0.01% . Certe, Trolltech fait un amalgame, mais il peut se defendre par les chiffres.
[^] # Re: et wxWidgets dans tout ça ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
Mouai. Je code tous les jours en PyQt (c'est mon boulot) et je n'ai pas eu la sensation de manquer de souplesse, au contraire. Le systeme signal/slot porte a python est beaucoup plus souple que celui du C++ puisque n'importe quelle methode ou fonction python peut servir de slot (callback).
[^] # Re: Peur...
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.0 en GPL sous Windows. Évalué à 4.
>>
Desole, mais meme si tous les arguments sont a NULL, l'api reste plus compliquee. C'est un probleme de l'api windows que tu ne peux pas nier.
Sous qt, je peux lancer un processus sans consuler la doc. Sous windows, je dois la relire trois fois pour etre sur que j'ai pas mis un NULL au mauvais endroit.
<<c) CreateProcess c'est un des nombreux APIs te permettant de lancer des processus, t'es libre d'utiliser d'autres APIs qui te permettent de faire des choses plus simples, plus simplement. >>
Ah ouai ? Et tu peux me dire ou on trouve cette api miracle ? Parce que quand on cherche sur le msdn, on tombe toujours sur CreateProcess.