L'auteur du site d'hébergement de dépôts fossil chiselapp.com a annoncé la fermeture en mai de ce service.
C'est une grande déception pour les amateurs de ce gestionnaire de version simple et original qui intègre un bug tracker et un wiki, car chiselapp était le seul service gratuit avec fossilrepos.
Le code source est toujours disponible et l'auteur a même adopté une licence plus permissive pour encourager les éventuels repreneurs.
Fossil est un très bon gestionnaire de version et même s'il est très facile à héberger sur son propre serveur, il est dommage de le voir boudé par les grandes forges du marché.
# le git et le couvert
Posté par coïn . Évalué à 7.
il ne doit en rester qu'un !
j'espère que ca sera mercurial :)
[^] # Re: le git et le couvert
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
On compare souvent fossil à git ou mercurial.
Certes, on peut faire la même chose (DVCS+wiki+bugtracker) en combinant d'autres outils, mais c'est toujours beaucoup plus complexe et plus difficile à maintenir.
Pour l'autohébergement de petits projets, fossil n'a pas de concurrent.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le git et le couvert
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 5.
Nan y'a Veracity aussi ! http://veracity-scm.com/
Mais il est pas packagé dans debian parce que ça inclue plein de libs forkées avec des failles de sécu genre une lib qui fait du js etc. dommage ça a l'air pas mal.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: le git et le couvert
Posté par Littleboy . Évalué à 2.
Ca n'a plus l'air d'etre le cas, donc il y aura peut-etre un package debian dans pas longtemps.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639311
[^] # Re: le git et le couvert
Posté par Maxime (site web personnel) . Évalué à 2.
Installer redmine et git, je ne vois pas en quoi c'est "beaucoup plus complexe". Pour moi, ça reste une solution alternative à fossil, c'est un peu rapide de dire que fossil n'a pas de concurrent.
D'autant plus qu'avec git, si je veux partager ce que j'ai fait localement, je rajoute juste une source distante pour pousser mon travail et puis voilà. Est-ce aussi simple avec fossil ?
[^] # Re: le git et le couvert
Posté par devnewton 🍺 (site web personnel) . Évalué à 8. Dernière modification le 30 mars 2013 à 10:41.
Pour l'installation, fossil c'est juste UN exécutable.
A l'utilisation Git est beaucoup plus compliqué à utiliser.
Ensuite si je veux maintenir plusieurs sites et les synchroniser, ça va marcher pour git mais pour redmine?
Enfin, une fonctionnalité que j'apprécie beaucoup avec fossil: j'ai accès à tout même sans connexion internet, donc je peux écrire de la doc ou des rapports de bug même si je suis dans le train.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le git et le couvert
Posté par karteum59 . Évalué à 5.
Et encore, sous Linux on a apt-get…
A fortiori si tu veux encourager l'utilisation d'un scm+wiki simple pour des gens sous Windows, il n'y a vraiment pas d'équivalent ! Un seul executable, qui marche partout. Que du bonheur !
[^] # Re: le git et le couvert
Posté par barmic . Évalué à -1.
C'est enviable ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: le git et le couvert
Posté par freem . Évalué à 2.
Franchement, j'ai testé les deux: git et fossil, et j'ai pas aimé fossil, y compris pour les petits projets.
Pourquoi?
Parce que le UN exécutable, on s'en tamponne royalement avec les distro linux: apt-get et basta. Sous windows, "git" fonctionne maintenant correctement (je mets des " parce que ça semble être un fork… enfin j'ai pas trop cherché à connaitre le statut exact) et avec tortoiseGIT il est bien mieux intégré.
Le coup du "git c'est plus complexe", là encore, je ne suis pas d'accord.
L'usage de base à la même complexité que fossil, et la documentation de git est plus accessible. Faire un commit, revenir à une version précédente, ajouter ou supprimer des fichiers est simplissime, peu importe lequel.
Niveau confort d'utilisation, git permets d'activer la couleur, même si ce n'est pas dans la configuration par défaut. Ca n'a l'air de rien, mais pour moi qui travaille principalement avec une console, la couleur n'est pas un gadget kikoolol, mais bien une fonctionnalité qui me permets de voir bien plus rapidement l'information que je cherche.
Pour ce qui est du suivi des tickets, je n'ai pas creusé le problème de redmine, mais j'imagine que rien n'empêche de versionner également sa bdd de tickets.
Mais de toute façon, comme je l'ai dit, j'utilise principalement la console, et, là encore, fossil pêche, si ce n'est pas la fonctionnalité, c'est par la doc: impossible de trouver comment modifier un ticket depuis la console!
Obligé de passer par son interface web, que (moi )j'ai trouvée foireuse et inutilement complexe. Mais ça, les goûts et les couleurs…
Bon, à la décharge de fossil, je ne suis pas un grand expert des bugtrackers, et j'installe rarement(jamais en fait) des bugtracker en local sur ma machine. Quand je trouve un bug, généralement j'annote dans le code, un petit ///fixme: blah et je garde une trace du bug. Le bug tracker me semble bien plus utile pour un non développeur…
Pour finir, avec le versionning de la doc: en général, j'utilise simplement un dossier "doc" dans mon code source, pour ce qui est réservé à l'utilisateur. Pour ce qui est destiné aux dev, bah, c'est dans le code, tout simplement, donc versionné aussi.
Bon, j'ai bien bashé fossil, mais il faut l'admettre: j'adore l'idée derrière. Je trouve juste que ça manque de possibilités en ligne de commande en fait:
Alors, oui, fossil à ses avantages, mais par pitié, il faut cesser de dire que fossil est plus simple et accessible que les autres, surtout pour de petits projets (qui n'ont pas forcément besoin de tout l'arsenal de git). Ou alors faut donner des exemples, qu'on puisse juger.
En l'état, fossil est une excellente idée, qui manque cruellement de facilité d'utilisation sur le point qui fait de lui une bonne idée: l'intégration des tickets. En plus de ça, il manque aussi de confort en ligne de commande sur les fonctionnalités standards… (j'aime la couleur quand je fais un diff, j'y peut rien, j'ai toujours aimé noël et ses sapins…)
PS: je me suis battu plus de 3H d'affilée avec fossil pour utiliser son supposé avantage, j'ai fini par lâcher l'affaire, histoire de coder un peu, voulu faire quelques commit, afficher des diff etc… et j'ai compris qu'en fait, git, c'est pas mal.
[^] # Re: le git et le couvert
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: le git et le couvert
Posté par barmic . Évalué à 2.
Je ne peux pas juger fossil que je ne connais pas, mais je me retrouve complètement là dedans. Je ne supporte pas en CLI d'avoir des grep, des ls et autres sans
--color(ou équivalent). Les interfaces graphiques permettent de facilement hiérarchiser les informations alors qu'en CLI on a peu de souplesse là dessus, mais ce n'est pas impossible grâce notamment à la couleur. De la même manière avoir son prompt en couleur permet de distinguer facilement la sortie de différentes commandes. Bref les couleurs c'est pas de la « kikoolol ».Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: le git et le couvert
Posté par GeneralZod . Évalué à 6.
à installer non, à installer proprement et à maintenir -hint: le fork ChiliProject améliore de loin ce point-, c'est autre chose. Fossil remplit peut-être une niche mais il le fait très bien.
# Pas de révision d'historique
Posté par Christophe HENRY (site web personnel) . Évalué à 10.
J'ai un peu testé Fossil. Je me suis braqué à cause d'une de ses fonctionnalités : il interdit la révision de l'historique. Pas de rebase, pas de suppression de commit, etc.
Donc si je fais un truc un peu douteux, je ne peux pas le réviser localement avant de l'envoyer. Par exemple je fais un beau petit patch et je m'aperçoit que j'ai fait une faute de typo bien énorme. C'est parti pour un deuxième petit commit. Propre…
À traduire par :
Chez Mercurial où le rebase est possible, comme chez Git, on ne peut rebaser par erreur ce qui a déjà été envoyé. C'est déjà suffisant, le reste se règle entre gens consentants.
[^] # Re: Pas de révision d'historique
Posté par ckyl . Évalué à 5. Dernière modification le 30 mars 2013 à 11:08.
Je ne vois pas pourquoi tu as été inutilisé alors que c'est particulièrement vrai.
Le rebase local, et ce qui gravite autour, est LA fonctionnalité qui booste le plus la productivité d'un développeur et la propreté de la base de code.
À choisir il vaut souvent mieux un dépot SVN avec un client local type git qu'un DCVS qui n'offre aucune facon simple et rapide de travailler ses commits et d'itérer son dev.
"Le rebase c'est pourri" c'est le genre de chose qui quand tu les acummules font que bzr est presque une blague.
[^] # Re: Pas de révision d'historique
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
La philosophie de fossil pour ce genre de cas est de créer une branche: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg02143.html
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas de révision d'historique
Posté par Christophe HENRY (site web personnel) . Évalué à 4.
C'est aussi la philosophie ailleurs. On crée une branche "oulaCaPetetout", c'est souvent mieux. Mais lorsqu'arrive l'heure de la fusion, c'est bien mieux de (pouvoir) refaire l'historique. Typiquement, une modification se fait en 3 commits logiquement séparés. Mais j'avais oublié un truc dans le premier commit et l'avait ajouté dans le troisième pour que ça tourne en local.
Une fois que c'est prêt, je refait l'historique localement en replaçant la modification à sa place. Comme ça, ceux qui vont se charger de la fusion auront un travail plus simple. Sinon, il faudra justifier du oui, mais en fait j'avais juste oublié un truc. bouhouhou. Refaire son historique est aussi une marque de respect pour ceux qui vont recevoir le code.
Des boulets, il y en a partout. On pense évidemment au rebase sur des commits publics. Mercurial verrouille par défaut les commits publics, laissant quand même la possibilité de débloquer si nécessaire. De même, les commandes destructrices ne sont pas actives par défaut.
Bref, retirer des fonctionnalités parce que sinon c'est trop compliqué pour l'utilisateur est sans fondement.
[^] # Re: Pas de révision d'historique
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Pour les obsédés de la pureté de l'historique et autres révisionnistes, fossil n'est pas adapté.
Il y a deux besoins:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas de révision d'historique
Posté par ckyl . Évalué à 5.
Faire des historiques propres c'est avoir compris:
- Que l'on écrit le code une fois mais qu'on le lit et maintient pendant 10 ans après.
- Qu'un code ca se fait toujours relire avant d'être mergé. Et c'est faire preuve de respect pour le relecteur et surtout ca permet d'attraper plus facilement les erreurs (les changements ont une sémantique). Tu valides chaque changement. Puis l'enchainement des changements.
- Qu'un code ca se fait merger dans plein de branches (maintenance & co). Un historique propre et simple ca permet de pas partir à la chasse aux cherry pick ou de devoir detricoter un gros commit (par ce que l'absence de rebase poussent les gens à faire des gros commits).
- Qu'un code sera maintenu par quelqu'un d'autre et qu'il te pourrira quand il cherchera un bug ou cherchera si un changement était voulu.
Les obsédés sont juste des gens qui font leur boulot quoi… A ton avis pourquoi la plupart des projets libres fonctionnement par patch atomiques dont tu publies les révisions successives jusqu'a ce que ca soit mergé à un moment ?
[^] # Re: Pas de révision d'historique
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Je suis complètement d'accord, mais ça ne vaut que le projet où une grosse gestion de version fait gagner du temps.
Sur un projet de taille moyenne avec quelques codeurs principaux et des contributeurs occasionnels, le jeu n'en vaut pas la chandelle.
Le créateur de fossil et sqlite explique dans le lien que j'ai donné plus haut comment travailler comme ça avec fossil.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas de révision d'historique
Posté par Christophe HENRY (site web personnel) . Évalué à 1.
Évidemment, quand on est un minimum soigneux on est forcément un obsédé de la pureté. Mais bien sûr. Ça me fait penser aux "journalistes" quand il parlent d'utilisateurs de Linux : ce sont forcements des adeptes des Linux. Rien dans la demi-mesure !
Les branches ne changent rien à la situation. Elles permettent d'envisager plusieurs axes de développement, mais ne garantissent pas la propreté du code. Ensuite, il faut quand même comprendre qu'une fois que c'est publié, c'est publié. Il n'y a pas de révisionnisme qui tienne ici. C'est d'ailleurs tout l'intérêt de nettoyer ses commits localement, parce qu'à après il est trop tard.
[^] # Re: Pas de révision d'historique
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
On peut être soigneux tout en conservant les erreurs dans l'historique. Tout dépends de comment tu conçois ce dernier: est-ce un roman ou une chronique?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas de révision d'historique
Posté par Christophe HENRY (site web personnel) . Évalué à 1.
D'un point de vue personnel, tout se vaut. Mais lorsqu'il faut communiquer vers autrui, ça se gâte. Surtout si le projet est chargé et qu'on veut être lisible plutôt que de susciter l'inquiétude chez la personne qui va examiner la requête.
[^] # Re: Pas de révision d'historique
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Si le projet est chargé, tu sors du cadre d'utilisation de fossil (petit à moyen projet, petite team qui se connait bien, quelques contributeurs occasionnels).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas de révision d'historique
Posté par Christophe HENRY (site web personnel) . Évalué à 1.
Le problème c'est de définir quand il est chargé. Ça m'est arrivé de charger tout seul un projet dans mon coin. Un truc sur lequel j'ai couru plusieurs choses à la fois. Si je veux encore pouvoir lire l'historique plus tard, j'ai intérêt à être propre de suite.
Évidemment, je n'irai pas reprocher à une petite équipe et/ou un débutant dans le domaine son manque de clarté des commits. Cependant, je veux pouvoir le faire à titre personnel et je veux aussi que d'autres le puisse, indépendamment de la taille de l'équipe.
[^] # Re: Pas de révision d'historique
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
C'est ce que je m'étais dit en commençant Newton Adventure: autant prendre git, c'est la référence et si mon projet grossit, je serais prêt.
Et puis j'en ai eu marre de passer plus de temps sur la gestion de version et la maintenance du site que sur le code tout en ayant un historique dégueu, car ça se terminait souvent en rage commit.
git est très bien, mais il y a des projets auxquels je ne remonte pas mes corrections juste parce que ça me gonfle de passer une soirée à me battre avec pour faire un commit propre.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas de révision d'historique
Posté par ckyl . Évalué à 3.
C'est pas une question de taille d'équipe ou d'outil. C'est une question d'organisation de son travail.
Si tu n'arrives pas un avoir un historique propre c'est que tu t'es laissé embarqué et que tu es en train de faire n'importe quoi. À chaque fois que je me retrouve à faire des choses que je ne voudrais pas (et c'est bien trop souvent) c'est que j'ai merdé lors du dev en faisant tout et n'importe quoi.
C'est comme les tests, ça coute pas plus cher bien au contraire… Ça te force à réfléchir à chaque incrément, à bien le délimiter, le spécifier et le tester. Si tu passes cette étape, t'as l’impression d'aller plus vite mais tu fais juste plus n'importe quoi.
[^] # Re: Pas de révision d'historique
Posté par barmic . Évalué à 2.
C'est de la théorie. Oui ça apporte beaucoup beaucoup de choses de faire des tests, mais c'est très couteux. Le nier c'est se voiler la face. Tu y gagne dans le car tu limite les gros problèmes avenir et tu es à peut prêt sûr de ne pas avoir de régression (pour en être certains, il faut être sur de ses tests et ça revient au même que de tester le code initial, il faut tester les tests…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas de révision d'historique
Posté par ckyl . Évalué à 3. Dernière modification le 30 mars 2013 à 23:01.
Ça na rien de la théorie, c'est très pratique et pragmatique.
Sans tests:
- Tu livres de la merde (je trouve toujours au moins un bug à chaque fois que j'écris un test)
- Tu n'as pas à te poser la question de ce que tu es en train d'écrire. Donc tu écris un truc pourri et non spécifié
- Tu fais un gros doigt d'honneur au mec qui reprendra ton code qui ne saura jamais ce que c'était sensé faire
- Tu empêches les gens d'ajouter des tests par la suite par ce que tu codes pas testé est pas écrit pour être testable
- Tu n'as aucun moyen de traquer tes régressions
- Tu plombes la productivité de ton équipe en empêchant de détecter les régressions.
Tu ne perds pas de temps à écrire des tests. Ce que tu peux faire par contre c'est accepter de livrer de la merde. J'appelle pas ça gagner du temps mais plutôt, grappiller quelque heures maintenant pour perdre des semaines ou des mois dans pas longtemps et pour toujours. Ça coûte toujours beaucoup plus cher de faire les tests après.
Pour le moment je pense que je peux encore compter sur mes doigts le nombre de cas ou l'absence de test pouvait se justifier. Par contre il me faudrait beaucoup plus de doigts pour compter le nombre de fois ou on a essayé de le justifier et on s'est mangé grave ensuite. Être un petit projet ou tu codes tout seul ne change rien la dessus.
Y'a un peu une raison si toutes les équipes finissent fatalement par mettre "unit test", "fonctional test", "code review" et "QA review" dans leur definition of done. Pouvoir encore penser que ça coûte cher me fait juste peur en fait.
[^] # Re: Pas de révision d'historique
Posté par barmic . Évalué à 6. Dernière modification le 31 mars 2013 à 01:11.
Tu amalgame les tests et la documentation. Pour le reste des points je suis tout à fait d'accord.
C'est là où tu fait erreur, les tests c'est pas des trucs qui se font en quelques heures. En quelques heures c'est peut être quelques tests unitaires que l'on écris (sans compter leur maintient). Là où tu fais vraiment de la non régression et où tu présente comment doit fonctionner le logiciel c'est avec des tests fonctionnels/d'intégration. Ils prennent à minima 30% du temps de développement d'une fonctionnalité. Il faut définir quand/comment tu les lance (généralement c'est via un serveur d'intégration continue) et dès que tu fait un logiciel graphique ça devient très complexe à tester (à moins que tu accepte de ne pas tester la couche présentation du logiciel).
Je fais du test sur le projet sur le quel je travail. Ça nous prend énormément de temps, on continue de le faire parce qu'on sait ce que ça nous apporte comme sécurité, mais de là à le présenter comme un coup négligeable (quelques heures), ce serait une fumisterie. La qualité logiciel ça a un coût et ce n'est pas quelques chose de simple à faire (ce n'est pas juste un manque de rigueur et/ou de volonté).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas de révision d'historique
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Tes remarques sont tout à fait valables pour des projets en entreprise où la stabilité est un critère et dont les résultats sont mesurables objectivement.
Maintenant pour un jeu…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas de révision d'historique
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 31 mars 2013 à 19:13.
J'ai des cas de figure où acheter le matos pour pouvoir faire le test me coûterai quelques milliers d'Euros (saloperie de cartes pro) et où le test n'est pas automatisable, donc un petit gars pour le faire, et écrire un simulateur prendrait quelques semaines sans garantie que le simulateur fasse toujours la même chose que la carte, alors en fait c'est le client, le pauvre, qui fait la recette une fois tous les 6 mois quand il change de version, tant pis pour le test à chaque commit.
Un autre cas de figure est où la criticité de la chose n'est pas importante (genre un jeu libre tranquille dans son coin), et donc le coût du test à créer est important.
Sans compter les prototypes, les essais pour voir si il y a assez de clients (sinon poubelle), le time to market (vaut mieux un truc buggué à l'heure qu'un truc non buggé dans un marché déjà saturé par les autres), pas pour rien que gmail (par exemple!) a été en beta pendant des années (fallait remplir l'espace "asap").
Un avantage du libre est de séparer les tâches aussi : tu codes, tu balances une RC, les autres testent suivant leur scénarios qu'ils connaissent mieux que toi (toi tu vas créer plein de scénarios que personne n'utilise), genre un Linux ça a combien de RC parce que tes tests unitaires n'ont pas été suffisants?
Sans compter le test qu'il faut pour débugger, car le code est juste mais le test est faux.
Bref, je tiens juste à signaler que oui, c'est important, mais… Ca dépend, en fait. De beaucoup de choses (taille ou criticité de la cible ou des délais ou…)
[^] # Re: Pas de révision d'historique
Posté par ckyl . Évalué à 1.
Je ne répondrais pas à la Zenitramerie qui consiste à trouver les contre exemples.
Ce n'est pas vraiment une question de criticité. Pour les trucs critiques les procédures et le type de test sont différentes et complémentaire. C'est d'ailleurs pour ca que la QA, les test engineers et le release engineering existent.
La troisième version c'est il vaut mieux un truc qui marche maintenant avec une feature de moins. Plutôt que d'accumuler une dête technique monstrueuse sous le pretexte du TTM.
D'ailleurs ton TTM il s'écroule après 6 mois quand une équipe passe 50% de son temps à résoudre ses problèmes et faire du support pendant que l'autre continue au même rythme voir devient plus véloce. Les deux ont livrés à temps pourtant…
C'est mon constat ayant bossé sur des codes de toute taille et dans quelques domaines où les tests sont un peu plus compliqués que dans la plupart des domaines (systèmes distribués, réseaux, grosse appli JS, moteur de recherche, big data etc.).
Et j'ai aussi eu l'occasion d'experimenter la chute de vélocité à moyen terme et l'empilement des BR d'une équipe quand on a joué la carte du "trop compliqué à tester" pendant quelques mois. On a passé un/deux mois à faire le taff qui aurait du être fait, plus longtemps que si on l'avait fait pendant le dev, et c'est reparti…
Quand je code tout seul pour le fun c'est étrangement la même chose.
Tu parles encore d'un truc dont tu ne connais absolument rien. T'as une idée de comment fonctionne l'engineering et la code base chez Google ? Tu as des fait sur gmail en particulier ?
AFAIK Y'a 0 TU dans Linux… Au passage prendre Linux comme exemple pour la gestion de projet est souvent une très mauvaise idée.
C'est étrange. J'ai du bosser sur quelques millions de ligne de codes et les seuls tests que j'ai eu a debugger sont ceux de gens qui soit disaient que c'était compliqué de tester, soit qui s'en foutait et soit qui pissait du mauvais code. En se penchant dessus on fait quelque chose qui juste marche. Dans les autres cas, la seul raison d'y toucher était un changement fonctionnel (et c'est à ca que ca sert).
Comme toujours il y a quelques raisons valides. Et comme souvent les gens utilisent ces quelques mais pour se convaincre qu'ils sont dedans et couper toute reflexion plutôt que de réfléchir à pourquoi c'est difficile et trouver des réponses efficaces. Non la couverture n'est pas un objectif. Non le but n'est pas d'appliquer bêtement un principe. Le but c'est d'ameillorer la qualité, la vélocité et donc te permettre de coder des nouveaux trucs plutôt que de débugger ou de passer 6 mois sur 12 en recette.
[^] # Re: Pas de révision d'historique
Posté par ckyl . Évalué à 3.
Je savais bien que j'avais un truc dans mes bookmarks là dessus: http://www.informit.com/articles/article.aspx?p=1854713
Google dit exactement la même chose que moi; tant sur l'importance du test dans le dev et que ca ne doit pas le ralentir, que sur le fait que troquer la qualité n'est jamais un bon choix. Bon c'est beaucoup beaucoup plus intéressant que ce que je dis donc ca vaut vraiment le coup de prendre le temps qu'il faut pour le lire.
Du coup je vais acheter le bouquin, je l'avais loupé…
[^] # Re: Pas de révision d'historique
Posté par barmic . Évalué à 3.
Ça te permet de sortir une nouvelle version en étant certain de n'avoir aucune régression, mais alors aucune :) (la plupart touchent soit tous les terminaux soit (entre autre) des Nexus 4/7).
Je ne sais pas comment fonctionne Google, mais je présume que c'est comme dans toutes les grandes boites : tout le monde ne travail pas de la même façon et les guidelines des uns n'est pas forcément respectés par les autres (à tors ou à raison). Donc dire que « Google dit » quand il s'agit du directeur des tests de Chrome me semble un peu surfait (ça n'enlève rien à la pertinence de ce qu'il dit).
Pour Android je suis sûr qu'ils ont des tests, leur tests ne couvrent juste pas tout. Soit on se dit que c'est des manchots, soit on reconnaît que faire du test c'est un vrai métier, qui demande des compétences et donc n'est pas si anodin et facile que cela (la preuve chez Chrome, ils ont un directeur juste pour ça (et donc un paquet de personnes qui ne travaillent qu'à faire du test)).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas de révision d'historique
Posté par ckyl . Évalué à 2. Dernière modification le 31 mars 2013 à 23:55.
On est obligé d'être aussi caricatural que de penser que par ce que tu tests il n'y a aucun bug ? Et que par ce que tu vas quand même laisser passer des choses ca ne sert à rien ?
Tu devrais vraiment vraiment le lire, tu arrives à dire exactement le contraire de ce qu'y est écrit ;) Il y a tellement de subtilités, de nuances et d'approches derrière "test".
Je caricature en effet, vu qu'il y'a beaucoup de talk et d'articles qui se recroises et qu'au passage Google a laissé publier le livre.
J'ai répondu spécifiquement sur Google/Gmail par ce que c'était l'exemple donné. Tu peux aller voir ce qu'il ce passe partout où les gens arrive à continuellement pousser du code et de l'innovation tu retrouves les mêmes ingrédients. Et pas grand monde te dira que les tests c'est le job de la QA, que ce n'est pas important ou que c'est un coût.
[^] # Re: Pas de révision d'historique
Posté par barmic . Évalué à 4.
Je ne sais pas ce que tu entends exactement par QA, mais dans le genre de cas que tu donne, il y a un service dédié aux tests (encore une fois tu cite le directeur des tests de Google Chrome, il a un service derrière lui - sinon il ne serait pas directeur). Mais ce n'est pas parce qu'il y a un service spécialisé, que ça n'est pas une responsabilité commune. L'une des raisons d'avoir un service séparé c'est que les bonnes pratiques veulent que la personne qui écris les tests ne soit pas la même personne qui code la fonctionnalité, ça pousse à spécifier la fonctionnalité avec le bon niveau de précision.
Tu ne m'a pas vu dire que ce n'est pas important au contraire.
Que tu le voit comme un coût, comme une charge ou que tu le facture simplement au client je dis juste que c'est chère. Si tu veux on peut le dire autrement (ça te conviendra probablement mieux) : « écrire du logiciel de qualité c'est chère » ou « un logiciel de qualité c'est chère » (même si ce prix est supporté par un geek dans sa cave).
Ce que je trouve dommage c'est de dire que ça prend quelques heures. Ça c'est faux ça prend du temps que tu récupère ailleurs dans une bonne partie des cas peut être, mais ça ne change pas que l'écriture des tests ça prends du temps si tu veut faire un minimum de couverture et que tu ne te limite pas aux tests unitaires.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas de révision d'historique
Posté par freem . Évalué à 1.
Hum, programmation par contrat? Le contrat est plus simple à écrire qu'une batterie de tests (quelques lignes avant la def de la méthode) et permets d'ajouter facilement des tests (puisque l'on sais ce qui devr**ait** être) non?
D'autant que celle-ci est, selon les langages, plus ou moins vérifiable par le compilateur (C++ par exemple en a un support partiel, avec "const", les références, "nothrow" ou "static", et il existe un langage, eiffel je crois, qui est complètement orienté vers cette façon de faire)…
La question est réelle, hein, c'est juste que je trouve effectivement qu'écrire des tests pour la moindre fonction, comme on peut voir certains le recommander me semble effectivement extrêmement coûteux.
[^] # Re: Pas de révision d'historique
Posté par GuieA_7 (site web personnel) . Évalué à 1.
En pratique, quand tu écris tes tests en même que ton code (je te conseille de regarder ce qu'est le Test Driven Development) tu es rapidement plus productif qu'en écrivant ton code et en le testant ensuite "à la main". Lorsque tu dois écrire une fonction un peu 'poilue' (avec 2 "if else" consécutifs par exemple tu as déjà 4 cas à vérifier), repasser tous les cas manuellement prend énormément de temps ; ceci dit c'est encore plus long au final lorsque c'est ton client qui tombe sur le bug, met 3 heures à mal te le décrire au téléphone, que tu passes 1h à essayer de le reproduire, puis 3h à corriger ton code d'il y a 6 mois en priant de ne pas faire de régression. Alors que rejouer tes tests sur ladite fonction prend 2 secondes, et tu peux donc les rejouer entre chaque modifications pendant que tu codes ta fonction.
Il y a quelques années, j'ai codé, en TDD, 30K lignes de code en 1 an et demi (+ 45K lignes de tests). Pendant la même période, mon collègue qui travaillait sur le me logiciel, et qui testait à la main avait fait 18K lignes, et 95% des bugs qui remontaient étaient chez lui.
J'aimerai aussi l'avis d'un codeur pratiquant le Contract Driven Development ; ne l'ayant jamais pratiqué moi même je peux me tromper, mais a priori je trouve assez simple d'écrire les tests pour une fonction de tri par exemple ça pourrait donner:
ce qui es quand même très simple. Alors que par contrat, j'imagine qu'il faut tester que ton résultat contient tous tes éléments de départ, et uniquement ceux-là, et vérifier qu'ils sont correctement ordonnés. Ça me semble plus pénible à écrire.
[^] # Re: Pas de révision d'historique
Posté par freem . Évalué à 0.
J'ai déjà jeté un oeil (donc, je n'ai pas creusé énormément) du côté du TDD, justement.
Le principe me semble réellement intéressant, mais la quantité de code de tests à écrire au début de l'application me semble quand même vachement excessive, puisque, selon les documents que j'ai lus à ce sujet il faudrait aller jusqu'a effectuer des tests pour tout, strictement tout…
Sachant que la moyenne de mes méthodes ne dépasse pas les 15 lignes (mes "algorithmes" se situent en fait plus dans le diagramme de classes, chacun s'occupant uniquement de ses affaires. Ca n'évite pas les bugs, mes le code est plus lisible pour moi, et 20 fois plus simple à réutiliser), j'imagine que tu peux comprendre qu'écrire 4 fois plus de code de test par classe que de code réel me semble trop lourd.
En gros, avec la programmation par contrat (de ce que j'en ai lu, je n'ai pas assez d'expérience avec pour me proclamer dev par contrat…) tu indiques au dev ce qu'il doit fournir à ta méthode -préconditions- (les langages à typage fort comme C++ permettent donc une vérification basique des contrats à la compilation, si les prototypes sont bien écrits), les invariants et les post-conditions. Si le contrat n'est pas respecté par l'appelante (mauvaises pré-conditions donc) le comportement est indéfini.
Du coup, il est simple de produire les tests, et si tu utilises pimpl (si je me lourde pas sur le nom), tu peux instrumenter très simplement le code, par exemple:
Personnellement, je préfère garder les vérifications de contrat en dehors de la version de débogage: ça consomme peut-être un peu de ressources, mais tu as la possibilité de faire des messages d'erreur clairs, que l'utilisateur peut te copier/coller (voire ton application t'envoie directement le rapport d'erreur par mail ou sur bugtracker, pourquoi pas, il suffirait d'implémenter un gros try{…}catch(std::exception &e){…} dans le main après tout) et qui t'indiquent quel bloc de code pose problème.
Du coup, pour détecter une merde dans le déploiement c'est assez pratique, je dois l'avouer, alors qu'il ne me semble pas que le TDD permette de vérifier que le problème vienne de l'installation de ton application, puisque les tests ne sont pas inclus dans le binaire (je ne crache pas sur TDD, au contraire, je ne fais que demander ce que tu en penses).
Ca, ça m'a déjà économisé pas mal de temps (et donc plus ça va, et plus j'utilise cette histoire de contrats) quand je balance mon boulot d'une de mes machines à une autre.
Et vu que ton contrat est clair, je me dis que si jamais à un moment… bon, ok, quand tu as une merde, il est simple d'ajouter un test de non régression, qui vérifie uniquement cette merde. Du coup, moins de "perte de temps" (note les guillemets) à écrire et maintenir des tests qui ne serviront potentiellement jamais, mais tu conserves la possibilité d'éviter une régression ou le retour d'un bug.
Je ne sais pas si je suis très clair, mais, je le répète: je ne suis expert ni dans le TDD, ni dans le CDD (en encore moins dans les CDI XD bon ok je sors)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pas de révision d'historique
Posté par freem . Évalué à 1.
Tu n'as rien raté, sauf qu'en fait la programmation par contrat, à ce que j'ai lu, consiste juste à définir ce que ta fonction attends/crache/ne change pas.
Tu peux ensuite les vérifier avec, effectivement, des assertions, si tu le souhaites.
C'est un peu comme tes tests, je n'ai rien raté si j'affirme qu'il ne s'agit que de petits programmes ;)
L'important n'est pas la technique utilisée, mais la façon de le faire, non?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # prog par contrat
Posté par freem . Évalué à 1.
Si le langage en est capable, il peut tester une partie du contrat statiquement:
Dans le cas de C++, langage que je connais le mieux, on peut par exemple utiliser le prototype pour dire que la méthode ne modifieras pas la classe, que tel paramètre est un paramètre d'entrée (passage par valeur ou en spécifiant const), d'entrée/sortie (passage de référence), ou juste de sortie (valeur de retour. Si on en veut plusieurs, on peut utiliser un tuple, mais perso je ne suis pas trop fan des tuple donc je préfère utiliser un paramètre normal avec une référence) et bien entendu, imposer le type.
Mais il est évident que tu ne peux pas vérifier que x>0 à la compilation… (quoique, si x est calculable à la compilation, C++11 nous a offert quelques outils pour ça)
En fait, je ne pense pas qu'il soit logique d'opposer les deux types de programmation: un contrat bien établi permet d'écrire des tests plus facilement, avec en plus la possibilité d'instrumenter le code en interne, ce qui peut rendre les bugs plus simples à reporter pour l'utilisateur.
J'ai encore pas mal de mauvaises pratiques, héritées de mon auto apprentissage et des cours que j'ai eus (il faut dire ce qui est), donc j'avoue avoir beaucoup de mal à écrire de tests unitaires quand je bosse sur mes projets persos. Au boulot, vue la tronche de l'environnement que j'ai eu la "chance" d'utiliser, je n'ai pas vraiment essayé… (Déjà si on pouvait commencer par clarifier le workflow, et utiliser un vrai VCS, ce serait un net progrès… m'en fout, dans 2 mois je me casse)
Après, comme je l'ai dis, je suis loin d'être expert dans le domaine de la prog par contrat, alors ma vision est peut-être très limitée. Le document qui m'a fait découvrir le concept est ici
[^] # Re: Pas de révision d'historique
Posté par GuieA_7 (site web personnel) . Évalué à 1.
Le TDD n'empêche évidemment pas de mettre des assertions dans le code, ainsi que des logs, qui sont en effet bien plus indiqués pour vérifier que l'installation est correcte.
Je peux le comprendre, et ta façon de penser est naturelle pour quelqu'un n'ayant pas pratiqué le TDD. Mais là où tu te trompes c'est qu'on s'en fout du nombre de lignes, ce qui compte c'est le temps que tu mets à écrire ta feature correctement (si tu torches un code vite fait plein de bugs, il faut compter tout le temps de debug, ainsi que le temps que tes collègues ont perdu etc…).
Je t'ai donné un vrai exemple tiré de mon expérience ; mon collègue pensait réellement gagner du temps en n'écrivant pas de test. La réalité c'est que j'ai quand même écrit plus de code utile que lui pendant le même temps (le nombre de lignes de code n'est pas une super métrique, mais en l'occurrence mon code était bien factorisé et objectivement bien meilleur pour le même prix).
Tu n'a pas à te dévaloriser parce que tes fonctions font rarement plus de 15 lignes : c'est normal et c'est pareil pour la plupart des gens ; ou bien ça devrait l'être, et la super fonction de la mort de 300 lignes peut être réécrite proprement en 20. Quant à écrire du code objet bien modulaire, là encore c'est en parfaite accord avec le TDD, où tu es obligé, si tu le fais bien, à écrire du code facilement testable.
En te fournissant un filet de sécurité permanent, tu en viens à refactorer ton code en permanence sans avoir peur des régressions (le fameux syndrome du "ça marche je n'y touche plus"). C'est vraiment très agréable, et ça a complètement changer ma vision du code, sans exagérer. Écrire les tests après c'est vraiment pénible, mais les écrire en même temps est amusant (mais il faut essayer c'est difficile à croire).
Oui il m'arrive lorsque j'écris un prototype/proof of concept de ne pas le faire en TDD, mais le faire lorsque l'essai est transformé (et écrire alors les tests pour le "vieux" code à posteriori). Ce n'est pas un dogme non plus :)
[^] # Re: Pas de révision d'historique
Posté par freem . Évalué à 0.
Brut, non. Par contre… CCCC (superbe outil pour moi) donne quelques métriques liées au nombre de lignes qui sont très utiles: % de code commenté (bon, ça ne prend pas en compte le fait qu'un nom de fonction ou de variable explicite équivaut à 3 lignes de commentaires, bien sûr), lignes / fonction, lignes / classe…
Je ne me dévalorise pas, c'est juste que je suis habitué à ce que mon code ne ressemble pas à celui des autres. Ca a commencé dès que j'ai vu à quoi ressemblait un prof de dev (moi auto-didacte qui avait donc mon propre style, lui qui me sortait des trucs genre "essaie d'avoir les mêmes noms que les autres, d'utiliser des int et pas des short…" et moi qui pensait "plutôt arrêter le dev". Je ne connaissais pas encore l'expression pisser du code… c'est ça qu'il enseignait.)
Pour moi les grosses fonctions qui contiennent tout l'algo sont plus une preuve de code mal pensé qu'autre chose, vu que la taille d'une fonction est fréquemment proportionnelle aux nombre de choses qu'elle fait, alors qu'elle n'est censée en faire qu'une.
D'ailleurs, me suis aperçu qu'a chaque fois que je fais un truc qui dépasse les 50 lignes, en dehors du gros switch des familles (que je hais en plus, mais pas toujours le choix) a terme je chope des bug ou je dois réutiliser une partie du gros bloc ailleurs… donc bon, au final je gagne mon temps.
En tout cas, la dernière fois que j'ai essayé sur un de mes projets (un éditeur de texte en console), je n'en ai pas perçu les avantages. Il faut dire que ça m'a tellement soulé d'écrire des tests que j'ai arrêté au bout de 3 fonctionnalités.
Je pense qu'il faudrait que je voie un projet réel qui utilise TDD pour me donner le déclic plus vite. Sinon tel que je me connais, je dirais que je finirai par l'avoir, mais dans quelques années :D
[^] # Re: Pas de révision d'historique
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Il est clairement plus pratique de commencer avec du code "calculatoire", les IHM sont pénibles à tester et souvent on fait l'impasse dessus.
Ce qui est souvent mal compris dans le TDD, c'est qu'il ne faut pas écrire 150 lignes de tests avant de commencer le vrai code (c'est chiant et pas hyper efficace). Il faut écrire un test avec une assertion, faire péter le test, coder pour faire passer le test de la manière la plus simple, puis recommencer le cycle. C'est assez déroutant au début, parce que les premiers tests qu'on écrit ont vraiment l'air stupide, genre:
mais on comprend l’intérêt plus tard quand on code les cas vicieux et que ces assertions détectent une régression.
[^] # Re: Pas de révision d'historique
Posté par Troy McClure (site web personnel) . Évalué à 8.
Faut aussi aimer debugger et maintenir des tests puisque 90% du temps le bug est dans le test. Ah c'est chouette le developpement moderne on passe son temps à écrire des tests les debugger, et nettoyer l'historique du DVCS pour que tout soit bien propre
[^] # Re: Pas de révision d'historique
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Oui mais au moins, c'est bô !!!
T'as plein de tests et un bel historique qui laissent penser que t'es le plus fort :D
[^] # Re: Pas de révision d'historique
Posté par Seb (site web personnel) . Évalué à 1.
Concernant Mercurial (voir Git, mais je connais moins bien), le principe des phases que tu mentionnes est vraiment très pratique. Seulement, existe t-il un moyen de pusher ses révisions sur un dépôt externe pour sauvegarder/mettre de côté son travail (pas forcément avec l'objectif de le partager) pour pouvoir le reprendre depuis une autre machine, sachant qu'à partir du moment où l'on push, les changesets sont marqués comme publiques et donc immuables, et l'on doit forcer le passage à l'état brouillon avec hg phase pour ensuite les retravailler avec MQ ou autre (chose pas très pratique à l'usage).
Globalement, une fonctionnalité peut être longue à développer et j'ai besoin de passer mon travail d'une machine à l'autre et un jour pouvoir retravailler tout mon historique avant de l'inclure sur la branche principale. Comment vous vous y prenez dans ce genre de situation ?
[^] # Re: Pas de révision d'historique
Posté par ckyl . Évalué à 2.
C'est la même justification et solution que bzr, et ca explique aussi pourquoi tout le monde trouve bzr improductif (bon y'a pleins d'autres raisons aussi).
Tant que c'est local, je veux pouvoir réordonner, fusionner, modifier, supprimer mes commits. Ca n'a aucun sens de:
Se tapper des historiques pourris type: "Commit 1", "Oups ajout du fichier manquant", "Commit 2", "Oups correction d'un bug introduit par commit 1". Quand toutes ces étapes ont été attrapées avant que le code soit publique.
Perde le découpage des commits (si tu sors le diff de ta branch pour mettre à plat comme recommande certains SCM. Sisi ! ).
Ton code avant de passer publique, il passe en code review. Avoir un historique propre ca permet de faire des codes review simples. Et pouvoir modifier ses commits ca permet d'updater facilement ses patchs suite à la code review.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.