Sondage Ce que je déteste le plus en informatique / programmation / codage c'est... :

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
10
9
sept.
2016
  • Lire la documentation :
    122
    (4.8 %)
  • Écrire du pseudo-code :
    63
    (2.5 %)
  • Écrire du code :
    85
    (3.3 %)
  • Documenter mon code :
    189
    (7.4 %)
  • Coder ce qu'on me demande et non pas ce que j'aime :
    304
    (11.9 %)
  • Relire mon code :
    26
    (1.0 %)
  • Tester et déboguer :
    88
    (3.5 %)
  • Écrire un rapport de bug :
    47
    (1.8 %)
  • Quand il faut y aller alors que c'est sûr, j'ai presque fini :
    297
    (11.7 %)
  • Délivrer une version pertinemment buggée sous la contrainte :
    747
    (29.3 %)
  • Répondre à un sondage :
    175
    (6.9 %)
  • Quand le chat marche sur le clavcxw< :
    111
    (4.4 %)
  • Quand y a plus de café :
    295
    (11.6 %)

Total : 2549 votes

La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses. 76,78 % des personnes sondées estiment que ces sondages sont ineptes.

  • # La doc

    Posté par  . Évalué à 2.

    Lire de la doc traduite a la Google me donne mal a la tête,
    surtout quand tu a 300 pages a épluché pour te rendre compte que l’info que tu cherches ni est pas.

    là tu te rends compte que tu a perdu ta journée (j’exagère) et que tu aurais préféré aller a la piscine.

    Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

    • [^] # Re: La doc

      Posté par  . Évalué à -1.

      traduite à la Google

      C'est ça ton problème, on peut rien faire sans savoir lire les docs en anglais.

      • [^] # Re: La doc

        Posté par  . Évalué à 10.

        Il n'a pas dit qu'il traduisait depuis l'anglais.

        • [^] # Re: La doc

          Posté par  . Évalué à 10.

          En même temps, il n'a pas non plus l'air de bien maîtriser le français…

      • [^] # Re: La doc

        Posté par  . Évalué à 3.

        Ça peut être le mec qui écrit la doc qui n'est pas anglophone et qui traduit à grands coups de google translate.

      • [^] # Re: La doc

        Posté par  . Évalué à 0.

        C'est ça ton problème, on peut rien faire sans savoir lire les docs en anglais.

        Y compris quand c'est un français qui fait la doc, c'est triste. (je pense au langage hakka "inventé" par un français sorti en full english)

        Cessez d'apprendre le français aux gosses ça sert plus a rien c'te langue :P (un gosse anglophone à quand même plus de chance de créer sa startup en technologie qu'un francophone, rien que parce qu'il ne sera pas démotivé devant de la doc qui n'est pas dans sa langue)

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: La doc

          Posté par  (Mastodon) . Évalué à 2.

          (je pense au langage hakka "inventé" par un français sorti en full english)

          Euh… On dirait du deeplop !

  • # Re : LA DOC

    Posté par  . Évalué à 4.

    C'est dur de choisir entre :

    • Lire la documentation
    • Documenter mon code

    J'ai déjà du mal à coder la doc que j'ai faite pour mon code alors décoder les docs des autres codes …

  • # code pro != code perso

    Posté par  . Évalué à 8. Dernière modification le 10 septembre 2016 à 06:11.

    lot1 : Parfois (souvent), les commerciaux vendent du rêve, les clients ne veulent pas payer le juste prix, les specs sont expédiées, le code il faut le pis
    lot2 : ser, on n'a pas le temps de tester, de valider, il est déjà l'heure de livrer, pourtnt ce n'est pas termi
    lot3 : né, (s/pourtnt/pourtant/), l'appel d'offre est lancé, bonne chance à ceux qui vont le remporter et reprendre :(

  • # Lire la documentation

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

    La plupart de temps, ce qui m'agace c'est de lire de la mauvaise documentation. Voici les principales défauts que je retrouve dans les documentations avec lesquelles je dois le plus souvent travailler:

    • Documentation qui hésite entre la référence, l'introduction du manuel de l'utilisateur et le manuel de l'utilisateur lui-même. L'information y est mal structurée, pas au bon endroit, etc.

    • La documentation mal présentée, l'exemple typique est la documentation de NodeJS ou celle de l'API AWS JavaScript. La documentation n'est pas assez espacée, pas assez bien structurée – on a des descriptions d'éléments 'APIs obsolètes qui s'étendent sur plusieurs écrans au beau milieu de la description, et comme il n'y a pas d'espaces verticaux ou de mises en retrait bien visibles, on ne se s'y retrouve pas. À la rigueur le seul moyen de s'en sortir à peu près, serait de l'imprimer! Et puis comme on est en 2016 le concept de page est has been et on écrit tout dans un seul document – alors que la page est une bonne unité pour délimiter et hiérarchiser le texte.

    • La documentation ambigüe, où les descriptions des fonctions laissent place non pas à une interprétation possible mais à plusieurs, ou bien qui laissent en suspens des questions essentielles que tout programmeur expérimenté se pose dans certaines situations. Par exemple la documentation du SDK AWS n'arrive pas à traiter proprement les cas de “valeur”, “null” et “membre non défini” – alors que quand on documente du JavaScript, c'est évidemment la chose avec laquelle il faut être le plus propre! – ce qui oblige à faire des essais. Autre exemple la documentation de NodeJS qui, lorsqu'elle aborde les streams se garde bien de décrire, lorsqu'on utilise des streams lisant la sortie d'un processus fils, le comportement bloquant ou non de l'écriture par le processus fils. Quand on lit en détails on peut deviner ce qui se passe et essayer pour vérifier, mais ce ne devrait pas être nécessaire.

    • La documentation bavarde, qui au lieu d'utiliser une langue technique claire et concise se livre à des bavardages incessants. Exemple typique le manuel de GNU Make qui arrive à dire en plus de 205 pages essentiellement la même chose que les 8 pages de man du BSD Make. Pour moi c'est beaucoup plus facile de retrouver une information dans 8 pages de documentation que dans 205.

    • [^] # Re: Lire la documentation

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

      J'ajouterais, en plus de ma remarque sur la doc pour PhD en math faites autre part dans les commentaires, les documentations pas à jour (et donc fausse). C'est surtout le cas dans des langages avec un typage un peu "dynamique" où certains arguments peuvent prendre un peu n'importe quoi, du genre un flag qui prend soit None, soit une fonction, soit des chaînes de caractère pour décrire une méthode, et où la documentation liste la mauvaise liste de possibilité et ne documente pas le prototype de la fonction que on doit passer ;)

    • [^] # Re: Lire la documentation

      Posté par  . Évalué à 5.

      Pour moi, la grosse majorité des documentations n'expliquent pas les principes généraux.
      On a souvent des documentations qui sont qu'une redite de l'interface graphique.

      On t'explique qu'en remplissant le champ « Nom du client » tu va renseigner le nom du client. MAIS ON S'EN COGNE ! Il y a même parfois des copies d'écran d'une demi-page pour bien indiquer où saisir le nom du client.
      Pas une seule ligne sur les concepts, pourquoi utiliser telle fonctionnalité, ou comment procéder dans tel cas.

  • # Avoir à travailler sur un code non documenté que je n'ai pas écrit

    Posté par  . Évalué à 10.

    Dans la plupart des cas ça se fait, mais ça rallonge le temps de développement car le temps de compréhension est plus long.

  • # Le code impératif

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

    Ecrire du code (particulièrement quand il s'agit de gestion d'erreur) dans des langages orientés impératifs ou OO depuis que j'ai découvert Elm et Haskell :)

    • [^] # Re: Le code impératif

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

      Oui !

      Mais si il y a une chose que je déteste avec Haskell, c'est la documentation pour docteur en informatique fondamental.

      J'adore le module Bifunctor mais je met au défi un humain normal (comprendre, un mec qui est au moins docteur en informatique avec +10 ans d’expérience en programmation) de comprendre ce que fait ce module à la première lecture. Alors que merde, un exemple tout simple au début n'aurait pas fait de mal, genre :

      -- Application to tuple :
Prelude Data.Bifunctor> first length ("hello", 10)
(5,10)
Prelude Data.Bifunctor> second (*2) ("hello", 10)
("hello",20)
Prelude Data.Bifunctor> bimap length (*2) ("hello", 10)
(5,20)

      • [^] # Re: Le code impératif

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

        En comparaison la documentation de OCaml est beaucoup plus simple. Elle est écrite de façon assez “matheuse” mais à un niveau beaucoup plus élémentaire: le côté matheux de la documentation est plutôt utilisé pour décrire brièvement une fonction par une phrase générale qui inclut aussi les cas particuliers (de type liste vide, etc.). Après pour l'exemple que tu cites, je ne sais pas ce qui pousse les gens à écrire des documentations comme ça… je ne dis pas que les phrases “Formally, the class Bifunctor represents a bifunctor from Hask -> Hask. Intuitively it is a bifunctor where both the first and second arguments are covariant.” ne sont pas intéressantes mais elles sont plutôt à mettre en remarque, ou en tout cas, après la description de ce que “font” concrètement les fonctions du module.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à -6.

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

        • [^] # Re: Le code impératif

          Posté par  . Évalué à 2.

          IMHO: ce n'est pas de la doc.
          C'est un vulgaire commentaire par le mec qui a ecrit le bousin, pour lui meme, et pas forcement clair pour lui si il le relisait maintenant.

          Je doute fortement que ce soit un vulgaire commentaire pour l'auteur : il m'est parfaitement compréhensible, et je suppute qu'il en est de même pour son auteur. Cela étant je ne pense pas faire partie de la catégorie des gens normaux dont parlait Guillaum (bien que j'ai ni doctorat en informatique, ni +10 ans d'expérience en programmation), et je ne suis pas partisan du jargon employé fréquemment dans le monde de la programmation fonctionnel comme je l'avais exprimé humoristiquement dans ce commentaire sur la dépêche au sujet de la sortie du dernier compilateur GHC, commentaire que je concluais ironiquement par :

          Je milite également pour que l'on soit plus rigoureux dans l'expression de certaine proposition, et que l'on ne dise plus : « la terre est ronde », mais plutôt : « d'un certain point vue, une équipotentielle du champ de gravitation terrestre est homéomorphe à la sphère S_2 ». :-D

          Cela étant, la documentation pointée par Guillaum s'adresse plus aux programmeurs qui voudraient implémenter une instance de cette classe qu'aux utilisateurs d'une instance particulière, ce qui est le cas de l'exemple donné par Guillaum dans son commentaire : c'est une instance de la classe générale des bifoncteurs pour les paires. Mais la bibliothèque en question fournit, par exemple, une instance pour les triplets où les deux fonctions s'appliquent respectivement sur la seconde et troisième composante du triplet. Pour ceux qui comprennent le Haskell, qui sont au fond les programmeurs à qui est destiné un tel code, le plus simple est d'aller lire le code de son implémentation (il est très court et parfaitement compréhensible, même si l'on ne sait pas ce qu'est un bifoncteur ou un paramètre covariant). Et pour aller dans le sens du commentaire initial de Guillaume Denry, après lecture, essayez d'imaginer le compléxité de hiérarchie de classes et la longueur du code nécessaire pour implémenter la même chose en POO. ;-)

          Il n'en reste pas moins, en revanche, que cette documentation est bien succincte, et les différentes instances auraient mérité d'être documentées et illustrées d'exemples.

          Pour rejoindre le propos de Michaël sur les documentations en OCaml, ainsi que l'importance et la difficulté d'écrire une bonne documentation, les documentations des bibliothèques de Daniel Bünzli sont pour moi un modèle du genre comme, par exemple, la documentation de sa bibliothèque sur le XML

          Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

          • [^] # Re: Le code impératif

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

            Je doute fortement que ce soit un vulgaire commentaire pour l'auteur : il m'est parfaitement compréhensible, et je suppute qu'il en est de même pour son auteur.

            C'est dommage, parce que ce commentaire n'a précisément aucun sens, vu que la catégorie Hask n'existe pas!

            • [^] # Re: Le code impératif

              Posté par  . Évalué à 1.

              Eh ! tu sodomises du diptère là. :-P

              J'avais vu passer cet article sur le planet OCaml, mais comme je ne suis pas un fin connaisseur de Haskell je n'y avais pas prêté attention plus que cela. Alors dans le fond, je suis d'accord vous avez raison, la catégorie Hask n'existe pas, et donc stricto sensu l'énoncé n'a formellement aucun sens. Pour reprendre sa comparaison avec les séries, c'est comme si ils affirmaient que toutes les séries étaient convergentes, d'où sa raillerie avec la question d'approximer à la quatrième décimale la valeur de la série 1 + 1/2 + 1/3 ....

              Néanmoins, si l'on se limite aux calculs qui terminent (i.e. aux fonctions totales sans prendre en compte les fonctions partielles) les significations semblent se recouper en un certain sens. Du moins c'est ce que j'ai compris de l'article Fast and loose reasoning is morally correct que j'ai rapidement survolé. D'ailleurs dans un addendum à son article, Andrej Bauer ne semble pas remettre en cause cette approche :

              Nor am I objecting to “fast & loose” mode of thinking while investigating a new idea in Haskell, that is obviously quite useful as well. I am objecting to:

              1. The fact the the Haskell wiki claims there is such a thing as “the category Hask” and it pretends that everything is ok.
              2. The fact that some people find it acceptable to defend broken mathematics on the grounds that it is useful. Non-broken mathematics is also useful, as well as correct. Good engineers do not rationalize broken math by saying “life is tough”.

              Ce qu'il a peut être rajouté après ce commentaire d'Edward Kmett.

              Pour ce qui est des objections d'Andrej, elles peuvent effectivement se défendre et se comprendre.

              Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

          • [^] # Re: Le code impératif

            Posté par  (site web personnel) . Évalué à 3. Dernière modification le 13 septembre 2016 à 09:50.

            Je milite également pour que l'on soit plus rigoureux dans l'expression de certaine proposition, et que l'on ne dise plus : « la terre est ronde », mais plutôt : « d'un certain point vue, une équipotentielle du champ de gravitation terrestre est homéomorphe à la sphère S_2 ». :-D

            Homéomorphe, c'est un peu faible, il vaudrait sûrement mieux demander qu'on puisse coincer cette équipotentielle entre deux ellipsoïdes de rayons pas trop différents. :)

            Oui bien demander un difféormorphisme avec une borne sur l'intégrale de la divergence.

      • [^] # Re: Le code impératif

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

        Bon, je viens de lire la doc, et

        bimap :: (a -> b) -> (c -> d) -> p a c -> p b d
        Map over both arguments at the same time.
        bimap f g ≡ first f . second g

        C'est plutôt clair, je trouve. Mais bon, il s'avère que j'ai un PhD en informatique fondamentale, et que j'ai fait du Haskell professionnellement…

  • # passer pour un c** auprès du client, ou galérer à réparer

    Posté par  . Évalué à 7.

    parce qu'un autre (qui n'est pas là aujourd'hui, ou carrémment plus dans la boite) a fait une bourde / fait à la rache / pas documenté.

    • [^] # Re: passer pour un c** auprès du client, ou galérer à réparer

      Posté par  . Évalué à 9.

      C'est ça pour moi le pire, "corriger" le code d'un "génie" qui a codé comme un porc sans se soucier une seconde des gens qui passeraient après. En général le "génie" en question finit par s'embourber dans son propre code et planter son truc pour finalement demander à faire autre chose et convaincre un chef quelconque que c'est tellement bien codé que ça ne devrait pas prendre longtemps à quelqu'un d'un minimum talentueux pour corriger le truc (notez comme le fourbe flatte autant lui-même que la victime). Car oui, le "génie" se lasse, il veut passer à autre chose. La traduction exacte est "les rats quittent le navire".

      En général, après relecture par plusieurs personnes (ne jamais rester seul dans ces cas là) le tout part à la poubelle ou n'est jamais corrigé.

      Fin du mode aigri, maintenant quand on me dit "il y a un truc écrit par , il a changé d'équipe, il faudrait faire un correctif, les gars de l'équipe ont du mal on a besoin de quelqu'un d'un peu experimenté, ça tente quelqu'un?" je fuis ventre à terre.

      • [^] # Re: passer pour un c** auprès du client, ou galérer à réparer

        Posté par  . Évalué à 2.

        Je me suis moi-même fait avoir à ce jeu, et comme première expérience en développement, c'est brutal : il faut résoudre les bugs du vieux tromblon pas documenté, faire évoluer tromblon n°2, et développer un nouveau programme qui va intéragir avec tromblon n°3.
        Je croise les doigts pour être parti avant que tout me pète à la figure.

        • [^] # Re: passer pour un c** auprès du client, ou galérer à réparer

          Posté par  . Évalué à 2.

          tiens ca m'est arrivé, équilibriste/résolution de pb pendant 6 mois a la rache en tirant la langue et a la fin de la mission je lorgne sur la grosse prime avec mon départ et …. PAF on me propose un CDI /o\ pour être a temps plein dessus. ouuiiiiiiinnnn !

  • # Les gens qui utilisent le mot "codage"

    Posté par  . Évalué à 2.

    Ou pire encore : "codeur".

  • # La finalisation

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

    Très souvent, il y a pas mal de petits trucs pénibles et inintéressants à faire pour finaliser le projet (le packaging, renvoyer à l'utilisateur des messages utiles et compréhensibles, etc.).

    • [^] # Re: La finalisation

      Posté par  (site web personnel) . Évalué à 8. Dernière modification le 12 septembre 2016 à 05:46.

      tu ne serais pas en train de penser aux automates de paiement par carte, qui te disent
      "paiement refusé"
      quand tu es à l'étranger et
      - tu as oublié de prévenir ta banque, donc ta carte est bloquée
      - tu as atteint ton plafond de retrait ou de paiement sur 7 jours
      - la banque locale n'arrive pas à joindre ta banque
      - la banque locale ne veut pas de paiement en Euros car cela induit des frais
      - et quelques autres cas…
      ???

      ウィズコロナ

      • [^] # Commentaire supprimé

        Posté par  . Évalué à -9.

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

      • [^] # Re: La finalisation

        Posté par  . Évalué à 5.

        Le non détail d'un message d'erreur peut être volontaire. Quand tu t'identifie sur un système avec un login/mdp on te dit pas si c'est le login ou mdp qui est faux si tu fait une erreur, juste "connexion impossible" ou "mauvais login ou mot de passe". De la même manière dire pourquoi un paiement est refusé donne une indication a quelqu'un de mal veillant de contourner les protections.
        Et même pour le péquin moyen avoir un message trop explicite n'est pas forcément facile a comprendre/interprété. Donc juste dire c'est pas possible est plus simple a gérer/comprendre.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à -10.

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

  • # Les gens

    Posté par  . Évalué à 10.

    L'enfer c'est les autres

  • # Le copier / coller

    Posté par  . Évalué à 3.

    Je n'aime pas ça (et c'est pas dans les items du sondage).

    • [^] # Re: Le copier / coller

      Posté par  . Évalué à 3.

      Je suppose que tu veux dire le code dupliqué.
      Parce que celui qui n'a jamais copier-coller du code depuis SO va te jeter la première pierre…

      • [^] # Re: Le copier / coller

        Posté par  . Évalué à 1. Dernière modification le 20 septembre 2016 à 13:47.

        Mmm, je ne sais pas, tout dépend du contexte :

        Si je suis en plein codage : j'ai développé le réflexe de faire un couper/coller et créer une fonction / un objet lorsque le besoin de copier/coller du code se fait sentir.

        Par contre, si je veux sur un bout de code sur le net ou sur un projet antérieur pour le réadapter, oui je copie/colle sans vergogne :)

  • # re:

    Posté par  . Évalué à 3.

    "Délivrer une version pertinemment buggée sous la contrainte"

    Bah justement! On peut facturer des frais de maintenance/SAV ;)

    • [^] # Re: re:

      Posté par  . Évalué à 5.

      ça c'est la logique de réflexion du commercial. La logique du codeur n'est pas la même, pour sa propre estime il préfère livrer quelqu chose dont il n'a plus a toucher, pour éviter de voir les horreur qu'il a laissé ;-)

      • [^] # Re: re:

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

        ça c'est la logique de réflexion du commercial.

        Plutôt du commercial que tu ne veux pas dans ta boîte parcequ'il ne s'intéresse visiblement pas trop à la relation avec le client ni à la bonne réputation de l'entreprise. Ne pas savoir dire “désolé j'ai merdé je n'ai pas tenu les dates, on a eu tel et tel problème“ est la signature de l'amateurisme.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à -10.

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

          • [^] # Re: re:

            Posté par  (site web personnel) . Évalué à 8. Dernière modification le 13 septembre 2016 à 21:40.

            C'est beau la naivete…

            Si tu as des choses concrètes à partager n'hésite pas à le faire. Pour ma part j'ai eu l'occasion de travailler pour une entreprise qui utilisait la stratégie décrite par le premier commentaire, et c'est essentiellement ce qui m'a poussé à démissionner. Je suis parti parceque d'une part je ne cautionne pas cela, d'autre part parceque les gens qui baisent leurs clients baisent aussi leurs employés. L'expérience montre que ce n'est pas partout comme cela.

            La vraie naïveté c'est de croire que le pessimisme peut tenir lieu d'expérience.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à -10.

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

          • [^] # Re: re:

            Posté par  . Évalué à 0.

            C'est moche la connerie…

            Sérieusement, avec une attitude pareil ta boîte elle tient pas 5 minutes.

            Mais faut avoir connu la vraie vie (ou avoir un minimum de logique) pour s'en rendre compte, pas comme Riendf.

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # la doc

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

    Ben moi, j'aimerai bien pouvoir lire la documentation. En ce moment, c'est plutôt, tu me fais ça en 2 jours. Et après c'est, ça marche mais il n'y a ni la fonctionnalité X ni la fonctionnalité Y, et le bouton, je voulais plutôt là, et puis si tu avais fait cette partie comme ça, ça serait mieux. Bon aller, tu me refais tout ça pour demain.

    • [^] # Re: la doc

      Posté par  . Évalué à 3.

      pour demain.

      pour hier. FTFY.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # Et les tests?

    Posté par  . Évalué à 2. Dernière modification le 14 septembre 2016 à 00:47.

    Je trouve ca marrant que ce sondage ne mentione pas les tests automatises.
    L'auteur deteste-t-il tellement les tests qu'il n'etait pas question d'en parler?

    Je prefere largement me coltiner un code non documente avec tests automatises plutot qu'un code documente mais sans tests.

    PS: desole pour l'absence de diacritiques, pas ma machine, pas ma langue sur le cla

    • [^] # Re: Et les tests?

      Posté par  . Évalué à 5. Dernière modification le 14 septembre 2016 à 21:57.

      Bah, moi ce que je détest c'est cette excuse bidon que l'on rencontre de plus en plus et qui consiste à dire que le code n'a pas besoin de doc vu qu'il y a des tests qui servent de doc (attention, je ne veux pas dire que c'est ce que tu sous-entends, c'est juste ton commentaire qui m'a fait penser à ça).

      D'une manière générale, je suis contre les excuses bidons que les développeurs s'inventent pour ne pas écrire de doc.

      • [^] # Re: Et les tests?

        Posté par  . Évalué à 2.

        Tout a fait d'accord avec toi.
        J'ajouterai meme que … d'une manière générale, je suis contre les excuses bidons que les développeurs s'inventent pour ne pas écrire de tests.

        PS: merci pour tes diacritiques ;)

    • [^] # Re: Et les tests?

      Posté par  . Évalué à 1.

      Quand j'écris des tests unitaires, je me console en me disant que ce sera utile (et ça l'est vraiment). Et quand je découvre un bug, je me dis que j'ai bien fait d'écrire des tests. Mais bon c'est clair que ce n'est pas la partie la plus amusante.

  • # Mandriva

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

    "Délivrer une version pertinemment buggée sous la contrainte"

    Y a des anciens de chez Mandriva SA, ici…

Suivre le flux des commentaires

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