[quote name=‘Zekiller’ date=’ 9 Feb 2005, 11:21’]Si ça crashe pas, ça part direct chez le client, qui avec pas de chance va appeller tout faché 10 minutes après que ça marche pas. Et ça recommence …
[right][post=“330724”]<{POST_SNAPBACK}>[/post][/right][/quote]
Et tout le temps que vous perdez au téléphone et à faire du support, vous auriez pu le passer à faire de la qualité. Et si ca avait été le cas, il y aurait eu, au bout, des économies, car on passe plus de temps à faire du support pour 1 bug qu’à le corriger (puisque le bug se reproduit chez x personnes, que tu perds du temps au téléphone avec chacun d’eux, qu’il faut refaire un déploiement, etc.); et en plus vous auriez un client heureux… un client heureux, c’est un client qui fait de la bonne pub.
Envoyer des trucs à l’arrache au client, c’est rarement un bon calcul à moyen terme (c’est tout juste bon à court terme, pour pouvoir dire au client “tiens ! t’as vu comme on est réactif !”)
[quote name=‹ GloP › date=’ 9 Feb 2005, 11:20’](sinon pour ce qui est de re-ecrire en partant de zero je suis pas d’accord 
si tu lis les textes de Joel Spolsky - un des gourous du managment de projet logiciel - il demontre que toutes les boites qui font vraiment ca se cassent la gueule ou se mettent en grande difficultes, exemples concrets a foison a l’appui. Repartir de zero est un challenge enorme qui te met dans les choux par rapport a la concurence. Je conseille fortement son site d’ailleurs.)
[right][post=« 330723 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Je suis d’accord avec toi. Je parlais juste de la sensibilité du dev (oui monsieur, sensibilité) devant le code patché de partout avec pleins de bouse qui se dit « il faudrait réécrire propre ». Avec de l’expérience on peut même arriver à reconnaître l’historique de la chose et à expliquer, sinon excuser, certaines bouses. On peut même y voir une certaine forme d’art.
Sinon quand je bossais pour un éditeur, on avait aussi une équipe product manager, mais ça ne résoud pas le problème des gros (et quand je dis gros, on vendait des progiciels de finance à des grands groupes mondiaux) clients capricieux qui tiennent l’avenir de la boîte entre leur main sur l’achat d’une version ou pas. Et là ils sont en mesure d’exiger des choses dans le contenu de la version. Evidemment à coder pour l’avant-veille, et pas du tout en harmonie avec les précédents choix techniques. D’où, bouse.
Enfin bref, on serait mieux sans les clients.
« Ca serait pas la guerre, qu’est-ce qu’on serait bien, hein chef ? » (source ?).
EDIT:
[quote name=‹ urdle › date=’ 9 Feb 2005, 11:17’]Et le problème en France, comme dit cocobill,
[right][post=« 330721 »]<{POST_SNAPBACK}>[/post][/right][/quote]
cocCobill s’il te plaît. Sinon ça veut rien dire
[quote name=‹ phili_b › date=’ 9 Feb 2005, 02:31’]C’est l’idéal mais dans les petits projets, ou dans les régies, on est obligé d’être tout cela à la fois sinon on se fait bouffer par le client/utilisateur, surtout quand les gens censés nous isoler nous mettent au contraire une pression supplémentaire et nous demande de la fermer.
[right][post=« 330732 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Tout depend de ce que tu appelle petit projet. A 2, ok, a 3 aussi mais meme sur un petit projet la structure est applicable. 4 personnes, chef de projet inclus, c’est deja bon. T’as un chef de projet, un PM qui deale avec le client et qui a RIEN a t’ordonner a toi codeur (il est pas au dessus de toi hierarchiquement), un testeur et un codeur. C’est la structure minimale, si conflit PM/dev ou test/dev ou pm/test il y a, il se regle avec le chef de projet (qui est pas un codeur, ni un PM, ni un testeur, il est au dessus de tout ca). Un PM peut bosser sur plusieurs projets a la fois pour peut que la boite en gere plusieurs. Le decoupage des roles, si il est bien assimile par chacun est etonnament efficace a resoudre les problemes. Par exemple, un dev qui se demande si quand il clique sur ce bouton, ca doit plutot faire X ou Y parceque c’est pas clair dans les specs, il va demander au PM, qui va repondre, mettre a jour les specs et en informer le testeur. Le PM est celui qui trie les bugs pour les classer par ordre de priorite en accord avec les devs et les tests, etc, etc. Le dev ne prend pas de decision sur qu’est ce que fait la produit, le pm ne dit pas au dev comment il doit coder la fonctionalite et le testeur a pour boulot de verifier que PM et dev parlent bien de la meme chose C’est assez logique quand on est habitue et ca simplifie grandement le bordel lie aux evolutions inevitables des softs en cours de devel
Edit pour philli_b: mais je comprend parfaitement ce que tu veux dire: plus c’est petit plus c’est le bordel a gerer des roles bien determines et tout le monde fait un peu de tout, c’est plus complique je suis parfaitement conscient de la chose
Cocobill: oui non tout a fait d’accord parfois c’est la merde avec des enormes clients qui exigent les trucs. Mais c’est mieux quand meme si c’est pas le dev qui deale direct avec eux. Faut pas croire que MS est isole de ce genre de chose non plus. Il y a pas « d’avenir financier » en jeu, mais je peux te garantir que quand Siebel ou Toshiba exigent un truc, on y regarde a deux fois et j’ai jamais vu leur dire « allez vous faire fouttre ». On bosse toujours avec eux, mais je comprend tres bien qu’ils sont pas en position de force pareil, ca permet d’etre moins borne, 100% d’accord avec toi B)
Entièrement d’accord mais quelque fois tu n’as pas d’autres choix que de t’en charger si le chef de projet brasse de l’air et promet la lune au client, ou si le chef de projet est en fait un client/utilisateur.
[quote name=‹ phili_b › date=’ 9 Feb 2005, 02:49’]Entièrement d’accord mais quelque fois tu n’as pas d’autres choix que de t’en charger si le chef de projet brasse de l’air et promet la lune au client, ou si le chef de projet est en fait un client/utilisateur.
[right][post=« 330743 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Ha oui clair tout cela suppose des competences de bon niveau pour les personnes impliquees. Quel que soit le role c’est un tripode (un genre) si un seul des pieds est bancal ou si celui qui decide comment on construit le tripode est mauvais ca va jamais tres loin L’influence de quelqu’un qui fait mal son boulot sera bien plus grande dans une petite equipe que dans une enorme/grosse equipe (ou a la limite un mec qui branle zero se remarquera a peine mias pour eviter ca y a d’autres techniques :P).
[quote name=‘GloP’ date=’ 9 Feb 2005, 10:53’]Urdle: tout a fait, c’est exactement vrai ce que tu dis. C’est la qu’entre le test driven developmeent et les methode de devel XP. Ca evite, ca oblige, le dev a pas avoir la tete dans le guidon et a ecrire les tests avant le developement pour eviter cela justement. En faisant cela, le nombre de bugs finaux est en theorie grandement reduit et/ou leur gravite diminuee.
[right][post=“330711”]<{POST_SNAPBACK}>[/post][/right][/quote]
Un des autres intérêts de ces méthodos de test, c’est la non régression automatisée !
J’ai déjà vu des équipes de test en TMA se retapper les même test à la main des dizaine de fois pour vérifier que l’appli ne régresse pas après chaque évolution.
Alors qu’avec des tests unitaires automatisés (écrits avant ou après peu importe, mais sous forme de code à l’aide d’un framework jUnit/nUnit et pas à la mano ou au débugger) on est capable de repasser les même tests des dizaines de fois en quelques minutes ! L’investissement au moment du développement est conséquent, mais le ROI est je le pense encore plus !
[quote name=‘GloP’ date=’ 9 Feb 2005, 10:06’]La technique elle meme est plutot recente (quelques annees au plus). La plupart des ingenieurs ne fonctionnent absolument pas de cette maniere.
Il y a une difference entre tester son code au fur et a mesure qu’on l’ecrit,et faire de l’XP de la maniere mentionnee. [right][post=“330696”]<{POST_SNAPBACK}>[/post][/right][/quote]
Otes moi d’un doute: c’est quasiment impossible pour la personne qui code, ou même qui conçoit, d’écrire les tests avant d’avoir développé ? C’est au fonctionnel de l’écrire n’est-ce pas ? Souvent les équipes de développement doivent malheuseument écrire les cahiers de test unitaires, quand ils existent, mais les dés sont trop pipés et c’est pas du tout logique si les tests XP étaient faits par l’équipe de développements. Autant ne pas en faire dans ce cas là.
Si ce sont les fonctionnels, ou une équipe tierce, qui doit écrire ces tests je comprends mieux l’XP que j’avais du mal à apprehender avant. Un fonctionnel, un utilisateur, qui doit écrire comment il veut que son application réagisse ça me parait beaucoup plus logique. (Rien n’empêche qu’il soit aidé dans la méthode).
Non mais ce sont pas les seuls test qui vont etre ecrit. C’est pas « tous les tests sont fait par les devs avant de commencer a coder ». Ca serait ridicule. Non, il s’agit d’ecrire formellement ed vrais unit tests et d’integrer a la suite de tests a faire tourner automatiquement la validation fonctionelle de ce que va ecrire le developpeur avant qu’il se lance dedans. Vu qu’il faut ecrire du code pour tester le code, le code qui teste il va lui aussi avoir des bugs et il est reloud de devoir en plus debugger le code qui teste le code. En faisant ca avant tu limite grandement les bugs dans les deux.
Par exemple si tu ecrit une fonction qui si tu passe « ou ca? », te reponds « DTC », tu ecrit un programme qui passe « ou ca? » « OU CA? » « ou cha? » « » null et autre en entree, et qui valide que « DTC » est retourne dans les cas prevu. Pour un exemple si simple t’as meme pas besoin de faire du code, tu prend ton outil de testeur et tu rentre les machins dedans (si t’as l’outil en question, sinon ben faut le faire). Apres tu prend ce petit programme de validation et tu le fais tourner automatiquement a chaque changement du code. Si jamais ca foire tu valide pas et tu accepte pas le changement tant que le test ou le code soit mis a jour pour que ca passe. C’est la phase unit test qui est concernee, celle que l’ingenieur qualite devrait dans un monde ideal ne jamais avoir a toucher. Mais si tu crois que le test devrait s’arreter la et que t’es bon pour shipper le code, t’es moooort grave ca va foirer en dix fois plus de maniere des que tu vas essayer de l’integrer avec autre chose.
Mais bien entendu apres derriere t’as toute une equipe de test qui travaille aussi a valider ton code en interaction, avec leur propre procedures, leur propre suites de tests, etc. Mais comme deja dit dans un monde ideal c’est PAS a l’equipe de QA de faire de l’unit test (en tout cas pas dans les proportion qu’on voit aujourd’hui dans l’industrie). Leur role c’est de faire l’autre test, tout le reste, c’est a dire par exemple, de verifier que t’as implemente ce que les specs disent et pas un truc a cote, ou entre autre du test d’integration ou c’est l’interaction entre des composants deja robustes et « unit testé » par les dev qui peut poser probleme. Il y a d’autre maniere de tester et c’est un metier a part, faut demander a ma femme qui est ingenieur qualitee mais ca se decoupe en plein de domaines compliques
Pour le test d’integration puisqu’on parle de ca, en gros l’equipe QA doit tester que les pieces du puzzle on bien la meme forme sur les bords et qu’elle s’adaptent l’une a l’autre, pas que la piece du puzzle tombe en morceau des qu’on l’attrape un peu de travers, ca c’est le role du dev de s’assurer que c’est bien fait comme il faut et que ses changement ulterieurs ne changeront rien.
Bien sur en pratique pour chaque changement il est bon d’avoir un ensemble de tests qui tournent automatiquement et qui recouvrent chaque phase du test (unit, integration, end to end, scenario based, manual testing, code coverage, perfs, etc) et qui ont pu etre mis en place a la fois par les devs au debut et par l’equipe d’assurance qualite.
Bon je repond en retard pour bussiere, et apres que tout le monde a bien developpe sur le vrai sujet: l’assurance qualite (pour ceux qui se demandait ce que QA signifiait :P)
Donc Bussiere, tu as eu des mauvaises experience avec linux parce que ca merdait chez toi et que t’as pas reussi a te depatouiller tout seul? Big deal. Les fameux RTFM et STFW ne sont pas un hasard, y a un vrai tas de gens qui n’ont pas envie de chercher et qui attendent que ca leur tombe tout cuit dans le bec et ce, gratuitement. Trop facile, non?
Tu as un probleme avec un LL? Tu veux pas te faire chier a chercher la doc? Ok, bah tu achetes du support Linux alors. De plus en plus de boite en font, et LA, t’as le droit de faire le gros neuneu de base.
Et c’est ce que j’explique quand je fais des formations linux: Pendant la formation, tout le monde a le droit de poser des questions idiotes, je suis paye pour y repondre. Par contre, apres la formation, si l’un des eleves pause une question idiote dans un forum, je n’hesiterais pas a repondre RTFM ou STFW. Parce que dans ce cas la, j’aide de maniere benevole, et je vois pas pourquoi je ferais l’effort de faire ce que l’eleve n’a pas eu le courage de faire.
Maintenant, concernant les LL, il faut relativiser, et considerer 2 cas:
- Les LLs connus genre gnome, kde, noyau linux qui ont une base d’utilisateurs et de developpeurs considerables, et qui sont plutot bien testes et [en general] bien documente (y a juste ce racisme info/man qui est SUPER penible).
- Les LLs de moyenne/petite envergure qui restent marginaux et tres peu utilises.
Dans le cas 1, il faut bien comprendre que les main dev sont PAYES par des societes qui mettent des sous dans les LLs, comme Redhat, Mandrake, IBM ou HP. Donc la logique est de plus en plus type « pro » que « amateur au fond du garage qui se fait plaisir a taper dans le code linux ».
Dans le cas 2, les devs ne sont pas payes et font ca pour le fun, et s’ils ne veulent pas faire de docs, bah je vois pas comment on pourrait les blamer: Moi perso, je prefere prendre mon pied a coder un algo de folie plutot que de me faire chier avec l’interface pour Madame michu. Pareil pour la doc. Surtout que le soft que je fais, je le fais a la base pour moi et je le donne a la communaute « s’il en veulent ». Et s’ils en veulent pas, ben je m’en tape.
Ca, c’est mon point de vue LL.
Concernant le cote professionnel, Dieu sait que j’aimerais travailler dans un environnement tel que le decrit Glop, c’est a dire les devs, les testeurs et la qualite. A mon ancien taf, j’ai pas mal insister pour avoir un serveur de dev, un de test et de mettre en place un systeme de branche et de release pour pas avoir a patcher a la porcasse quand un client en prod trouvait un bug. Bah non, trop cher, trop long a maintenir (backport, tout ca) donc pas moyen.
Dans ma structure actuelle, on a un gros projet mais coder par une seule personne (base sur un projet GPL), donc le besoin est moindre (mais quand meme :P)
Voila mon avis a moi que j’ai
(bravo pour le thread avec des arguments et tout, et qui part pas en live comme sur linuxfr)
LoneWolf
Cafzone mieux que Linuxfr
Quelque fois le souci que l’on puisse répondre RTFM c’est que la personne ne sait même pas où aller chercher. Surtout si la personne débute complétement dans ce domaine.
On peut répondre RTFM mais il faut donner une URL (ou un chapitre dans un livre). Certes certaines personnes ne se donnent pas la peine de lire la doc, mais d’autres veulent être un peu aiguillé pour ne pas lire des tonnes de docs inutiles.
Un RTFM tout seul sans URL c’est un peu méprisant et ça fait informaticien dans sa tour d’ivoire, en tout cas c’est souvent compris comme cela par les débutants de bonne foi.
Edit: Avant qu’il n’y ait les How-to, la seule présence des mans était vraiment insuffisantes. D’ailleurs il ne faut pas confondre manuel d’utilisateur et guide de référence qu’est un man malgré son nom.
Edit2: D’autant plus que dans le domaine des logiciels libres il n’y a pas que des professionnels dudit domaines. Quelqu’un qui pose des questions sur Linux, dans son métier il fait peut-être du NT ou de la base de données, ou même n’est pas du tout informaticien. Il le fait pour apprendre, par passion pour l’informatique, ou pour pouvoir élargir son panel de compétence à son rythme nécessaire dans les petites structures de type PME. Autrement dit il n’a pas subi de formation.
Je suis d’accord avec l’article aussi, mais il ne m’apprend rien là, c’est même logique ce qu’il dit.
D’un autre coté, aucun test n’est infaillible, et si le test est buggué il peut ne pas détecter certains bugs, donc au final c’est un peu flou ces histoires de tests. Mais ce n’est pas inutile pour autant, ça sert bien entendu.
Généralement je m’arrange pour utiliser des logiciels libres connus et je les teste dans leur ensemble avant de les utiliser (je ùe suis aperçu que la qualité générale de conception du logiciel reflète le nombre de bugs qu’il contient, ce n’est pas toujours le cas bien sûr, mais souvient oui.
Après il y a les développeurs qui testent, et ceux qui tesent pas. Généralement quelqu’un qui développe un logiciel libre le développe d’abord parce qu’il en as besoin (donc il fait des tests basiques la plupart du temps).
Il y a aussi les tests de bugs et failles fait par je sais plus quels algorithmes inventés par je sais plus quelles boites.
Ils affirment que le noyai Linux contient 0.15 bugs par millier de lignes de codes, que le noyau Windows est estimé à quelques 2 bugs par milliers de lignes de codes…
Ils disent qu’en gros parmi touts les OS qu’ils ont testés, c’est le plus souvent les OS libres qui ont le moins de bugs.
Mais qui dit que leurs algorithmes sont sans failles ? Peut être qu’un certain type de bug non détecté passe plus souvent dans le libre ? De plus on ne connâit pas les conditions et paramètres des tests, vu que ces outils sont propriétaires.
Comme quoi, c’est beaucoup de blabla pour rien tout ça, moi je pense que les systèmes de bug tracking style Bugzilla ou autres sont un bon moyen de tester les logiciels, peut être est-ce un meilleur moyen de tester que de faire des systèmes de détection de bugs.
L’inconvénient avec le libre c’est donc qu’il est préférable d’utiliser des logiciels matures (que beaucoup d’utilisateurs ont testé).
Mais c’est d’après moi un peu la même chose dans le logiciel propriétaire. Certains développeurs font des logiciels proprios mais les testent sans plus quoi. Pour les logiciels proprios c’est un peu pareil, ils sont vraiement fiables quand ils sont connus la plupart du temps.
Donc voilà, en gros qui vous dit que les systèmes de tests de logiciels sont fiables et servent vraiement à quelque chose ?
Moi j’utilise des logiciels libres et proprios, aussi connus d’un coté que de l’autre, et je vois pas vraiement de différence flagrante en général, donc pour moi ces histoires ne sont pas des arguments vraiement valables. C’est en utilisant les logiciels qu’on voit à la longue si ils sont buggués ou pas. Si ça plante jamais c’est qu’il y a peu de bugs, peu importe que les bugs aient été corrigés avec bugzilla ou des systèmes de test divers.
je vais rajouter un centime d’euro, va voir la documentation de Gentoo pour voir si les logiciels libres n’ont pas de documentations, aussi complêtes qu’elle peut être et localisée dans tout pleins de langues !
Sinon, je suis d’accord quand même un peu sur le fond, genre OpenOffice, la documentation est quasiment inexistante, il suffit comparer l’aide du Basic Editor de OO avec l’aide du Basic Editor de Microsoft Office tiens…
Le logiciel libre, pour se faire des sous c’est généralement via du service.
C’est pour ça que l’ont peut trouver pas mal de livre qui apprennnent à utiliser Open Office.
Ensuite pour les petits logiciels c’est vrai que la documentation il y en a souvent pas beaucoup, mais a ma connaissance c’est un peu pareil dans les petits logiciels proprios.
J’ai d’ailleurs un environement de programmation libre BASIC (visual) installé sur mon PC (hbasic) pas connu du tout, un seul développeur, version bêta, et il y a une documentation qui va avec et que l’auteur a rédigée à mesure.
Pour les logiciels connus effectivement (comme Gentoo, ou KDE) les documentations je les trouve exellentes (surtout celle de Gentoo).
Dans le cas de “petits” projets, ça doit aussi dépendre pas mal du développeur. S’il a envie de faire un truc bien léché, il prendra la peine de faire de la doc et de tester son travail je suppose.
Généralement en ce qui concerne les petits outils, j’utilise ceux faits pas la KDE Team ou rattachés, ils sont la plupart du temps de bonne qualité.