Journal Question à 100¤...

Posté par  (site web personnel) .
Étiquettes :
0
31
mai
2007
Si vous vous lancez dans un projet de code libre sur votre temps libre pour 15 jours, quel est le nombre de ligne de code maximum que pourra faire votre projet ?

Je me posais cette question après avoir lu, un texte de Sam, le Debian leader français, qui parlait de la plus grande facilité de terminer un projet de 2 semaines. J'imagine qu'il devait penser à une chose plus général que du code (documentation, paquaging, trac de bugs,...)

Donc, je me demandais quel serait la taille d'un module logiciel que l'on développerait en 15 jours sur son temps libre.

  • # montre l'argent d'abord.

    Posté par  . Évalué à 10.

    ca depend, 1 ligne en perl ou 40 000 en assembleur.

    • [^] # Re: montre l'argent d'abord.

      Posté par  . Évalué à 10.

      Oui mais tu pourra lire l'assembleur comme un livre alors que la ligne de Perl ne ressemblera a rien d'intelligible :D

      • [^] # Re: montre l'argent d'abord.

        Posté par  . Évalué à 2.

        Zut j'aurait du attendre 1h23 avant de poster

        Sinon plus sérieusement ça dépend du développeur et du projet, il est bien-sur impossible de faire un DE ou un OS en 2 semaines mais si le développeur connais bien le langage et le sujet sur lequel porte son projet, il peut pondre du code a une vitesse assez élevé !

        • [^] # Re: montre l'argent d'abord.

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

          Ca dépend. Un petit OS, ça se code relativement vite, surtout à plusieurs.

          Dans un autre genre, Autrijus Tang a codé la première version de pugs, un compilo perl6, en 6 jours. Mais bon, c'est un peu de la triche, c'est du haskell et c'est autrijus.

          • [^] # Re: montre l'argent d'abord.

            Posté par  . Évalué à 2.

            Je voulais dire un OS type Linux/*BSD

            Pour le compilo perl6 on est exactement dans le cas que je cite : Le développeur connais sûrement très bien haskell, perl6 et les autres "outils" nécessaires a son projet.

            • [^] # Re: montre l'argent d'abord.

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

              Perdu, Autrijus venait de finir un bouquin sur la programmation fonctionnelle et a voulu mettre ça en pratique. Les gens normaux codent de petites applications, style une calculatrice, mais Autrijus a décidé que ce serait plus rigolo d'implémenter un compilo pour un langage encore pas fini de spécifier avec tout et n'importe quoi dedans et dont plus grand monde ne pensait qu'il serait possible d'écrire un jour le compileur...

              Mais je ne pense pas qu'on puisse généraliser à partir d'Autrijus, ce qui est fort dommage !

              • [^] # Re: montre l'argent d'abord.

                Posté par  . Évalué à 4.

                Ouis enfin il devait bien connaître des sujets comme la c ompilation et maîtriser pas mal les outils qu'il a utilisé pour coder ça, et ne pas être à sa première implémentation de langage. Ça a l'air d'être une condition nécessaire (mais pas suffisante) pour réaliser ce genre de prouesse.

              • [^] # Re: montre l'argent d'abord.

                Posté par  . Évalué à 4.

                J'ai rien dit alors,

                Baleze le type, j'ai un peu le même esprit, mais rien de comparable a mon palmares.

  • # Autre question à 100 ¤

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

    Pour vous la qualité d'un projet libre se mesure t il en nombre de lignes de code ?

    • [^] # Re: Autre question à 100 ¤

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

      C'est même souvent l'inverse, c'est pour ça que des projets comme dwm, wmii ou xmonad s'imposent des limites de lignes de code (respectivement 2000, 10000 et 500), afin d'être sûr de garder un code propre, modulaire et factorisé. Bon, après on peut argumenter que ça encourage les astuces et hacks dans tous les sens pour gagner de la place, et je ne suis pas persuadé qu'appliquer une règle stricte soit une si bonne chose que ça, mais il est certain que la qualité d'un projet ne se mesure pas au nombres de lignes de code.

      Sans oublier que certains langages sont plus ou moins mal foutusverbeux. On fait en 20 lignes de haskell la même chose qu'en 500 lignes de java.

    • [^] # Re: Autre question à 100 ¤

      Posté par  . Évalué à 10.

      O
      U
      I

    • [^] # Re: Autre question à 100 ¤

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

      Je ne pensais pas attendre une masse pareil de commentaire sans aucun interret.

      Ta question aussi est à coté de la plaque. D'après les normes de dev, un produit à un nombre fixe de ligne de code pour taux de bug donné pour des logiciels semblables.

      Donc ma question n'a aucun rapport sur le fait que N lignes de codes, c'est trop pour le logiciel L. Vu que L n'est pas spécifié...

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

  • # Exploiteur!

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

    100 ¤ pour 2 semaines de travail, c'est de l'esssploitasssion!

    La gelée de coings est une chose à ne pas avaler de travers.

    • [^] # Re: Exploiteur!

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

      Ça dépend du pays, il y en a qui gagnes même pas 10¤ par mois pour bosser comme des forcenés. Ah, heu... bah en fait, oui, c'est de l'esssploitassssioon...

  • # Ca depend...

    Posté par  . Évalué à 7.

    C'est variable.

    Si on considere que le projet part de zero et doit etre _totalement fini_ alors il faut inclure le temps de faire le design, la doc, les tests, ... et ca va forcement reduire le temps de codage.

    Ensuite, il y a evidemment le type de soft que tu codes, car tester un soft qui fait des operations longues va forcement prendre plus de temps qu'un soft qui fait des operations courtes.

    Dans tous les cas, a mon avis il est difficile de pondre un projet de plus de 2-3000 lignes de qualite en 15 jours(en considerant que tu es cloitre dans ton bureau sans etre interrompu toutes les 15 minutes par un collegue ou un article sur linuxfr).

  • # de mon expérience dans une SSII...

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

    ...en fait, ça dépend beaucoup si tu es facturé à la ligne ou à la journée.

    Si tu es facturé à la journée, ça va dépendre de ce qu'il y a à lire dans tes flux RSS.

    • [^] # Re: de mon expérience dans une SSII...

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

      En même temps, si t'es facturé a la ligne, le temps d'écrire le code mort compte aussi.

      • [^] # le code mord ?

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

        C'est quoi du code mort ?
        des commentaires ?
        des lignes vides ?
        ou du code qui ne sera jamais appelé, style
        if (debug)
        printf("coucou");

        • [^] # Re: le code mord ?

          Posté par  . Évalué à 2.

          Du code mort, c'est plutot du code qui à une époque était utilisé, mais qui du fait de d'une modification ne sera jamais executée. Il peut s'agir de code relativement sioux à trouver, notament de fonction qui ont été réécrite/optimisée sous un autre nom et peu à peu migrée vers la nouvelle fonction. Apres dans le cas qui nous occupe ca serait plutot 
          if(false) { .... }

          • [^] # Re: le code mord ?

            Posté par  . Évalué à 5.

            T'es pas fou de mettre ton if sur une seule ligne toi ?
            Tu gâches le métier !

            Une ligne c'est une ligne, non mais.

  • # Par expérience...

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

    La première version de gshutdown que j'ai développé avec un pote a été développé en 1,5 semaine environ.
    Il y a 3500 lignes de code dans cette version (qui vienne de nous sur 6000 au total). (l'interface a été faite sous glade donc ça réduit de beaucoup le nombre de lignes)


    Bon en même temps, c'est pas mon métier de coder... Je code quasiment que pour le loisir (ya que depuis cette année que j'ai des cours d'info et ça va pas loin).

Suivre le flux des commentaires

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