Combien de lignes de code un développeur C # peut-il produire par mois?
Un cadre de mon lieu de travail m'a posé la question à mon groupe de développeurs:
Combien de lignes de code un développeur C # peut-il produire par mois?
Un ancien système devait être porté en C # et il aimerait que cette mesure fasse partie de la planification du projet.
D'une source (apparemment crédible), il avait la réponse "10 SLOC/month" mais il n'était pas satisfait de cela.
Le groupe a convenu que cela était presque impossible à préciser car cela dépendrait d'une longue liste de circonstances. Mais nous pouvions dire que l'homme ne partirait pas (ou ne serait pas très déçu de nous) si nous ne trouvions pas de réponse qui lui conviendrait mieux. Il est donc reparti avec la meilleure réponse de "10 SLOC/day"
Peut-on répondre à cette question? (désinvolte ou même avec une analyse)
Demandez à votre cadre combien de pages de contrat son avocat peut écrire par mois. Puis (j'espère), il se rendra compte qu'il y a une énorme différence entre la rédaction d'un contrat d'une seule page et la rédaction d'un contrat de 300 pages sans lacunes ni contradictions. Ou entre la rédaction d'un nouveau contrat et la modification d'un contrat existant. Ou entre la rédaction d'un nouveau contrat et sa traduction dans une autre langue. Ou à un système juridique différent. Il conviendra peut-être même que les "pages de contrat par unité de temps" ne sont pas une très bonne mesure pour la productivité des avocats.
Mais pour vous donner n pe réponse à votre vraie question: D'après mon expérience, pour un nouveau projet, quelques centaines de SLOC par jour et développeur ne sont pas rares. Mais dès que les premiers bugs apparaîtront, ce nombre baissera fortement.
Combien de lignes de code un développeur C # peut-il produire par mois?
S'ils sont bons, moins de zéro.
Courez dans l'autre sens ... Maintenant.
LoC est l'une des pires mesures que vous pouvez utiliser.
Les mauvais développeurs peuvent potentiellement écrire plus de LoC par jour que les bons développeurs, mais produisent du code de détritus.
Selon la complexité du code, le portage peut être effectué par des processus d'automatisation qui entraîneraient de gros milliers de changements de LoC par jour, tandis que les sections plus difficiles où les constructions de langage sont extrêmement différentes sont portées au 100LoC par jour.
Envoyez-lui de lire la page Wikipedia sur SLOC . Si donne quelques exemples agréables et simples de la raison pour laquelle il s'agit d'une mesure si médiocre.
La bonne réponse: non ...
Cet exécutif doit être informé que le SLOC n'est pas une mesure valide pour la progression de l'analyse
La réponse bâclée: n'importe quel nombre que vous pouvez composer.
Donnez-lui simplement un numéro, vous et votre équipe pouvez facilement le faire de toute façon. (En mettant sauf ligne, lignes vides, commentaires etc etc, juste pour permettre à ce gars de continuer à vivre dans son monde fantastique, et de hanter encore une autre équipe et de continuer le cycle renforcé de la misère qui fait une histoire au quotidien.
Pas sympa, mais faisable.
À première vue, cette question semble absolument stupide, et tout le monde ici n'a répondu qu'à la stupide partie C # LoC. Mais il y a une nuance importante - c'est une question sur les performances portage. La bonne façon de poser cette question est de demander combien de lignes de code du projet source (celui qui est porté) qu'un développeur peut gérer dans une unité de temps donnée. C'est une question parfaitement justifiée, car le nombre total de lignes de code est connu, et c'est exactement la quantité de travail à faire. Et la bonne façon de répondre à cette question est de collecter un peu de données historiques - travailler pendant, disons, une semaine et mesurer les performances de chacun des développeurs.
Je n'ai qu'une chose à dire:
"Mesurer la progression de la programmation par des lignes de code, c'est comme mesurer la progression d'un bâtiment en poids."
-- Bill Gates
Après cela, vous pouvez affirmer que Bill Gates ne savait pas comment réussir un logiciel;)
Remarque: SLOC est cependant une très bonne mesure de la complexité de la base de code!
I
can
write
large
numbers
of
lines
of
code
per
month.
Proportionnelle au nombre de mots, en fait.
Vous voyez mon point?
C'est généralement une mauvaise idée d'appeler votre patron un idiot, donc mes suggestions commencent par comprendre et discuter des mesures, plutôt que de les rejeter.
Certaines personnes qui ne sont pas réellement considérées comme des idiots ont utilisé des mesures basées sur des lignes de code. Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan et Steve McConnell les ont tous utilisés. Vous les avez probablement utilisés même si juste pour dire à un collègue, ce module God est de 4000 lignes, il doit être divisé en classes plus petites.
Il existe des données spécifiques liées à cette question provenant d'une source que beaucoup d'entre nous respectent.
http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html
http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html
http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22
Je soupçonne que la meilleure utilisation de la ligne de code par heure de programmation est de montrer que pendant la durée de vie du projet, cette valeur commencera assez haut, mais comme des défauts sont trouvés et corrigés, de nouvelles lignes de code seront ajoutées pour résoudre les problèmes qui ne faisaient pas partie des estimations originales, et des lignes de code supprimées pour éliminer la duplication et améliorer l'efficacité montreront que LOC/h indique autre chose que la productivité.
- Lorsque le code est écrit rapidement, bâclé, gonflé et sans aucune tentative de refactorisation, l'efficacité apparente sera à son maximum. La morale ici sera que vous devez faire attention à ce que vous mesurez.
- Pour un développeur particulier, s'il ajoute ou touche une grande quantité de code cette semaine, la semaine prochaine, il pourrait y avoir une dette technique à payer en termes de révision, de test, de débogage et de retravaillage de code.
- Certains développeurs travailleront à un taux de sortie plus cohérent que d'autres. On peut constater qu'ils passent le plus de temps à obtenir de bonnes histoires d'utilisateurs, se retournent très rapidement et effectuent des tests unitaires correspondants, puis se retournent et créent rapidement du code qui se concentre uniquement sur les histoires d'utilisateurs. Le retentissement ici est que les développeurs méthodiques auront probablement un tour rapide, écriront du code compact et auront peu de retouches car ils comprennent très bien le problème et la solution avant de commencer à coder. Il semble raisonnable qu'ils codent moins car ils ne codent qu'après avoir réfléchi, plutôt qu'avant et après.
- Lorsque le code est évalué pour sa densité de défauts, il se révèle être moins qu'uniforme. Certains codes expliqueront la plupart des problèmes et des défauts. Il sera candidat à la réécriture. Lorsque cela se produit, il deviendra le code le plus cher car en raison de son haut degré de retravail. Il aura le plus grand nombre brut de lignes de code (ajoutées, supprimées, modifiées, comme cela pourrait être signalé par un outil comme CVS ou SVN), mais les lignes de code nettes par heure investies les plus faibles. Cela peut finir par être une combinaison du code implémentant le problème le plus complexe ou la solution la plus compliquée.
Quelle que soit l'issue du débat sur la productivité du programmeur dans les lignes de code, vous constaterez que vous avez besoin de plus de main-d'œuvre que vous ne pouvez vous le permettre et que le système ne sera jamais terminé à temps. Vos vrais outils ne sont pas des métriques. Ils utilisent une méthodologie supérieure, les meilleurs développeurs que vous pouvez embaucher ou former, et le contrôle de la portée et des risques (probablement avec des méthodes Agiles).
Je pourrais avoir une position légèrement différente à ce sujet, mais je pense que je pourrais comprendre pourquoi l'exécutif recherchait cette information s'il fait actuellement la planification de projet. Comme il est difficile d'estimer la durée d'un projet, l'une des méthodes utilisées (voir: Estimation logicielle: démystifier l'art noir ) consiste à estimer la durée du projet. sur la base du nombre de SLOC dans des projets similaires et maintenant les développeurs peuvent produire en moyenne. Dans la pratique, cela est censé être fait en utilisant des enregistrements historiques que le groupe a sous la main pour des projets similaires avec des développeurs identiques ou similaires.
Cependant, cela ne vaut rien que ces estimations soient destinées uniquement à la planification de projet de base et ne sont pas réellement destinées à définir le rythme des développeurs sur le projet car les choses changent d'un jour à l'autre. Ainsi, la plupart de ce que vous lisez sur l'utilisation des SLOC comme outil d'estimation est qu'ils sont bons à long terme si vous avez déjà un bon corpus de connaissances, mais moche pour une utilisation quotidienne.
Je peux vous dire qu'une charge d'entrepreneurs pour un grand projet a écrit 15 000 LOC (chacun) en un an. C'est une réponse incroyablement grossière, mais elle nous a été utile car nous avons 400 000 LoC C++ existants et nous pourrions comprendre que la conversion de tout cela en C # nous prendrait environ 26 années-hommes pour terminer. Donner ou prendre.
Alors maintenant, nous connaissons l'ordre de grandeur approximatif, nous pouvons mieux planifier pour cela - obtenir 20 devs et estimer le travail d'un an pour eux serait à peu près correct. Avant de compter, nous ne savions pas combien de temps il faudrait pour migrer.
Donc, mon conseil pour vous est de vérifier tout le code que vous avez écrit dans un laps de temps spécifique (j'ai eu la chance d'avoir un nouveau projet avec lequel travailler), puis d'exécuter l'un des nombreux outils de mesure de code dessus. Divisez le nombre par le temps et vous pouvez lui donner une réponse précise - combien de LOC vous écrivez réellement par jour. Pour nous, c'est sorti à 90 LOC par jour! Je suppose que nous avons eu beaucoup de réunions et de documentation sur ce projet, mais je suppose que nous aurons également beaucoup de réunions et de documentation sur le prochain :)
Donnez-lui une meilleure métrique avec laquelle travailler
Au lieu de LOC , expliquez que c'est la pire mesure à utiliser. Donnez-lui alors une alternative:
Nombre de fonctions/caractéristiques par Demandes de fonctions/fonctions -> NOFF/RFF
Vous devrez peut-être ajouter une pondération/normalisation en plus de NOFF/RFF, pour répondre aux quantités de demandes par semaine.
:) clairement ce qui précède est composé, mais tout est meilleur que SLOC ...
Cela semble correct.
Si vous prenez en compte le débogage, la documentation, la planification, etc. Cela représente en moyenne environ 10 lignes de code par jour. En fait, j'évaluerais 10 lignes par jour sur le côté supérieur (c'est-à-dire un développeur très productif).
Même si vous pouvez produire quelques centaines de lignes en une seule journée (ce n'est pas durable). Ce ne sera pas un code de qualité tant que vous n'aurez pas ajouté tous les tests unitaires de la documentation et bien sûr débogué le code après que votre test unitaire ait montré les erreurs. Après tout cela, vous êtes de retour à 10.
Les autres réponses sont correctes, c'est une question stupide et la réponse ne signifie pas une fichue chose. C'est vrai, mais il se trouve que je sais combien de lignes de code j'ai produites en environ un mois.
C'est environ 3000 lignes de code C # sans XML-doc. J'implémentais de nouvelles fonctionnalités et je me suis retrouvé avec ce montant en un mois ou un mois et une semaine. C'est tout ce qui s'est retrouvé dans le contrôle de code source, beaucoup de code a été écrit puis refactorisé ou supprimé.
Je suis un développeur C # et j'essaie d'être bon dans ce domaine, mais je ne peux pas vous dire à quel point je suis objectivement bon. J'ai essayé d'écrire du bon code et j'ai mis beaucoup d'efforts pour le rendre facile à maintenir. Je ne mets des commentaires qu'une ou deux fois dans ce code.
Je ne sais pas si c'est trop ou trop peu de lignes de code et je dois dire que je m'en fiche vraiment. C'est un morceau de données sans signification et il ne peut en aucun cas être utilisé pour l'extrapolation. Mais je connais ces données, j'ai donc décidé de les partager.
Laissez votre manager s'en occuper ou commencez la recherche d'emploi.
Sérieusement, vous pourriez passer du temps ce qui pourrait finir par être un effort désespéré pour expliquer à l'exécutif les méthodes appropriées et inappropriées pour mesurer les progrès d'un projet vers l'achèvement. En réalité, à quoi servent les ingénieurs et les chefs de projet.
En revanche, les circonstances sont telles que l'exécutif en question EST votre ingénieur et/ou chef de projet. Vous avez des problèmes beaucoup plus importants et plus fondamentaux à traiter, même s'ils ne se sont pas encore révélés. Dans ce cas, un problème comme celui-ci peut servir de "coup de semonce" pour de plus gros problèmes à venir.
Je suppose qu'un développeur travaillant avec un langage comme C # devrait être capable d'écrire/générer environ 10 000 LoC/jour. Je suppose que je pourrais faire ça. Je ne le ferais jamais.
Ce que vous voulez d'un développeur, c'est de faire son travail en 10 LoC/jour. Moins de code, c'est toujours mieux. Il m'arrive souvent de commencer à produire une masse de code, puis à couper jusqu'à ce que j'atteigne le maximum de simplicité, donc j'ai effectivement des jours avec des LoC négatifs.
Dans un sens, le codage est comme de la poésie. La question n'est pas de savoir combien de lignes un poète peut écrire, mais combien il peut transmettre dans les 14 lignes d'un sonnet.
Eh bien, je suis un peu en retard à cette fête, comme d'habitude, mais c'est en fait intéressant. Au départ, je pensais comme la plupart que la question de l'exécutif était stupide. Cependant, j'ai lu la réponse de SK-logic et j'ai réalisé que c'est une question sensée posée de manière absurde. Ou, autrement dit, il y a un problème valable derrière la question.
Les gestionnaires doivent souvent essayer de déterminer la faisabilité, le financement, la dotation en personnel, etc. pour un projet. C'est un problème sensible. Pour un port de Straightford, une estimation basée sur des lignes de code de port divisées par la moyenne estimée des lignes de code par développeur et par jour est séduisante de simplicité, mais vouée à l'échec pour toutes les raisons données sur cette page.
Une approche plus sensée serait: -
- Pour une estimation sur place, demandez aux développeurs qui ont le plus d'expérience avec le code une estimation précise du temps qu'il faudra. Cela est forcément incorrect pour de nombreuses raisons que je n'entrerai pas ici, mais c'est le mieux qu'ils pourront faire au début. Au moins, ils devraient avoir une idée si ce sera facile à faire dans une semaine ou des années, même avec des ressources supplémentaires. S'il y a eu des ports de taille similaire ou des travaux effectués, ils pourraient l'utiliser comme guide.
- Estimez le port par composant pour obtenir un dimensionnement total. Les tâches qui ne sont pas directement liées au port doivent être incluses, telles que la configuration de l'infrastructure (machines, systèmes de construction, etc.), la recherche et l'achat de logiciels, etc.
- Identifiez les composants les plus risqués du port et commencez par ceux-ci en premier. Celles-ci sont susceptibles de faire exploser le plus l'estimation, donc devraient être faites à l'avance si possible afin qu'il y ait des surprises limitées tard dans le port.
- Gardez une trace de la progression par rapport au dimensionnement effectué à l'étape 2 pour calculer en permanence la durée prévue du port. À mesure que le projet avance, cela devrait devenir plus précis. Bien sûr, le nombre de lignes de code qui ont été portées (les fonctionnalités de la base de code d'origine qui sont maintenant dans le code porté) peuvent également être utilisées comme métrique et sont en fait utiles pour garantir que le produit d'origine est porté plutôt que un tas de nouvelles fonctionnalités intéressantes ajoutées sans aborder le port réel.
Ce sont les étapes nues, bien sûr, il existe de nombreuses autres activités autour de cela qui sont utiles, comme étudier les outils de portage et les cadres enfichables, créer des prototypes, déterminer ce qui doit vraiment être porté, réutiliser les outils et l'infrastructure de test, etc.