Existe-t-il des utilisations valides connues du SLOC pour mesurer la productivité?

54

J'ai eu une conversation inhabituelle et brève avec un architecte de très haut niveau sur les langages dynamiques et statiques. Il a déclaré que les données des entreprises montrent qu'il existe des preuves d'une productivité accrue lorsque des langages statiques sont utilisés. Notez, c'est une grande entreprise avec une longue histoire. À ma grande surprise (et d'autres), la métrique qu'il a utilisée était l'ajout de lignes de code.

Il a rapidement écarté les objections concernant la métrique, affirmant qu'au sein d'une même entreprise, avec une culture, un secteur d'activité et des données suffisantes, les différences (en ce qui concerne les situations uniques et les capacités des individus) se confondaient suffisamment pour que la métrique SLOC soit utile pour comparer la productivité des entreprises. outils et langages.

Bien que je ne pense pas que cette affirmation soit étayée par une analyse statistique rigoureuse, existe-t-il des preuves dans le secteur qui seraient en faveur de cette ligne de pensée?

sevo
la source
25
La productivité n'est pas le bon terme. Ce terme est défini comme la quantité de travail accomplie dans une période de temps, qui n’est pas liée au code produit.
Frank Hileman
25
Une personne sage a déclaré que nous devrions considérer les lignes de code non pas comme "construites" mais comme "épuisées"; en ingénierie physique, lorsque l’on prend en compte le nombre de pièces et la longueur de la nomenclature, plus petit est mieux.
pjc50
23
La comparaison de langues différentes (qu’elles soient statiques ou dynamiques) annule l’hypothèse selon laquelle «au sein d’une même entreprise, avec une culture et un secteur d’activité similaires»: les différences entre les langues rendent les comparaisons entre SLOC vides de sens.
Rob
4
Cette méthode est tragiquement imparfaite. Même deux développeurs différents d'une même entreprise utilisant le même environnement de développement produisent souvent un SLOC radicalement différent pour implémenter le même jeu de fonctionnalités.
17 du 26
8
Utiliser le SLOC pour mesurer la productivité est tout aussi logique que d'utiliser la pollution émise pour mesurer la distance parcourue, alors que vous devez vous soucier de l'efficacité énergétique. Les façons dont cela est correct sont toujours erronées. Utilisez ceci .
candied_orange

Réponses:

65

L'argument de l'architecte principal pourrait signifier deux choses.

  1. Cela peut signifier qu'un développeur moyen de l'entreprise produit plus de lignes de code lors de l'utilisation de langages statiques que lors de l'utilisation de langages dynamiques. Par exemple, si quinze développeurs travaillent avec Java pendant six mois, ils écriront 100 KLOC et si ces mêmes quinze développeurs travaillent avec Python pendant six mois, ils n'écriront que 50 KLOC.

    Il n'y a pas de corrélation entre LOC et productivité ici. Et si il fallait quatre fois plus de lignes de code en Java pour produire la même fonctionnalité qu'en Python? Si cela est vrai, l'utilisation de Python entraînerait une productivité deux fois plus grande, en fonction des mesures KLOC ci-dessus.

  2. Il peut également signifier qu'un développeur moyen de l'entreprise produit moins de lignes de code lorsqu'il utilise des langages statiques que lorsqu'il utilise des langages dynamiques: quinze développeurs écriraient en six mois 100 KLOC en Java ou 200 KLOC en Python.

    Même si moins de lignes de code est généralement préférable (moins de code à écrire, à lire et à maintenir), il est encore difficile de savoir combien de fonctionnalités les développeurs Java ont produites par rapport à celles de Python. Peut-être ont-ils écrit des demi-lignes de code par rapport aux développeurs Python, mais ont également produit la moitié du nombre de fonctionnalités?

Dans les deux cas, LOC n'est pas une métrique précieuse, car une même fonctionnalité ne serait pas traduite dans le même nombre de lignes de code dans différentes langues . Certaines langues ont tendance à être plus verbeuses; d'autres, plus compacts. Bien que, dans certains cas, la compacité soit précieuse, il n’ya pas de règle générale pour cela. Un exemple extrême serait le langage Brainfuck qui est extrêmement compact, mais qui n’est pas populaire pour sa lisibilité. Comparer des langages similaires peut être délicat: par exemple, lorsqu'il s'agit d'accolades, Java suit le style K & R, tandis qu'en C #, l'accolade ouvrante est sur sa propre ligne dans la plupart des cas lorsqu'elle suit le style officiel, ce qui conduit à une augmentation des LDC pour C #. Et que se passe-t-il quand on compare un langage procédural avec un langage orienté objet ou avec un langage fonctionnel?

Au lieu d'utiliser une métrique sujette aux erreurs, l'architecte principal pourrait s'appuyer sur un groupe de métriques qui mesurent la productivité lorsqu'elles sont utilisées ensemble: le nombre de fonctionnalités développées par mois, le nombre de bogues introduits dans la base de code et le temps passé à résoudre ces bogues. , l’évolution de la dette technique, etc. Cette comparaison risque d’être délicate au début, car il faut tenir compte de la méconnaissance de l’équipe avec le nouveau langage. Une fois que l’équipe s’y familiarisera suffisamment, le choix devra être basé sur les métriques stables, ainsi que sur la préférence des membres de l’équipe eux-mêmes.

LOC a une valeur dans certaines situations étroites. Par exemple, cela pourrait donner un indice sur la taille du projet et des parties du projet (et correspond en moyenne à des points de fonction, tout en étant souvent plus facile à mesurer), ou pourrait indiquer les méthodes et les classes qui pourraient nécessiter une plus grande attention, de leur grande taille. Cependant, LOC doit être utilisé avec précaution, car il est trop souvent mal utilisé par les personnes qui imaginent une corrélation entre des choses non liées. L’utilisation la plus désastreuse des lettres de crédit était jadis la tentative de mesurer la productivité d’un développeur en fonction des lettres de crédit écrites chaque mois.

Arseni Mourzenko
la source
8
Ouaip. La seule mesure en laquelle j’ai confiance est le nombre de tickets (fonctionnalités, bugs, recherches, etc.) réalisés par unité de temps. Cela varie d'une équipe à l'autre (une équipe différente décompose les billets avec une granularité différente), mais au sein d'une même équipe ou d'un même groupe d'équipes, une culture émergera pour rendre la taille des billets assez précise (tant que vous ne les comparez pas en dehors de cette culture)
slebetman
10
La chose que j'aime le plus: "Ne comptez jamais sur une seule mesure"
Chococroc
30
@slebetman Je suis jaloux de la précision / cohérence de la personne qui crée vos billets, mais je dois résoudre des problèmes allant de "Correction de l'écriture de 2 mots" à "Ajouter une fonctionnalité X". La métrique de tickets m’est encore moins utile que LOC. Un code de classe réduit de 20 LOC au moins me donne une idée du travail effectué. Résoudre 5 tickets peut représenter une heure de travail, mais pourrait tout aussi bien être une semaine.
R. Schmitz
3
@ R.Schmitz C'est la même chose dans mon entreprise, mais chaque ticket a aussi une taille associée, donc la somme de la taille des tickets fonctionnerait.
Nico Burns
1
Même essayer d'utiliser ces métriques a des problèmes. Et si les fonctionnalités ajoutées sont complexes et difficiles à implémenter? Ou bien, il peut même s'agir d'une situation dans laquelle des fonctionnalités spécifiques sont particulièrement faciles ou difficiles à implémenter pour un langage, mais en général, le langage est plus facile / difficile à utiliser. Le manque de productivité peut également être dû au fait que les employés actuels ne sont pas familiarisés avec une langue au début. Il ne faut surtout pas se fier aux métriques pour déterminer quelle langue utiliser.
John Smith
26

A propos de la productivité et du SLOC

Le problème avec le SLOC

Le problème avec la métrique SLOC est qu’elle mesure une approximation de la quantité de code écrite, sans prendre en compte:

  • la qualité du code (c'est-à-dire si, pour 100 SLOC, vous devez en ajouter 90 de plus à cause de bugs, mais que vous ne savez pas pour le moment que votre code est livré?)
  • les objectifs atteints avec le code (par exemple, le SLK 10K gère-t-il tous les cas d'utilisation ou histoires d'utilisateurs attendus? ou seulement un sous-ensemble minuscule?)
  • la maintenabilité du code (c.-à-d. devrez-vous ajouter 1% ou 50% de code supplémentaire pour adapter le code aux exigences évolutives attendues?).

Autrement dit, la production de code spaghetti incertain et incontrôlable avec de nombreuses pièces copiées-collées sera considérée comme plus productive que le code réutilisable élaboré avec soin.

Le SLOC n’est donc définitivement pas le meilleur moyen de mesurer la productivité.

Quelle productivité envisageons-nous?

La productivité est mesurée pour un processus. Le SLOC pourrait donc être un indicateur parfaitement valable pour le processus de codage seul.

Si, par exemple, vous comprenez mal les exigences peu élevées, passez cinq mois à produire le logiciel, montrez-le à l'utilisateur, découvrez qu'il est tout à fait faux et passez encore cinq mois à le réécrire pour de bon, vous obtiendrez la même productivité dans SLOC. / mois, qu’une équipe écrivant le code correctement dès la première fois, par exemple parce qu’elle a utilisé un processus agile qui réduit les malentendus grâce à des retours fréquents. Cette productivité apparente égale cache d’énormes problèmes.

Ainsi, la productivité du développement logiciel doit prendre en compte l’ensemble du processus, y compris l’analyse des exigences, la conception des éléments à coder, le codage, les tests, le débogage et la vérification du respect des attentes de l’utilisateur. Comme toutes ces activités sont très différentes, la meilleure chose à faire est de mesurer le seul facteur qui compte: un logiciel fonctionnel, c’est-à-dire ce que le logiciel produit signifie pour l’utilisateur .

Comment mesurer les livrables logiciels?

Plusieurs approches existent:

  • L'approche typique en génie logiciel classique est la fonction des points de fonction (FP). Les points de fonction sont mesurés en fonction des exigences à remplir (nombre de formulaires, nombre de champs dans chaque formulaire, etc.). La productivité est ensuite mesurée en PF par unité de temps et par personne. Certaines entreprises disposent même de données indiquant le nombre de points de fonction qu'un développeur peut produire par unité de temps dans une langue donnée pour un domaine donné. Le problème avec la PF est qu’elle nécessite d’abord des exigences très détaillées et prend beaucoup de temps.
  • Une approche plus moderne et pragmatique est Story Point (SP). Ceux-ci sont utilisés pour évaluer la complexité du code à produire et sont couramment utilisés pour évaluer la vitesse des équipes de développement. Cependant, SP est une mesure d'estimation du travail effectué avant que tous les détails ne soient connus. Ce n'est pas une mesure finale de ce qui s'est réellement passé. Il faut donc faire preuve de prudence lors de son utilisation en tant que mesure de la productivité, car cela pourrait se retourner contre le processus d’estimation .

À propos de la productivité du typage statique et dynamique

Je dois avouer que je suis personnellement un fan des langages à typage statique, car je sais au fond de moi que c'est plus fiable (des années de codage m'ont prouvé cela).

Donc, une chose que je suis sûr de faire est que le langage à typage statique est capable d’éviter beaucoup plus d’erreurs / bogues au moment de la compilation (par exemple, des fautes de frappe, des différences dans les types attendus, etc.) par rapport aux langages à typage non statique. Mais en toute objectivité, je n'oserais pas généraliser abusivement ceci comme une productivité plus élevée.

Votre architecte a-t-il raison?

Peut-être peut-être pas.

Mais ses arguments ne semblent pas valables: le gain de productivité d’un langage à typage statique provient d’un nombre important d’erreurs que le compilateur a rattrapées d’emblée.

Par conséquent, il n'est pas possible de découvrir ce gain de productivité "plus élevé" en examinant uniquement le SLOC sans examiner les retouches nécessaires pour les langages à typage dynamique. Donc, sa comparaison ne peut pas être juste.

L'argument des circonstances comparables ne tient pas non plus. Certains langages à typage dynamique autorisent certaines constructions de niveau supérieur nécessitant moins de code que la même chose dans l’un des langages classiques à typage statique. Vous pourriez donc avoir besoin de moins de temps, écrire moins de code, mais ajouter les mêmes coûts d'analyse, de test et de vérification. Donc, mesurer la productivité par le SLOC diluerait les gains de productivité potentiels, créant ainsi un biais contre un langage typé dynamiquement.

Toute étude pour soutenir cette revendication?

Plusieurs études académiques récentes existent sur le sujet. Bien que certains d’entre eux voient un avantage au typage statique, celui-ci est généralement limité à un objectif spécifique (documentation, réutilisation de code ou d’API mal documenté, etc.). Une formulation prudente est également utilisée car les IDE modernes ont considérablement réduit les risques liés au typage dynamique:

Christophe
la source
3
Vos points de critique ont déjà été abordés dans la question: « au sein d’une même entreprise, avec une culture, un secteur d’activité et avec suffisamment de données, les différences (quant aux situations uniques et aux capacités des individus) se mélangent suffisamment pour que la métrique SLOC soit utile ». L'argument était qu'à cette échelle, toutes les bases de code seraient de qualité comparable. Personnellement, je doute fortement que ce soit le cas.
amon
Nous utilisons gitprime ( gitprime.com ) pour des mesures concrètes. L’une des choses qu'il fait est de suivre le nombre de fois qu'un développeur réécrit les mêmes lignes de code. Ainsi, si vous écrivez du code, obtenez un rapport de bogue et réécrivez le code, il mesure votre efficacité et indique votre productivité nette. En bref, je ne pense pas que vos commentaires soient un problème inhérent à l’utilisation de SLoC comme mesure de la productivité. Je pense plutôt que vos plaintes concernent des systèmes qui ne mesurent pas SLoC "correctement".
Conor Mancone
8
@ConorMancone Personne n'est payé pour écrire du code. Ils sont payés pour créer des solutions. Une analogie serait de mesurer un charpentier par le nombre de clous et de planches qu'il utilise. Un clown qui coupe les planches trop courtes et plie plus de clous qu’il ramène chez lui sera plus productif que le maître charpentier de cette métrique.
JimmyJames
1
@ Christophe J'ai essayé de mesurer les produits livrables à la production en tant que principal indicateur de productivité. Le seul inconvénient est que certaines choses peuvent nécessiter plus de travail que d’autres, mais, d’après ce que je peux en dire, au fil du temps, les choses tendent vers un débit assez (statistiquement) cohérent, basé sur la taille et la composition de l’équipe. Bien sûr, beaucoup de choses vont dans ce sens, alors l'attribution peut être un défi mais c'est le point d'ancrage de toute autre mesure de la productivité du développement.
JimmyJames
2
Il y a des années, dans au moins un magasin de programmation, certaines personnes ont écrit des diagrammes logiques et d'autres ont converti ces diagrammes logiques en code compilable. Le compilateur de ce magasin avait essentiellement des pré-processeurs humains. Il serait juste d'utiliser SLoC / month pour mesurer la productivité de l'un de ces préprocesseurs humains; c'est analogue au nombre de vis qu'un ouvrier à la chaîne peut installer dans les trous où les ingénieurs ont dit qu'ils devraient aller. L'ingénieur qui spécifie 100 vis alors que 15 sont nécessaires pour le poste réduit la productivité de l'entreprise. (De même s'ils spécifient 5 vis!)
David K
7

Voici un contre-exemple pour votre architecte principal: Supposons que je veuille écrire une hiérarchie de trois classes, dont deux dérivent de la troisième, implémentant certaines fonctions virtuelles définies par la classe de base.

Si j'écris ces trois classes en C ++, c'est assez simple. Je déclare les classes, utilise virtuel aux bons endroits, et je le fais.

Si j'écris ces trois classes en C, je devrai ajouter un peu de code: je dois définir structs pour les v-tables, je dois ajouter un pointeur de v-table à la classe de base, je dois ajouter Code aux constructeurs pour définir réellement les pointeurs v-table, je dois ajouter du code aux constructeurs pour appeler en réalité le constructeur de la classe de base, je dois ajouter du code pour effectuer une allocation de mémoire de manière explicite avant d'appeler un constructeur (ce que C ++ newfait en une seule étape ), de même, je dois séparer la destruction de l' free()appel suivant, etc., etc.

Le fait est que toutes ces choses supplémentaires sont plutôt stupides. Je peux les faire très vite. Donc, l'écriture de la version C ne prendra pas beaucoup plus de temps que celle dont j'ai besoin pour écrire la version C ++. Néanmoins, j'ai produit beaucoup plus de lignes de code C que de code C ++. À tel point que je semblerais avoir été plus productif en C en termes de SLOC.

Toute langue nécessitant une certaine quantité de code passe-partout apparaîtra plus productive en termes de SLOC qu'une langue ne nécessitant pas la même quantité de code passe-partout.

Vous voyez, l'argument du SLOC est tellement fondamentalement imparfait que je le verrais en fait l'inverse: je prendrais l'énoncé suivant: "les programmeurs ont tendance à produire plus de SLOC dans des langages statiques": "les langages statiques semblent exiger davantage code passe-partout, et donc réduire la productivité ".

cmaster
la source
1
J'aime ta dernière phrase.
Peter - Réintégrez Monica
1
"Les langages statiques semblent nécessiter plus de code passe-partout et donc réduire la productivité": cela montre à nouveau à quel point la métrique SLOC est défectueuse. Le nombre final de lignes ne prend pas en compte (1) le nombre de fois que l’on a besoin de réécrire le code avant d’obtenir la solution finale (2) le nombre de lignes de code supplémentaires nécessaires sous forme de tests unitaires tests unitaires pour avoir une confiance comparable dans l'exactitude du code de production). La métrique SLOC est définitivement imparfaite.
Giorgio
6

Je serai le contrarian.

Nous suivons SLoC dans notre travail (bien que nous ne l'utilisions pas directement dans les décisions de dotation), et des personnes ont déjà contesté ce que la plupart des gens ont dit dans leurs réponses. En effet, "La LoC n'a pas d'importance parce que la technologie X nous permet de faire plus avec moins de code" ou "Les meilleurs développeurs écrivent un code plus court et de meilleure qualité, de sorte qu'ils n'écrivent pas plus que quiconque". D'après mon expérience (même si je n'ai pas de chiffres précis à l'appui), ces objections ne sont tout simplement pas correctes. À mon époque, nous avons constaté une nette corrélation entre le taux et la qualité de la production de code pour nos développeurs, par rapport à toutes les autres mesures significatives de leur "compétence" globale en tant qu'ingénieur. Pour donner quelques contre-exemples aux sortes d'arguments avancés ci-dessus:

  1. Oui, certaines langues peuvent faire plus avec moins de code. En fait, nous avons construit un cadre complet qui "automatise" de grandes parties du développement pour nos problèmes métier particuliers (back-end uniquement). Le résultat de tout cela n'est pas que les gens écrivent moins de code, mais simplement que nous avons plus de temps pour écrire du code. En conséquence, dans notre entreprise, le taux global d’écriture de code est relativement constant d’une technologie à l’autre et dépend principalement du niveau de compétence de l’ingénieur.
  2. L'idée selon laquelle un meilleur développeur produira moins de code parce qu'il écrit plus intelligemment n'est absolument pas vraie. Oui, un programme mieux conçu peut prendre moins de lignes de code. Cependant, j’ai personnellement constaté que les «meilleurs» développeurs écrivant du code plus efficace ne tardent pas à le planifier plus rapidement qu’un développeur plus junior qui écrit sur le long terme. En conséquence, les développeurs les plus expérimentés exécuteront leurs tâches de codage plus rapidement et écriront un code différent avec le même taux élevé.

Cette dernière partie est mon résumé général, BTW. Ce que j’ai constaté, c’est que, quels que soient la technologie et le type de projet, la plupart des développeurs ont leur propre rythme, qui est celui auquel ils opèrent. Si un langage comporte de nombreuses fonctionnalités qui rendent le code plus efficace pour les développeurs, cela représente un avantage considérable pour les entreprises, mais cela ne signifie pas qu'elles rédigeront moins de code. Au lieu de cela, ils obtiennent des fonctionnalités plus rapidement et passent rapidement au nouveau code. Là encore, le résultat final est qu’ils évaluent le code auquel ils codent dépend principalement de leurs compétences et moins de leur pile technologique. En fait, à cause de cela, je m'attendrais généralement à ce que la pile technologique fasse plus de différence en ce qui concerne le taux de développement des billets et des fonctionnalités que celui des codes.

Cela étant dit, ni le taux de rédaction des codes ni le taux de clôture des tickets ne constituent une mesure parfaite de la productivité. C'est pourquoi nous ne prenons pas directement de décisions de dotation sur la base de SLoC. Au lieu de cela, cela fait partie du processus et les évaluations des employés sont effectuées en utilisant autant de points de données que possible. Je dirais cependant que votre architecte n'est certainement pas fou.

Une exception

La seule exception avec laquelle je suis d’accord est la possibilité d’un code de plaque chauffante S'il y a beaucoup de copier-coller d'une classe (ou autre) à une autre pour la rendre opérationnelle, cela va évidemment fausser les métriques. Cela est également vrai si vous avez des outils capables de générer automatiquement de grandes quantités de code pour vous. Cependant, je pense que ce sera souvent l'exception plutôt que la règle. Si vos développeurs passent du temps à copier le code de la plaque de chaudière pour commencer, vous utilisez le mauvais ensemble de technologies. S'ils écrivent le code, même s'il est assez répétitif, je m'attends à ce que cela ne biaise que peu les mesures: lors de l'écriture du code, nous sommes généralement limités par la rapidité avec laquelle nous pouvons résoudre le problème. que la vitesse à laquelle nous pouvons taper. Même en écrivant du code relativement répétitif,

Évidemment, tout ce qui précède est basé sur ma propre expérience personnelle. Votre kilométrage peut varier et je suis évidemment minoritaire. N'hésitez pas à être en désaccord. En résumé cependant:

Je trouve que le taux de codage dépend plus de la rapidité avec laquelle vous pouvez résoudre vos problèmes, plus que d’autre chose. En conséquence, j’ai constaté que le taux de codage est une mesure décente de la productivité, même dans l’ensemble des technologies, à quelques exceptions près.

Conor Mancone
la source
4
Il y a aussi une autre exception: la chasse aux bogues. La recherche de bogues particulièrement dangereux peut prendre beaucoup de temps, mais entraîne généralement une seule ligne de modification du code.
Nathan Merrill
@NathanMerrill C'est un bon point pour, bien que cela soit moins pertinent pour l'OP: le débogage est un débogage dans toutes les langues et (par coeur), je ne vois aucune raison pour laquelle ce serait beaucoup plus facile ou plus difficile d'un paquet technologique à l'autre. Cela dit, c’est une raison pour laquelle, dans l’ensemble, vous ne pouvez pas juger de la productivité exclusivement sur le code écrit, pas plus que sur toute autre mesure.
Conor Mancone
Nous utilisons gitprime ( gitprime.com ) dans notre société et, en tant que gestionnaire et ingénieur, je pense que c'est la meilleure chose au monde. Encore une fois, cela ne représente qu’une partie de la situation, mais c’est extrêmement utile pour identifier les problèmes potentiels des ingénieurs bien avant qu’il ne se pose réellement. La transparence est impressionnante et tout ce qu'ils font revient finalement à SLoC. Compte tenu de la valeur ajoutée et de la perspicacité que cela ajoute, je suis toujours très sceptique quant à la tendance de certains ingénieurs à rejeter SLoC. Tout le monde est le bienvenu, mais ça marche
Conor Mancone
La question est de savoir si la LoC peut être utilisée pour comparer des outils et des langages, dans le contexte du développeur senior, affirmant que cela montre une productivité plus élevée dans les langages "statiques". Vous semblez répondre à une question différente - La LoC peut être utilisée pour comparer des développeurs, mais vous acceptez néanmoins de ne pas l'utiliser pour comparer des langues, car un développeur donné écrit le même nombre de LoC, quel que soit l'outil / le langage? Vous dites que vous êtes contre les autres réponses ici, mais il semble que vous êtes d'accord?
TessellatingHeckler
En tant que développeur, je peux penser à de nombreuses fois, j'ai pris un tas de code non-DRY et l'ai remplacé par un petit ensemble de fonctionnalités réutilisables. J'ai ensuite ajouté une quantité importante de nouvelles fonctionnalités. Réduire la quantité de code tout en ajoutant un multiple de valeur réelle est une bonne chose dans mon livre. D'après mon expérience, les meilleurs ingénieurs écrivent le moins de lignes de code et les pires écrivent le plus.
JimmyJames
6

Bien que je saute dans le train en marche. Je pense que l'impact sur le comportement des programmeurs doit être souligné.

L'utilisation du SLOC comme mesure de la productivité a un effet toxique sur le moral du programmeur. Au moment où un ingénieur de votre équipe / entreprise réalise qu'il est mesuré sur le SLOC, plusieurs choses se passent:

  1. Ils commencent à écrire du code beaucoup plus long pour faire la même chose
  2. ils se soucient moins de la qualité de leur code
  3. ils cesseront de faire d'autres choses qui aident votre équipe (recrutement, débogage, aide aux juniors)
  4. ils détesteront leur travail et partiront probablement

Je ne saurais trop insister sur le fait que le moral du personnel est corrosif, comme je l'ai déjà vu se produire deux fois dans deux entreprises différentes. Quels que soient vos cas d'utilisation apparemment valables, je soutiens qu'il est peu probable que l'impact sur votre équipe / votre entreprise en vaille la peine, même s'il n'y a que très peu de chances que son utilisation soit découverte. Même s'il existe dans certains cas une corrélation entre le nombre de lignes écrites et le nombre de fonctionnalités utiles, cela encourage tous les mauvais comportements de vos programmeurs et envoie le message que la qualité n'est pas importante.

Nath
la source
En effet ... toute métrique qui dissuade quelqu'un de supprimer le code redondant ("vous avez eu une métrique SLoC négative cette semaine!" Est fausse, c'est tout à fait fausse!
Andrew,
1

Ce n'est généralement pas considéré comme un moyen valable de mesurer la productivité. Un code plus petit est généralement préférable à un code plus volumineux. Ainsi, un développeur plus productif produit généralement moins de code. La productivité prend son plus grand succès en débogage; Les développeurs efficaces passent peu de temps à déboguer.

Les langages statiquement typés sont plus productifs (si vous contrôlez toutes les autres différences entre les langages), car utilisés judicieusement, ils réduisent le temps de débogage, en rattrapant les erreurs en phase de compilation, où elles sont plus rapides à corriger.

Frank Hileman
la source
1
Cela pourrait être un point valable si nous comparions la productivité de développeurs individuels. La question concerne toutefois la comparaison entre les langues, le contexte est donc très différent. Cela signifie également, par exemple, qu'un code plus petit n'est pas meilleur ou pire qu'un code plus volumineux; comparez LOC du code écrit en Brainfuck avec le code écrit en Ruby, par exemple.
Arseni Mourzenko
1
@ArseniMourzenko Hormis les blagues comme Brainfuck, les langages bien conçus sont comparés sur la base de la quantité de code nécessaire pour résoudre une tâche. Habituellement, une telle comparaison est appelée expressivité. C’est vrai, j’ai parlé de la LOC dans une seule langue, et non pas entre les langues. La productivité est généralement définie comme le temps nécessaire à l'exécution d'une tâche. ce n'est pas spécifique à la programmation.
Frank Hileman
0

La seule mesure que vous pouvez utiliser pour comparer la productivité des développeurs entre les langues est une mesure qui ne compare pas le code entre les langues. Certaines langues sont notoirement verbeuses (COBOL pour la victoire héritée), et d'autres nécessitent plusieurs étapes pour faire quelque chose que vous pouvez faire dans une seule ligne de code (assembleur par rapport à à peu près tout le reste). Même si vous ne comparez que les lignes de code actives (en d'autres termes, ne comptez pas les déclarations et ne comptez que le code comportant des actions), vous pouvez toujours biaiser vos résultats.

Vous pourrez peut-être faire valoir un argument en faveur des taux de changement. C'est-à-dire des lignes de code ajoutées, comparant la pente de productivité sur la même période. Toutefois, cela ne prend pas en compte les modifications négatives des lignes de code. Par exemple, vous héritez d'un projet comportant un copier-coller de code partout. Vous effectuez quelques refactorisations rapides et faciles pour réduire le nombre de blocs de code répétés - par définition, vous avez une pente négative.

Plus sérieusement, comparer la productivité des équipes / des langues n'a pas de sens, car de nombreux facteurs supplémentaires affectant la productivité d'une équipe ne permettent pas de tirer des conclusions significatives.

J'ai travaillé sur un projet où l'infrastructure était très fragile et les outils obsolètes. Le projet a été construit sur Java avec une application de page unique, mais hébergé dans un conteneur de portlets sans aucun avantage apparent. Le temps qu'il a fallu pour effectuer des changements, même simples, était ridiculement long. Si vous basiez toutes vos conclusions sur ce projet particulier, vous pourriez en conclure que Java était mauvais ou que les applications à une seule page étaient mauvaises. Ni sont vrais. Le système que le vilain projet était censé remplacer a été construit sur C # et WebForms. Lorsque nous avons analysé la rentabilité de l'extension de l'application existante pour répondre aux besoins des clients, notre productivité a explosé. Cela signifie-t-il qu'une application WebForms étroitement couplée est supérieure? Vous ne pouvez tirer cette conclusion que dans ce cas particulieret cela ne s'étend pas au monde entier. Et cela n'a de sens que parce qu'il y avait une application existante avec une maturité suffisante pour s'étendre.

Même comparer les taux de résolution des problèmes dans le système de suivi des problèmes est erroné, en ce sens que vous comparez des infrastructures de projet complètes les unes aux autres. Les bibliothèques et les cadres utilisés peuvent soit accélérer, soit ralentir les progrès. Vous êtes peut-être en phase de démarrage avec très peu d'inertie à surmonter, alors que le projet pour lequel vous êtes "meilleur que" se trouve dans une phase de maintenance où le nombre de nouveaux tickets est relativement faible. Il ne s'agit jamais de comparer des choses semblables.

Berin Loritsch
la source