Journal Chiselapp ferme ses portes

Post√©¬†par¬† (site web personnel) . Licence CC¬†By‚ÄĎSA.
√Čtiquettes¬†:
10
29
mar.
2013

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¬† . √Čvalu√©¬†√†¬†7.

    il ne doit en rester qu'un !

    j'espère que ca sera mercurial :)

    • [^] # Re: le git et le couvert

      Post√©¬†par¬† (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¬† (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¬† (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¬† (site web personnel) . √Čvalu√©¬†√†¬†8. Derni√®re modification le 30/03/13 √† 10:41.

          Installer redmine et git, je ne vois pas en quoi c'est "beaucoup plus complexe".

          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¬† . √Čvalu√©¬†√†¬†5.

            Pour l'installation, fossil c'est juste UN exécutable. A l'utilisation Git est beaucoup plus compliqué à utiliser.

            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¬† . √Čvalu√©¬†√†¬†-1.

            […] je peux √©crire de la doc ou des rapports de bug m√™me si je suis dans le train.

            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¬† . √Č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:

            • couleur (manque extr√™mement cruel pour moi)
            • pas de gestion des tickets (qui aurait rendu l'outil r√©ellement un outil en ligne de commande, et non un outil b√Ętard obligeant √† utiliser √† la fois la CLI et la GUI)
            • et l'interface web qui pourrait difficilement √™tre pire, mais √ßa, √ßa doit √™tre li√© √† mes go√Ľts. Je ne parle bien s√Ľr pas du c√īt√© esth√©tique dont je me contrefout (et est customisable √† souhait, plut√īt ais√©ment d'ailleurs), mais bien du fait que je trouve ce truc tr√®s compliqu√© √† configurer: il faut quand m√™me √† chaque fois ou presque modifier des commandes SQL, qui m'ont sembl√© plut√īt cryptiques. Je n'ai pas eu la m√™me sensation avec les divers bugtrackers utilis√©s par sourceforge, savannah, github ou bitbucket.

            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¬† (site web personnel) . √Čvalu√©¬†√†¬†4.

              j'aime la couleur quand je fais un diff

              fossil settings diff-command colordiff
              
              

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: le git et le couvert

              Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

              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.

              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¬† . √Čvalu√©¬†√†¬†6.

          Installer redmine et git, je ne vois pas en quoi c'est "beaucoup plus complexe"

          à 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¬† (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…

    The lack of a "rebase" function is considered a feature of Fossil, not a bug.

    À traduire par :

    L'absence d'une fonction "rebase" est considérée comme une fonctionnalité, pas un bug.

    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¬† . √Čvalu√©¬†√†¬†5. Derni√®re modification le 30/03/13 √† 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¬† (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¬† (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¬† (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:

          • une gestion de version simple: archiver, partager, revenir en arri√®re en cas de b√™tise, faire quelques branches pour la maintenance ou les √©volutions.
          • une gestion de version au cŇďur du d√©veloppement: pouvoir g√©rer des milliers de contribution, avoir un historique/documentation, g√©rer 42 variantes.

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Pas de r√©vision d'historique

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†5.

            Pour les obsédés de la pureté de l'historique et autres révisionnistes

            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¬† (site web personnel) . √Čvalu√©¬†√†¬†3.

              Faire des historiques propres c'est avoir compris

              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.

              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 ?

              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¬† (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¬† (site web personnel) . √Čvalu√©¬†√†¬†3.

              √Čvidemment, quand on est un minimum soigneux on est forc√©ment un obs√©d√© de la puret√©.

              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¬† (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¬† (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¬† (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¬† (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¬† . √Č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¬† . √Čvalu√©¬†√†¬†2.

                          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.

                          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¬† . √Čvalu√©¬†√†¬†3. Derni√®re modification le 30/03/13 √† 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¬† . √Čvalu√©¬†√†¬†6. Derni√®re modification le 31/03/13 √† 01:11.

                              • 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 amalgame les tests et la documentation. Pour le reste des points je suis tout à fait d'accord.

                              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.

                              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¬† (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¬† (site web personnel) . √Čvalu√©¬†√†¬†5. Derni√®re modification le 31/03/13 √† 19:13.

                              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

                              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¬† . √Čvalu√©¬†√†¬†1.

                                J'ai des cas de figure o√Ļ acheter le matos pour pouvoir

                                Je ne répondrais pas à la Zenitramerie qui consiste à trouver les contre exemples.

                                Un autre cas de figure est o√Ļ la criticit√© de la chose n'est pas importante

                                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.

                                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)

                                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.

                                Pas pour rien que gmail (par exemple!) a été en beta pendant des années

                                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 ?

                                genre un Linux ça a combien de RC parce que tes tests unitaires n'ont pas été suffisants?

                                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.

                                Sans compter le test qu'il faut pour débugger, car le code est juste mais le test est faux.

                                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).

                                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…)

                                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¬† . √Čvalu√©¬†√†¬†3.

                                pas pour rien que gmail (par exemple!) a été en beta pendant des années (fallait remplir l'espace "asap").

                                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¬† . √Č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¬† . √Čvalu√©¬†√†¬†2. Derni√®re modification le 31/03/13 √† 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 ?

                                    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)).

                                    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".

                                    Donc dire que ¬ę Google dit ¬Ľ quand il s'agit du directeur des tests de Chrome me semble un peu surfait

                                    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¬† . √Čvalu√©¬†√†¬†4.

                                      Et pas grand monde te dira que les tests c'est le job de la QA,[…]

                                      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.

                                      que ce n'est pas important

                                      Tu ne m'a pas vu dire que ce n'est pas important au contraire.

                                      ou que c'est un co√Ľt.

                                      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¬† . √Čvalu√©¬†√†¬†1.

                              • 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 emp√™ches les gens d'ajouter des tests par la suite par ce que tu codes pas test√© est pas √©crit pour √™tre testable

                              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¬† (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:

                                assertEqual([], sort([])
                                assertEqual([1], sort([1])
                                assertEqual([1, 2], sort([1, 2])
                                assertEqual([1, 2, 3, 4], sort([4, 2, 1, 3])
                                
                                

                                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¬† . √Čvalu√©¬†√†¬†0.

                                  je te conseille de regarder ce qu'est le Test Driven Development

                                  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.

                                  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.

                                  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:

                                  int foo::bar(std::string const& input, double &output)
                                  {
                                    #ifndef NDEBUG
                                    if( false == input.empty() )
                                      throw std::logic_error(...);
                                    int ret=fooimpl(input, output);
                                    if( output < 1.0 )
                                      throw std::logic_error(...);
                                    return ret;
                                    #else
                                    return fooimpl(input, output);
                                  }
                                  
                                  

                                  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¬† . √Čvalu√©¬†√†¬†0.

                                    Ce commentaire a été supprimé par l’équipe de modération.

                                    • [^] # Re: Pas de r√©vision d'historique

                                      Post√©¬†par¬† . √Č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¬† . √Čvalu√©¬†√†¬†0.

                                        Ce commentaire a été supprimé par l’équipe de modération.

                                        • [^] # prog par contrat

                                          Post√©¬†par¬† . √Č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¬† (site web personnel) . √Čvalu√©¬†√†¬†1.

                                    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).

                                    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.

                                    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.

                                    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).

                                    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),

                                    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).

                                    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

                                    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¬† . √Čvalu√©¬†√†¬†0.

                                      le nombre de lignes de code n'est pas une super métrique

                                      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…

                                      Tu n'a pas à te dévaloriser

                                      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.

                                      ta façon de penser est naturelle pour quelqu'un n'ayant pas pratiqué le TDD

                                      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¬† (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:

                                        def test_empty():
                                             assertEqual([], sort([]))
                                        
                                        def sort(l):
                                            return []
                                        
                                        

                                        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¬† (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¬† (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¬† . √Č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:

        1. 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.

        2. 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.