Journal Bonnes pratique pour le développement

Posté par  .
Étiquettes : aucune
0
11
jan.
2007
Bonjour,
je suis intéressé par ce que vous considérez comme de bonnes pratiques, que vous avez vous-même expérimenté.

Pour préciser je suis plus intéressé par des exemples pratiques que par la théorie. Et plus par la méthode que par les technique de programmation.

Voici pour ma contribution:

- Toujours utiliser une gestion de configuration, même à un ou deux.
Les avantages sont évidents. Ne pas utiliser une gestion de configuration qui plombe le processus de développement, je pense à un certain logiciel propriétaire assez buggé, lent, contre-intruitif, et qui veut en faire trop. En bref Subversion est très bien.

- utiliser une méthodes automatisée pour générer et déployer l'application.

- plus généralement les procédures manuelles sont à proscrire.

- Ne pas laisser d'erreurs considérés comme "normales":
Tout ce qui est en gestion de configuration doit compiler (!!),
de préférence sans warning. Et quand on passe les procédures automatises (ant, make, script), cela doit se passer sans erreurs.

- Eviter les générateur de code.

- Ne pas mettre en gestion de configuration des fichiers qui sont générés.

- Commiter du code propre et indenté (penser au merge)

- Ne pas utiliser les tabulation mais des espaces à la place

- Ne pas commiter de fichier avec du code en commentaire

- Utiliser des outils réactif: rien de plus agaçant et distrayant que d'attendre devant son écran.

- définir un vocabulaire: ne pas utiliser le même mot pour des choses différentes, même si les contextes sont différents.

Voilà, et vous quelle est votre expérience du front?
  • # .

    Posté par  . Évalué à 8.

    >- Eviter les générateur de code.

    Dans la meme optique que "utiliser une méthode automatisée" je ne suis pas contre les méthodes automatisées pour generer le code quand il s'agit de code répétitif. Exemple: si j'ai 500 tables de base de données, je fais generer des classes d'acces base. Toutes les classes sont écrites de la meme manière. Ca evite des erreurs. Et ca me fait gagner *beaucoup* de temps.

    >- Ne pas utiliser les tabulation mais des espaces à la place
    De toute facon il faut se mettre d'accord sur la taille d'une tabulation en espace ...
    Perso je prefere les tabulations plutot que les espaces..
    • [^] # Re: .

      Posté par  . Évalué à 7.

      je ne comprends pas pourquoi il ne faut pas utiliser de tabulation !
      • [^] # Re: .

        Posté par  . Évalué à 1.

        En fait l'important est surtout que tout le monde utilise un éditeur reglé de la même façon pour utiliser soit les tabs, soit les espaces, afin d'éviter les faux conflits.

        Il me semble que je m'était fait pincé aussi par un collègue pour une autre raison, mais je ne me souviens plus...
        En tout cas c'est sûr, il ne faut pas! ;)
        • [^] # Re: .

          Posté par  . Évalué à 2.

          La meilleur solution consiste à configurer le repository SVN pour qu'il passe un "indent" sur chacun des fichiers commités
          • [^] # Re: .

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            La raison c'est que les tabulations ne se voient pas et qu'on peut facilement écrire une ligne indenté avec une tab et une autre avec des espaces, voire un mix. Selon les éditeurs, une tab peut faire 2, 4 ou 8 (en général) donc le code est complètement en vrac si on a pas l'éditeur qui est bien configuré pour les tabs.

            Évidemment on peut toujours dire : t'as qu'à utiliser un éditeur avec des tabs à 4 par exemple....Mais c'est un peu énervant si on a, par exemple, juste envie de "visualiser" des sources, rapidement et que le visualisateur/éditeur rapide n'a pas le bon format pour les tabs.
            • [^] # Re: .

              Posté par  (site web personnel) . Évalué à 5.

              Une indentation bien faite avec des tabulations fonctionne très bien ! C'est juste que les gens ne savent pas quand tabuler avec des espaces ou avec des tabulations.

              Règle: pour du placement absolu, utiliser des espaces, pour de placement relatif, utiliser des tabulations. Y a rien qui me gonfle plus que devoir apuyer 15 fois sur backspace, ou avoir des fichiers indentés à la barbare.
            • [^] # Re: .

              Posté par  . Évalué à 2.

              La raison c'est que les tabulations ne se voient pas


              Je m'insurge ! Avec tout bon éditeur/IDE, on peut faire apparaitre visuellement les tabulations, les espaces et les espaces en fin de ligne.

              Geany (ide gtk2) permet de configurer cela dans les préférences, et vim via les options 'set list' et 'set listchars'.
              • [^] # Re: .

                Posté par  . Évalué à 3.

                Bonne pratique de développement : utiliser un éditeur de texte pas trop moisi qui sait gérér proprement l'indentation (Emacs le fait tout seul comme un grand) ou qui sait appeler un copain qui sait faire (il doit bien être possible d'appeler indent depuis les autres éditeurs).

                BeOS le faisait il y a 20 ans !

                • [^] # Re: .

                  Posté par  . Évalué à 2.

                  emacs (en tout cas, la config par défaut sous etch) indente avec des espaces ce qui n'est pas gérer proprement l'indentation (même si le fonctionnement général est assez agréable).

                  L'indentation avec des espaces c'est une hérésie, en tout cas ce n'est pas une bonne pratique.
                  • [^] # Re: .

                    Posté par  (site web personnel) . Évalué à 2.

                    absolument pas, c'est l'indentation à geometrie variable (ben oui puisque le soit-disant argument pour des tabulations c'est que chaucun peut l'adapter selon ses preferences) via des tabulations qui est une hérésie, rien de tel pour casser un bel alignement entre des debuts de ligne et une parenthese ouvrante.
                    • [^] # Re: .

                      Posté par  . Évalué à 1.

                      rien de tel pour casser un bel alignement entre des debuts de ligne et une parenthese ouvrante.

                      Je ne vois pas de quoi tu parles.

                      L'indentation des débuts de lignes est peut-être une hérésie pour toi, ça n'en reste pas moins le standard.

                      La config par défaut de indent représente les coding styles de GNU et on voit dans la page de man :
                      -ut, --use-tabs (Use tabs. This is the default.)

                      En ce qui concerne openbsd et freebsd c'est la même chose :
                      http://www.freebsd.org/cgi/man.cgi?query=style&sektion=9
                      http://www.openbsd.org/cgi-bin/man.cgi?query=style

                      Indentation is an 8 character tab. Second level indents are four spaces.
                      • [^] # Re: .

                        Posté par  (site web personnel) . Évalué à 2.

                        ce que je veux dire c'est qu'un code du genre:
                        if(toto && truc_vachement_long &&
                           tutu && encore_un_truc) {
                          plop();
                          coin();
                          prout();
                        }


                        n'est pas possible à faire avec des tabs, puisqu'il y a trois espaces devant tutu (pour qu'il soit joliement aligné avec toto)


                        > Indentation is an 8 character tab. Second level indents are four spaces.

                        je comprends pas. Ils recommandent de mélanger espaces et tabs ? Je trouve que c'est le pire du pire
                        • [^] # Re: .

                          Posté par  . Évalué à 1.

                          Ce qu'ils appellent "second level indents" c'est typiquement (enfin de ce que j'en comprends) ta ligne qui commence par tutu.

                          Ton code s'indente donc comme ça :

                          if(toto && truc_vachement_long &&
                              tutu && encore_un_truc) {
                                  plop();
                                  coin();
                                  prout();
                          }

                          Je trouve ça plus clair d'ailleurs, je trouve maladroit que tes instructions soient décalées sur la gauche par rapport à la 2ème ligne de ton if.
                          • [^] # Re: .

                            Posté par  . Évalué à 2.

                            dans ce cas moi je mets des tabs juste après le if

                            if (\t toto && truc &&
                            \t \t tutu && titi ){
                            }


                            comme ça mes conditions du if sont alignées, idem pour l'appel d'une fonction avec 50 paramètres


                            ma_fonction( \t toto,
                            \t \t \t \t titi );
                        • [^] # Re: .

                          Posté par  (site web personnel) . Évalué à 2.

                          -Ne pas couper une ligne uniquement parce qu'elle est trop longue, c'est le boulot de l'éditeur de texte. Tout le monde n'a pas la même résolution/n'est pas en console graphique pour éditer. En plus, ça évite aux gens prores(qui donc utilisent des tabs) de devoir mettre des espaces.
                          • [^] # Re: Problèmes d'indentation

                            Posté par  . Évalué à 1.

                            C'est le genre de problèmes qu'on a pas quand on fait du smalltalk. Avec un IDE bien fait, plus besoin de se soucier de l'indentation : elle est gérée automatiquement et de la même façon chez tout le monde.

                            Pour moi la meilleure solution présentée jusqu'à présent est celle de faire tourner indent par SVN sur chaque commit. On définit le standard pour le projet, et SVN se charge de le faire respecter. C'est la solution idéale.
      • [^] # Re: tabulations

        Posté par  . Évalué à 2.

        Oui, en faite, cette recommandation n'est pas à sa place pour deux raisons:

        - L'idée derrière est qu'il faut imposer un certain nombre de règles de codage, cela ne se limite pas à l'indentation.

        - La règle est discutable. D'après Linus par exemple, le code doit être indenté avec des tabulations, si vous ne pouvez pas voir correctement votre code dans un éditeur tout bête (ceux qui place les tabulations tous les 8 caractères), c'est que votre code est mal fichu et que vous ne maitrisez pas le découpage fonctionnel du code.

        Au boulot, les normes de développement impose la tabulation; ainsi que pratiquement une centaines d'autres règles de bonne conduite (pas de catch d'exception vide, un seul return par fonction, pas de membre d'objet qui soit publique...)
        • [^] # Re: tabulations

          Posté par  . Évalué à 6.

          pas de catch d'exception vide
          Ca me parait évident, mais c'est bon de le rappeler.

          un seul return par fonction,
          Ca par contre je trouve ça débile: ca augmente inutilement la complexité cyclomatique du code, et donc diminue la lisibilité

          J'aime bien avoir des tests de gardes au début de mes méthodes pour éliminer les cas spéciaux ou triviaux, et retourner au plus vite, et ensuitre avoir le code du cas général.

          Le même code écrit avec un seul return contient plus de niveau d'intentation, et est plus long: pour moi c'est moins bon.
          • [^] # Re: tabulations

            Posté par  (site web personnel) . Évalué à 6.

            > Ca par contre je trouve ça débile: ca augmente inutilement la complexité cyclomatique du code, et donc diminue la lisibilité

            bah c'est pas compliqué, suffit de faire des goto vers le return unique!

            void toto() {
              blahblah;
              if (truc) goto cassos:
              burp;
              if (machin) goto cassos;
              blop;
            cassos:
              return;
            }
            • [^] # Re: tabulations

              Posté par  (site web personnel) . Évalué à 1.

              A choisir, il vaut mieux faire comme ceci :
              PMString MaClass::MaFonc() {
                  PMString retval = "";
              
                  do {
                      if(mon test pas glop) {
                          break;
                      }
                      
                      [...]
                      
                  } while(kFalse);
              
                  return retval;
              }
              
              C'est des structures de ce type qui sont utilisées entre autre dans InDesign CS2 de Adobe (c'est l'un des rares endroit où j'en ai rencontré en tout cas)
          • [^] # Re: tabulations

            Posté par  . Évalué à 4.

            Ca dépends, normalement les cas anormaux sont éliminés par un lancer de trolld'exception.
            Pour le reste, oui, ça oblige a faire quelque chose comme
            
            fonction f(...) {
            	entier resultat
            	si( situation1 ) {
            		resultat = 1
            	} sinon si( situation2 ) {
            		resultat = calcul compliqué
            	}
            	retourne resultat
            }
            
            Dans plusieurs cas, on trouve des solutions plus claires; mais le but est surtout d'éviter du code effroyable avec des sorties de boucle, des variables pas trop bien initialisées...
            Plusieurs des règles que l'on peut imposer résultent d'un compromis. Comme tu l'as visiblement bien compris en rédigeant ce journal, on a besoin de bonnes pratiques, et lorsqu'on est une entreprise, on essaye de les imposer aux fournisseurs. Les bonnes pratiques sont rarement universelles; mais dans l'ensemble, on essaye de les choisir afin d'avoir le code le moins buggé et le plus maintenable possible.
            En général, le jeune développeur qui débarque est complètement focalisé sur les performances; ensuite il y a un long travail pour lui faire comprendre que ce que l'on veut, c'est un code clair, simple et non buggé. S'il faut mettre un second serveur à coté à cause des performances, ça coûte toujours moins cher que coller trois hommes.mois pour résoudre les problèmes.
            
  • # vocabulaire

    Posté par  (site web personnel) . Évalué à 3.

    Juste pour être sûr de bien comprendre ce que tu veux dire, ne faut-il pas plutôt lire "gestionnaire de versions" plutôt que "gestion de configuration" ?

    J'ajouterais dans les bonnes pratiques:
    - faire des tests (unitaires, fonctionnels)
    - écrire de la doc
    • [^] # Re: vocabulaire

      Posté par  (site web personnel) . Évalué à 7.

      et pour être sympa avec les copains qui repasse dérrière :
      - ne pas coder comme un porc
      - non, une fonction de 1000 lignes, ce n'est pas de l'optimisation.

      (ceux qui code des fonctions de mille lignes, on devrait les pendre par les couilles ou non pire : les obliger de maintenir leur code à vie)

      "La première sécurité est la liberté"

      • [^] # Re: vocabulaire

        Posté par  . Évalué à 3.

        Ben si, c'est de l'inlining!! ;)

        Oui je suis bien d'accord!

        Ca va souvent de paire avec la programmation par copier/coller qui est une hérésie quand on utilise un langage objet (avec un autre langage aussi d'ailleurs)
      • [^] # Re: vocabulaire

        Posté par  (site web personnel) . Évalué à 4.

        si on pend par les couilles ceux qui font des fonctions de 1000 lignes, que doit-on faire de ceux qui écrivent des fonctions de 4-5000 lignes plusieurs fois dans un fichier > 30 000 lignes le tout en utilisant un langage objet et les fonctions ayant plus de 10 paramètres ?
        (vrai question, j'ai rencontré ça professionnellement et c'est pas évident... a oui, j'ai oublié, comment on fait quand c'est le chef qui code comme ça le tout sans mettre de commentaire ?)

        Sinon, pour moi le mini vital c'est :
        - svn (ou autre, faut pas être sectaire ;-) )
        - bugtracker (j'aime particulièrement trac qui s'interface bien avec svn)
        - des commentaires dans le code (objet, fonctions, ...) : utilisation de doxygen, javadoc, etc. C'est à mon avis le mieux car c'est très facile a écrire et à maintenir en même temps que le code *
        - point très important, et souvent plus complexe que les problèmes techniques : se mettre d'accord dans l'équipe sur des conventions de codage : code en anglais, position des accolades (enfin c'est forcément à la fin de la ligne donc il n'y a pas a discuter ;-) ), ...

        Sinon, j'irai plus loin sur le traitement des erreurs.
        Tant que c'est possible (langage, lib externes, ...) toujours avoir - au moins en debug - le niveau de warning le plus élevé possible tout en rajoutant le traitement des warning comme des erreurs. Le résultat est que le programme ne compilera / se lancera jamais tant qu'il y a le moindre warning. C'est un peu contraignant mais ça oblige à lire les warnings et force a écrire du code correcte. Il n'y a rien de plus gonflant que de vouloir compiler un soft et d'être automatiquement noyé sous les warnings idiots.

        (*) : Dans certains cas, on peut faire passer en tant que warning le fait qu'il manque un commentaire (sur un membre le nécessitant, membre public, ...). Associé au traitement des avertissements comme des erreurs, l'effet est immédiat : les commentaires apparaissent.
        • [^] # Re: vocabulaire

          Posté par  . Évalué à 3.

          Sinon, pour moi le mini vital c'est :
          - svn (ou autre, faut pas être sectaire ;-) )

          Moi je suis sectaire, et je dis mort a SourceSafe. Les autres je gere, mais celui-la, non, vraiment, je peux pas.
          • [^] # Re: vocabulaire

            Posté par  (site web personnel) . Évalué à 4.

            c'est pas être sectaire ça ;)
            Toute personne ayant déjà utilisé sourcesafe sait que ce n'est pas un vrai gestionnaire de source mais simplement une blague que les personnes de crosoft on voulu faire mais que des idiots on décidé de prendre au sérieux...

            (oui, 1 an de sourcesafe ça marque, j'avais fini par écrire un soft en ruby permettant de migrer sourcesafe vers svn mais j'ai quitté la boite avant de le finir totalement ;-) )
        • [^] # Re: vocabulaire

          Posté par  . Évalué à 2.

          si on pend par les couilles ceux qui font des fonctions de 1000 lignes, que doit-on faire de ceux qui écrivent des fonctions de 4-5000 lignes plusieurs fois dans un fichier > 30 000 lignes le tout en utilisant un langage objet et les fonctions ayant plus de 10 paramètres ?


          Mais mais mais .. on a bossé dans la même boite ??
          • [^] # Re: vocabulaire

            Posté par  . Évalué à 2.

            On est tant que ca a etre passés par Sharp ?
            • [^] # Re: vocabulaire

              Posté par  (site web personnel) . Évalué à 2.

              non, et c'est ça le pire... c'est qu'il y en a plusieurs des boites comme ça...

              Moi qui coryait être passé dans une exception ;-)

              Le mieux ça a été leur tête quand j'ai demandé, lors de mon 2° jour dans cette boite, s'il y avait des conventions de codage et si oui lesquelles. J'ai compris un peu plus tard, quand j'ai vu leur code...
              Ils ont du me prendre pour un fou ! ;-)
              • [^] # Re: vocabulaire

                Posté par  . Évalué à 3.

                Ouais pareil et ce n'est pas Sharp :
                - pas de convention de codage
                - des fonctions qui font facilement plusieurs milliers de lignes
                - des prototypes de fonctions avec plusieurs dizaines de variables
                - pas de typage fort
                - pas d'indentation défini
                - le nommage des variables dans le genre x, y, z ou toto, tata
                - réutilisation des variables pour faire passer d'autres infos .. d'autres types
                - ..

                En fait c'est super formateur parceque c'est tout à fait à l'opposé de l'ensemble des bonnes pratiques :) Comme ça tu vois en vrai pourquoi il ne faut pas faire ça.
    • [^] # Re: vocabulaire

      Posté par  . Évalué à 2.

      Oui "gestionnaire de version", ça me va aussi.

      Pour les tests, ça me parait évident, bien que les test unitaires n'ont pas l'air d'être évidents pour tout le monde.

      De la même manière utiliser un outils de suivi de bug me semble tellement indispensable que je m'aperçoit que je ne l'ai même pas mentionné.

      Pour la doc, c'est important, mais il faut éviter de faire de la doc pour faire de la doc.
      Moins il y en a et mieux c'est (il faut la maintenir à jour), mais il y a un minimum à fournir
      .
      Pour la forme, le wiki c'est pas mal (mieux qu'un tas de fichiers bien enfouis sur un lecteur partagé en tout cas)
      Mais c'est pas optimal non plus, au bout d'un moment, les gens oublient de mettre à jour le wiki, et de plus les non-informaticiens ne sont pas toujours à l'aise avec.
      • [^] # Re: vocabulaire

        Posté par  . Évalué à 2.

        Pour la doc, c'est important, mais il faut éviter de faire de la doc pour faire de la doc.
        Moins il y en a et mieux c'est (il faut la maintenir à jour), mais il y a un minimum à fournir

        /me se rappelle avec nostalgie d'une de ses précédentes boites (penser télécom et Suede) ou il a passé 3 mois a écrire de la doc pour un wrapper entre 2 API qui a été codé et testé en une demi-journée.
        J'ai démissioné au bout de 5 mois. Bon, j'avoue que c'est aussi parce que j'avais dans les mains une offre que je ne pouais pas refuser, mais j'étais soulagé de partir...
        • [^] # Re: vocabulaire

          Posté par  . Évalué à 2.

          Par contre personnellement je dirais qu'il faut SPECIFIER le code que l'on écrit (schéma ou texte, peu importe), de telle façon que n'importe qui puisse intégrer le projet sans passetr trop de temps à lire des sources pour savoir comment ca marche.
    • [^] # Re: vocabulaire

      Posté par  (site web personnel) . Évalué à 0.

      Juste pour être sûr de bien comprendre ce que tu veux dire, ne faut-il pas plutôt lire "gestionnaire de versions" plutôt que "gestion de configuration" ?


      Un outil de gestion de version est un outil qui permet de faire de la gestion de configuration :)
  • # Alors, il faut générer ou pas ?

    Posté par  . Évalué à 4.


    - Eviter les générateur de code.

    En ce qui me concerne, je remplacerais celle là par :
    - Générer le code chaque fois que c'est possible.
    pour moi, utiliser un générateur de code, c'est du même ordre d'idée que d'utiliser une bibliothèque externe.
    Ne pas oublier non plus que les compilateurs sont des générateurs de code !!!


    - Ne pas mettre en gestion de configuration des fichiers qui sont générés.

    Alors, on les génère ou pas ?
    • [^] # Re: Alors, il faut générer ou pas ?

      Posté par  . Évalué à 2.

      Ne pas oublier non plus que les compilateurs sont des générateurs de code !!!
      +1

      Alors, on les génère ou pas ?
      J'ai dis "éviter", pas interdire ;)

      En fait je me pose pas mal de question la dessus.

      A mon avis, si le langage permet de réutiliser le code, ou d'écrire du code générique pour le problème rencontré, il faut privilégier cette voix

      En tout cas la génération de code pose problème pour les fichier qu'on doit retoucher ensuite:
      - écrasement des modifs par la génération suivante
      - les dév on peur de toucher le code généré
      - générateur pas à jour -> procédure manuelle pour palier le problème.
      Car bien souvent un générateur est complexe, et personne ne veux/peux le maintenir si la personne qui l'a mis en place n'est plus là.

      Plus généralement je me pose aussi la question de l'utilisation des outils de "programmation visuelle".
      J'ai plutôt tendance à avoir confiance dans une approche entièrement textuelle: le code fais foi,
      mais j'arrive pas trop à me justifier la dessus.
      • [^] # Re: Alors, il faut générer ou pas ?

        Posté par  . Évalué à 1.

        s/voix/voie
      • [^] # Re: Alors, il faut générer ou pas ?

        Posté par  . Évalué à 5.


        En tout cas la génération de code pose problème pour les fichier qu'on doit retoucher ensuite:

        il ne faut *JAMAIS* modifier à la main du code généré


        - les dév on peur de toucher le code généré

        ils ont bien raison.


        - générateur pas à jour -> procédure manuelle pour palier le problème.
        Car bien souvent un générateur est complexe, et personne ne veux/peux le maintenir si la personne qui l'a mis en place n'est plus là.


        Deux cas :
        1) le générateur viens de l'extérieur :
        Avant de se décider à l'utiliser, s'assurer qu'il existera toujours (vive le logiciel libre !!!) et s'assurer qu'il est suffisemment bien construit pour avoir une gestion fine du code généré.

        2) le générateur est écris en interne :
        Il faut le gérer comme le reste du code qui peut être complexe aussi !!!
  • # Vocabulaire

    Posté par  . Évalué à 1.

    Bonjour,

    je ne suis pas développeur, et donc je suis gêné par le mot commiter. Je comprends le besoin d'adapter l'anglais "to commit", mais ne faudrait-il pas trouver un mot français qui va bien plutôt que ce franglais ?
    • [^] # Re: Vocabulaire

      Posté par  . Évalué à 3.

      Soumettre ?

      J'admets que c'est pas parfait, mais ça pourrait convenir....
    • [^] # Re: Vocabulaire

      Posté par  . Évalué à 6.

      Tout le monde comprends 'commiter', alors qu'une francisation ridicule ça donne ça:

      Guilbert: "C'est bon, j'ai soumis mes changements."
      Raymond: "Hein ?! T'as fait quoi ??"
      Guilbert: "J'ai commité."
      Raymond: "Ah ok."

      Conclusion, ça fait perdre du temps à Guilbert et Raymond.
    • [^] # Re: Vocabulaire

      Posté par  . Évalué à 3.

      Commettre?

      D'accord je sors!
      Quoique parfois on peux se demander ;)

      Cela dit, l'"outils linguistique" de google donne cette traduction, mais bon c'est pas forcément une référence

      A mon avis le sens est plutôt confier (au système de gestion de versions)
    • [^] # Re: Vocabulaire

      Posté par  (site web personnel) . Évalué à 3.

      Si sur le principe je suis d'accord, dans ce cas précis je suis contre utiliser le français.
      La première raison (mais la moins importante) et que le jour ou j'ai utilisé un logiciel de gestion de source en français (c'était simplement une version de tortoise svn en français) j'ai rien compris du tout, les mots ne voulaient rien dire du tout pour moi (car j'avais déjà mis une connotation sur les mots anglais).
      La deuxième raison est que presque tous les logiciels de gestion de source comportent les commandes en anglais (cvs/svn commit, checkout, ...) et donc si on apprend pas les termes anglais le jour où il faut utiliser un tel logiciel en ligne de commande on ne peut/sait pas...
      • [^] # Re: Vocabulaire

        Posté par  . Évalué à -5.

        d'un autre cote, faut etre un peu SM pour utiliser CVS en ligne de commande...
        • [^] # Re: Vocabulaire

          Posté par  (site web personnel) . Évalué à 2.

          pourquoi ?
          C'est une vrai question, il m'arrive régulièrement d'utiliser mon svn en ligne de commande sans aucun soucis.
          Je trouve justement cette utilisation parfois plus pratique et plus rapide que par les gui classiques (j'utilise depuis quelques jours kdesvn et ça marche quand même pas trop mal)
          Surtout que le jeu de commande de base est très succint et au moins on est certain de savoir ce que l'ont fait
          • [^] # Re: Vocabulaire

            Posté par  . Évalué à 2.

            Premier point, lié a la ligne de commande : c'est conceptuellement particulierement inadapte pour gerer des fichiers (hors cas tres simples, avec une dizaines de fichiers dans un seul repertoire par ex). Les fichiers sont en effet dans un arbre et on fait bien mieux que de l'ascii art pour representer un arbre, tout de meme ;-)
            Bon apres, j'suis dev java, un repertoire par package, t'imagines vite le bordel a se fader des cd com/maboite/monprojet/package/souspackage, cd ../../../../../ etc.
            M'enfin, l'idee est la quoi.

            Sinon, syntaxe aride, commandes cryptiques, enchainement particulierement relou de commandes (pour supprimer un repertoire et son contenu, par ex), page man longue comme ma teub (i.e. : gros, tres gros ^_^) etc.
            Lever un conflit de commit en ligne de commande, ben voila quoi.

            Rien que pour supprimer un fichier : rm fichier cvs delete fichier, cvs commit, ca fait une operation de trop ('fin a mon gout, hein).

            Un client CVS graphique decent t'affichera directement un diff graphique avec toute les facilites pour naviguer (perso, j'utilise enormement la perspective CVS/Team synchronise d'eclipse, ben quand meme ca simplifie la vie)

            En tout cas dans une utilisation pro, CVS en ligne de commande me parait totalement inutilisable.
            Techniquement, je l'ai fait, sur un petit projet ou j'avais une partie du boulot a faire en ssh sur une machine distante, avec 4-5 fichiers max a manipuler, c'etait deja penible, j'ose pas imaginer quand je commit mes 15 classes (en fait, dans ce cas la, j'aurais rappatrié les sources sur mon poste local et j'aurais commite dans mon eclipse).

            Tres recemment, j'ai du me fader l'historique de mes commits pour retrouver un jar bien particulier : selection de la vue "historique", dnd du fichier dans la vue, ya plus qu'a click droit sur chaque revision, get Contents, double click et paf, j'ai ce qu'il me faut sous la main, le tout avec la date du commit, le ocmmentaire, le numero de verison etc sous les yeux et bien organise.
            Va naviguer parmi les tags/branches etc dans un client ligne de commande.
            Va checkouter une version anterieure a une certaine date en ligne de commande, entre un calendrier graphique et la saisie de la date manuellement ya pas photo, mon choix est vite fait.

            Apres, si c'est juste pour faire un checkout d'un projet sur 'ternet, ./configure && make, c'est sur que c'est plus rapide que de sortir un gros client graphique.

            Je connais pas du tout SVN, mais il m'a l'air tout a fait calqué sur CVS niveau utilisation.
            • [^] # Re: Vocabulaire

              Posté par  (site web personnel) . Évalué à 3.

              En fait, dans ce cas précis ce qui est chiant c'est cvs surtout.
              Pour ma part, avec svn, c'est quand même plus simple (rien que du fait qu'il gère le repository et non simplement des fichiers)
              Si je ne me trompe pas en svn pour supprimer il suffit de faire svn rm fichier && svn commit

              Sinon, pour la gestion des rep, il suffit aussi de se def une variable correspondant à ton projet :-)

              Attention, je ne dis pas qu'un client graphique est inutile, pour moi le meilleur client c'est simplement celui qui est intégré dans l'ide (dans la liste des fichiers). Mais je réagit surtout au fait qu'il faudrait être SM pour utiliser en cli.

              Pour ce qui est des opérations de base (je sais pas vous, mais sur un projet "classique" je touche pas les branches toutes les 5 min et il "suffit" de tagger car ça ça se fait très rapidement, y compris le swap sur la tête) la ligne de commande peut suffire et est tout a fait utilisable.
              • [^] # Re: Vocabulaire

                Posté par  . Évalué à 1.

                Sinon, pour la gestion des rep, il suffit aussi de se def une variable correspondant à ton projet :-)
                pffouuu..
                ca fait chier. mon boulot c'est pas de me compliquer la vie alors que c'est le boulot d'une machine de gerer la presentation des infos.
                D'autre part, je crois qu'on s'est mal compris, je parlais de naviguer dans une arborescence en ligne de commande : c'est pas pratique de naviguer dans un arbre avec une ligne de commande. Parce que tu n'as pas de vision globale.

                je sais pas vous, mais sur un projet "classique" je touche pas les branches toutes les 5 min et il "suffit" de tagger car ça ça se fait très rapidement, y compris le swap sur la tête
                ben chais pas, a chaque commit j'impacte bien 5 a 10 fichiers.
                Et commiter sans verifier le diff pour chaque fichier, tres peu pour moi.

                Bref le probleme vient plus d'une mauvaise presentation des infos du CVS (impossible de faire un diff lisible etc.) que du concept ligne de commande.

                tout a fait d'accord avec toi par contre concernant l'integration a l'ide.
            • [^] # Re: Vocabulaire

              Posté par  (site web personnel) . Évalué à 1.

              Bon apres, j'suis dev java, un repertoire par package, t'imagines vite le bordel a se fader des cd com/maboite/monprojet/package/souspackage, cd ../../../../../ etc.


              Après c'est une question d'habitude. Moi aussi je développe en java. Mes outils : xterm + emacs et Netbeans de temps en temps. Maven pour la compilation. J'ai déjà utilisé le plugin SVN de Netbeans. Bien sûr ça marche bien mais je trouve que je ne gagne rien par rapport à la ligne de commande, plus rapide et plus pratique à mon goût.

              Par contre sous windows, j'ai été très impressionné par TurtoiseSVN.
            • [^] # Re: Vocabulaire

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              >Je connais pas du tout SVN, mais il m'a l'air tout a fait calqué sur CVS niveau utilisation.


              Ben interresse toi à SVN ! Car même si il reprend en (tres) gros les commandes, SVN a été grandement simplifié (c'était le but du projet d'ailleurs, qui, je le rappelle a été fondé par des anciens dev de feu CVS)

              Avec CVS, moi aussi les commandes me rebutaient. Plein de switches et paramètres dans tout les sens. Obligé d'utiliser un outil graphique sinon ça m'énervait trop.

              Quand je suis passé à subversion, les commandes sont tellement simples que je n'ai depuis jamais réutilisé d'outils graphique. Le tutoriel aussi est très bien fait, ce qui a certainement influencé mon appréciation. ( http://svnbook.red-bean.com/ )

              Franchement, passe à SVN... C'est que du bonheur quand on a connu CVS.
              • [^] # Re: Vocabulaire

                Posté par  . Évalué à 1.

                je ne decide pas du gestionnaire de version utilise...
      • [^] # Re: Vocabulaire

        Posté par  . Évalué à 4.

        Je suis bien d'accord.
        En ce moment je suis contraint à utiliser wasd, qui n'est autre qu'un Eclipse customisé.

        Tout a été francisé, ça m'a fait perdre pas mal de temps à chercher dans les menus et les préférences. Ah oui, parce qu'il ont modifié les raccourcis clavier aussi...

        Sans parler de la débilité de certaines traductions:
        par exemple le "go into" traduit par "suivant", qui ne veut rien dire,
        ou bien "propager les modification" pour "refactor"...
      • [^] # Re: Vocabulaire

        Posté par  . Évalué à 2.

        Oui je suis d'accord aussi sur le fond avec toi. Je faisais simplement le remarque parcequ'il m'avait semblé qu'on n'était justement pas obligé d'utiliser l'anglais pour ce cas précis. J'avais sans doute tort. J'insiste cependant sur un point : ok pour utiliser le jargon anglais, mais certainement pas pour le conjuguer à la française... "commiter", c'est très laid... ;-)
        • [^] # Re: Vocabulaire

          Posté par  . Évalué à 1.

          D'autant plus que dans ce cas, on peut simplement dire "faire un commit" (valider ? envoyer ?), "faire un checkout" (récupérer une copie ?), "poser un tag", "créer une branche", et tout simplement "fusionner".

          Non ?
    • [^] # Re: Vocabulaire

      Posté par  (site web personnel) . Évalué à 2.

      Valider ?
      Valider la transaction ?
      Valider les modifications ?
    • [^] # Re: Vocabulaire

      Posté par  . Évalué à 2.

      Le terme usuel pour le commit ou check-in est "remise".
      On dit remettre un fichier comme on parle de l'extraire pour modification
      (check-out)
  • # Impressionnant

    Posté par  . Évalué à 6.

    tout ce qu'on ne fait pas ici...
  • # Et les tests, vous oubliez les test !

    Posté par  . Évalué à 2.

    - Faire des tests unitaires (Si pas de JUnit ou de liib dédié aux tests unitaires, un ensemble de main() permettant de lancer "en ligne de commande" les grandes fonctionnalités tordues du logiciel.

    - Une procédure d'installation documentée et automatisée du poste de développement. Utiliser la même version de l'IDE, du compilo etc, pour faire en sorte que ré-installer un poste de dev et compiler la dernière version ne prenne pas plus d'une heure.

    - Un gestionnaire de LOG parametrable.
    • [^] # Re: Et les tests, vous oubliez les test !

      Posté par  . Évalué à 2.

      Les test unitaire, ça me parait indispensable, mais c'est étonnamment peu répandu. Ils y en a même pour prétendre que c'est une perte de temps

      Par contre ce qui est un vrai problème c'est d'écrire des test unitaires pour de l'existant qui n'en comporte pas: c'est quasi impossible, car le code n'est en général pas écrit de manière à être testable, et il est impossible de le modifier sans casser ce qui marche (car en fait on ne sait pas ce qui marche ou pas!!)
      • [^] # Re: Et les tests, vous oubliez les test !

        Posté par  (site web personnel) . Évalué à 2.

        Tu soulèves effectivement un point assez intéressant, la nom modularité du code existant. Ce qui fait que l'utilisation de tests unitaire est fort difficile.

        Par contre, une approche tout aussi intéressante est le refactoring. Bien que couteux en temps, il s'avère fort intéressant à long terme.

        L'intérêt du refactoring, est le nettoyage de code pour garder un code à jour.

        Lire les articles de JoelOnSoftware et de Martin Fowler sont très instructif.
  • # À lire

    Posté par  (site web personnel) . Évalué à 2.

    Un bouquin à ce sujet qui est classé dans mes 5 ouvrages favoris:

    http://www.amazon.fr/Pragmatic-Programmer-Journeyman-Master/(...)

    À lire, plusieurs fois.
  • # Quand je programmais...

    Posté par  . Évalué à 2.

    ... c'est à dire il y a bien longtemps, ma conscience avait assimilé ces quelques préceptes...

    http://www.canonical.org/~kragen/tao-of-programming.html
  • # Mon expérience actuelle

    Posté par  (site web personnel) . Évalué à 2.

    Travail en équipe réduite: moi :-)
    Mon premier vrai dev provessionnel sous linux. C'est du C.

    Avec tous les préceptes que j'ai découvert sur linuxfr et la communauté GNOME, je me suis mis à appliquer tout ceci:

    * gestionnaire de versions : subversion
    * bugtracking: trac (je m'en sers pour le wiki et le suivi des changesets subversion)
    * génération: autotools (make check et make distcheck rulez)
    * doc: doxygen
    * tests unitaires: http://check.sourceforge.net

    Quand je pense que je codais en MFC il y a 3 ans :-p

    La règle primordiale quand tu codes: penses à ce que tu laisses à celui qui passe derrière toi ! Bien des fois, ce sera toi, 3 mois plus tard, et ça t'aidera bien à recomprendre ce que tu avais fait à l'époque.

    Pour certaines de tes remarques, voici mon avis personnel:
    Ne pas utiliser les tabulation mais des espaces à la place

    Question de goût, quand tu sais utiliser les tabulations, tout devient plus facile. Des fois, j'ai l'impression que les paresseux ne cherchent pas à comprendre et utilisent les espaces systématiquement. Oui, ça fait gros con de dire ça.

    Ne pas commiter de fichier avec du code en commentaire

    Moyennement d'accord. C'est ce que je faisais et j'en ai eu marre de refaire 15 fois la même chose (que j'avais fait, puis effacé). Alors je mets du #if 0 pour marquer les bouts de code mort, et s'ils restent morts assez longtemps, je les vire. un grep permet tout de suite de les localiser, ce que tu ne peux pas faire avec un commentaire.
    • [^] # Re: Mon expérience actuelle

      Posté par  . Évalué à 2.

      Alors je mets du #if 0 pour marquer les bouts de code mort, et s'ils restent morts assez longtemps, je les vire. un grep permet tout de suite de les localiser, ce que tu ne peux pas faire avec un commentaire.

      Tu n'as jamais pensé à /* Dead code, might be resurrected soon ou un truc du genre ?
      • [^] # Re: Mon expérience actuelle

        Posté par  (site web personnel) . Évalué à 2.

        bah en général je mets du #if 0 que pour ça. Quand c'est pour une désactivation temporaire, c'est plutôt du :

        #define MABIDOUILLE TRUE
        ...
        #if MABIDOUILLE

        mais il est vrai qu'un #if DEAD_BUT_NOT_QUITE , ça le fait aussi ;-)
        • [^] # Re: Mon expérience actuelle

          Posté par  (site web personnel) . Évalué à 3.

          On peut aussi utiliser les fameux FIXME et TODO très utiles, et facilement visibles à coup de grep (à faire suivre d'une petite explication quand même, hein)
          • [^] # Re: Mon expérience actuelle

            Posté par  . Évalué à 3.

            C'était le but de ma question : faire remarquer qu'une explication (introduite par un texte fixe et lui-même explicatif) valait mieux et était tout aussi grépable qu'un tout moche #if 0 ;oP
            • [^] # Re: Mon expérience actuelle

              Posté par  . Évalué à 3.

              Moi je trouve le #if 0 très pratique.

              Pour la simple raison que si le code mort contient des commentaire le compilateur ne risque pas d'être perturbé et surtout le programmeur n'a pas à se prendre la tête.

              Bien sur la mise en commentaire de code source est pour moi à utiliser avec modération. Mais est quand même très utile dans le cas d'un débugage par exemple. Mais aller de là à commiter du code mort ça me semble limite, généralement (attention j'ai bien dis généralement) quand on commit, ça que ça marche.... :-)
          • [^] # Re: Mon expérience actuelle

            Posté par  . Évalué à -1.

            question, je vous vois tous parler de grep etc.

            zavez jamais pense a utiliser un vrai ide, du genre qui vous permet de faire une recherche dans tous les fichiers du projet, plutot que de jongler avec 4 applis en permanence?
  • # Ne pas péter plus haut que son cul

    Posté par  (site web personnel) . Évalué à 3.

    _ Re-utiliser au maximum du code existant et éprouvé
    _ Avancer petit à petit et valider au fur et à mesure
    _ Faire des libs
    _ Faire des tests
  • # Serveur de build de nuit

    Posté par  . Évalué à 2.

    Sur le blog www.joelonsoftware.com (je n'arrive pas à retrouver l'url exacte). Le monsieur conseillait d'utiliser une serveur effectuant un build chaque nuit.

    En gros une tache cron qui checkout la dernière version du soft et la compile (d'où l'utilité de tout pouvoir compiler à l'aide d'un make).

    Est - ce qu'il y en a parmis vous qui ont éprouvé cette solution, est - ce vraiment utile ?
    • [^] # Re: Serveur de build de nuit

      Posté par  (site web personnel) . Évalué à 1.

      Je build quand je veux tester (je vais pas attendre la nuit pour tester ;))
      Mais si c'est un gros soft tu ne fais que des tests unitaire, et le build nocturne permet de rassembler le tout.

      Tout dépend de la taille de ton projet
    • [^] # Re: Serveur de build de nuit

      Posté par  . Évalué à 2.

      A mon avis, le build automatique après le commit est plus intéressant.
      Ca permet d'avoir un retour rapide pour le développeur sur ce qu'il vient de commiter (oui encore cet anglicisme ;) et ces eventuels oublis.

      Par exemple sur un projet on utilisait CruiseControl, qui compilait et executait les test unitaire après chaque commit, et envoyait un rapport aux developpeurs, c'est super utile, mais ça demande un peu d'éducation: j'ai vu des développeur filtrer les mail de rapports directement à la poubelle...

      Et aussi, faire passer les test unitaire doit être une priorité
      • [^] # Re: Serveur de build de nuit

        Posté par  (site web personnel) . Évalué à 2.

        J'utilise Builbot pour cela et cela m'a souvent aidé. Avec suffisamment de client, on peut tester différentes plateformes et configuration très facilement.

        L'idéal c'est de lancer les tests unitaires à chaque commit et des tests plus poussés toutes les nuits.
    • [^] # Re: Serveur de build de nuit

      Posté par  (site web personnel) . Évalué à 1.

    • [^] # Re: Serveur de build de nuit

      Posté par  (site web personnel) . Évalué à 1.

      Avec les builds automatique, tu peux faire bcp de choses.

      Générer la documentation de ton code
      Compiler ton code
      Réaliser les tests unitaires
      Vérifier le rapport de tes tests unitaires
      Packager tes binaires pour l'équipe de qualification qui doit vérifier ton code, avec un listing des améliorations et des bugs supplémentaires.

      Y a plein de choses que l'on peut faire.
    • [^] # Re: Serveur de build de nuit

      Posté par  . Évalué à 3.

      Ca se fait chez MS sur tous les gros produits dont Windows.

      C'est extremement utile sur les gros projets car ca permet de tirer avantage du temps ou les gens dorment(la nuit) pour effectuer des etapes essentielles mais couteuses en temps (build qui peut prendre bcp de temps, tests unitaires qui peuvent prendre du temps aussi, ...)

      Le desavantage c'est quand tu recois un coup de fil a 8h du soir d'un gars qui t'annonce que ton commit a casse le build et que tu ne feras rien d'autre avant que ce soit corrige...
  • # Parler anglais

    Posté par  . Évalué à 3.

    Mieux vaut toujours garder l'anglais comme langue pour nommer les variables, les fonctions...
    - Quand on fait du code libre, c'est bien de pouvoir le diffuser au monde et pas seulement aux francophones.
    - En anglais, y'a pas d'accents, et les accents dans les noms de variable, ça suxxx.
    - Ca fait réviser l'anglais.

    Et puis pas mélanger les langues. Je me souviens d'un projet de fac où j'ai fait tout une partie en angliche, et les autres tous en franchiche. Et bah c'était pas joli joli.
    • [^] # Re: Parler anglais

      Posté par  . Évalué à 3.

      Mieux vaut toujours garder l'anglais comme langue pour nommer les variables, les fonctions...

      Oui sauf qu'en France les spec sont souvent écrites en Français, et les gens parlent entre eux en Français.
      Traduire en anglais introduit une ambiguïté, et en plus en France on est pas très fort en anglais, et je t'assure que ça pose problème, entre ceux qui comprenne rien, et ceux qui introduise des traduction toute pourrie.


      - Quand on fait du code libre, c'est bien de pouvoir le diffuser au monde et pas seulement aux francophones.

      Tout à fait d'accord, et là je trouve que ça se justifie pleinement d'investir dans une conception en anglais. AMA il faut a tout pris éviter de concevoir en français pour traduire ensuite, il faut tout faire en anglais, dès la conception fonctionnelle.

      - En anglais, y'a pas d'accents, et les accents dans les noms de variable, ça suxxx.
      Les langages qui ne gère pas les accents, ça suxxx.
      Bon, dans la réalité je n'utilise pas les accents dans le code, mais avec un langage moderne (Python, Java) ça ne pose aucun problème. D'ailleurs c'est un indice pour la gestion de l'internationalisation. Par exemple Ruby suxxx, à ce niveau là.



      - Ca fait réviser l'anglais.
      C'est bien ce que je dis, beaucoup de gens ne maîtrisent pas l'anglais, et sur un projet, ça peut faire mal.

      Et puis pas mélanger les langues. Je me souviens d'un projet de fac où j'ai fait tout une partie en angliche, et les autres tous en franchiche. Et bah c'était pas joli joli.

      Je suis d'accord, c'est moche, mais parfois c'est un moindre mal.
      Dans le cas de spec en français, je garde le vocabulaire métier en français, et le reste en anglais et je les compose à l'anglaise.

      Par exemple pour une méthode qui crée une facture, je l'appelle
      createFacture, car tout le monde parle de "facture" quand on discute, et pas de "invoice"
      Et de toute façon, il y a un certain nombre de dev qui ne connaissent pas le mot "invoice" et mettront "facture" dans leur code
      • [^] # Re: Parler anglais

        Posté par  . Évalué à 1.

        Les langages qui ne gère pas les accents, ça suxxx.

        Nan, sérieux ... qu'est ce que ca peux bien apporter (à part des problèmes) d'avoir un langage qui gère les accents ???

        Avec les éditeurs qui ne gèrent pas encore tous les codages modernes de caractères (UTF et compagnie), avec le nombre important de polices de caractères nécessaires pour pouvoir afficher toute la panoplie des caractères unicodes (empreinte mémoire), quid de la relecture et de la compréhension du nom des fonctions/variables (on parle de favoriser l'anglais ... imagine du code en caractères asiatiques !) ...

        Donc, ca apporte quoi ?
        • [^] # Re: Parler anglais

          Posté par  . Évalué à 3.

          Ou en Géorgien (http://fr.wikipedia.org/wiki/G%C3%A9orgien)
          J'avais essayé dans Eclipse il y a un certain temps et ça marche,
          pas mal pour rendre son code illisible ;)

          Je suis d'accord, ça apporte pas grand chose, pour le code,
          c'est d'ailleurs pour ça que je ne le fais pas.

          Par contre pour les chaînes de caractères c'est indispensable.
    • [^] # Re: Parler anglais

      Posté par  . Évalué à 2.

      Je confirme, et je rajouterais : "commenter le code en anglais" car quand tu débarque dans un pays dont tu ne comprends pas la langue et qu'on te file une appli que tu dois analyser pour savoir comment elle marche et ce que tu va pouvoir en tirer... ben les traducteurs automatiques ca t'avance pas des masses...

      Bon ca s'applique peut-être pas à tous les environements de travail mais on est quand même à l'heure de la mondialisation ;)
  • # Source inépuisable

    Posté par  . Évalué à 2.

    Au fait, une source inépuisable pour les développeurs

    http://c2.com/cgi/wiki

    Et aussi comme cité plus haut, Martin Fowler distille de sages conseille et n'est pas avare de son expérience

    http://www.martinfowler.com/
  • # ce qu'il ne faut surtout pas faire

    Posté par  . Évalué à 1.

    J'ai eu le cas, véridique, sur un projet (1 an de dev) pour lequel on était 2 dev, de voire que mon collègue faisait beaucoup des trucs du genre (entre autre malheureusement) :

    #define SEND_INFO \
    if (data_size) \
    if (send_rsp(dest, data)) \
    print_error;

    (et encore, celle-ci c'est une "gentille" comparé à ce qu'il a pondu)

    et dans le fichier source d'appeller de telles macros plus ou moins toutes les 15/30 lignes... sur des fichiers de plus de 5000 lignes.. et bien entendu dans des fonctions différentes..

    supeeeeeeeeeerrrrrrr - étonnament j'ai eu pas mal de confrontation avec ce gars justement pour ces questions de bonnes pratiques..
  • # et les assert alors ?

    Posté par  (site web personnel) . Évalué à 3.

    Etrangement, ça parle de svn, de tests, de code ...
    Mais pas d'assetions...

    Les assertions sont une bonne invention utile, voir même indispensable.

    Peut-être que personne n'en parle car vous les utilisez, et dans ce cas c'est bien, mais j'ai rencontré il y a peu des personnes (oups, mes chefs en fait...) qui avaient du mal à comprendre ce que c'était et l'intérêt d'écrire des assertions... (et evidemment se plaignaient ensuite quand sa crash sans savoir pourquoi)

    Evidemment certaines personnes ne comprenaient pas à quoi ça servait car ne lançait jamais leur programme en debug, toujours en release -> autre chose à ne jamais faire.
    Pour ma part je fais exactement l'inverse, je lance tout le temps en release (y compris quand ça met 2-3 vrai minutes à se lancer) et en release une fois que le debug est correct.
  • # Résumé perso de la discussion

    Posté par  (site web personnel) . Évalué à 2.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.