Gibt es bekannte gültige Verwendungen von SLOC zur Messung der Produktivität?

54

Ich hatte ein ungewöhnliches, kurzes Gespräch mit einem sehr erfahrenen Architekten über dynamische und statische Sprachen. Er sagte, dass Unternehmensdaten zeigen, dass es Beweise für eine höhere Produktivität gibt, wenn statische Sprachen verwendet werden. Beachten Sie, es ist ein großes Unternehmen mit langer Geschichte. Zu meiner (und anderen) Überraschung verwendete er als Metrik zusätzliche Codezeilen.

Er wies Einwände in Bezug auf die Metrik schnell zurück und sagte, dass innerhalb eines Unternehmens mit ähnlicher Kultur, Branche und mit genügend Daten Unterschiede (in Bezug auf einzigartige Situationen und Fähigkeiten von Einzelpersonen) genug verschmelzen, so dass die SLOC-Metrik für den Vergleich der Produktivität von nützlich ist Werkzeuge und Sprachen.

Obwohl ich nicht der Meinung bin, dass diese Behauptung durch rigorose statistische Analysen gestützt wird, gibt es in der Branche einige Beweise, die diese Denkweise stützen würden?

Sevo
quelle
25
Produktivität ist der falsche Begriff. Dieser Begriff ist definiert als die Menge an Arbeit, die in einem Zeitraum geleistet wurde, der nicht mit dem erzeugten Code zusammenhängt.
Frank Hileman
25
Eine weise Person sagte, wir sollten Codezeilen nicht als "gebaut", sondern als "ausgegeben" betrachten. Wenn wir die Anzahl der Teile und die Länge der Stückliste in Betracht ziehen, ist im physischen Ingenieurwesen kleiner besser.
pjc50
23
Der Vergleich verschiedener Sprachen (egal ob statisch oder dynamisch) widerspricht der Annahme "innerhalb eines Unternehmens mit einer ähnlichen Kultur und Branche": Die Unterschiede in den Sprachen machen SLOC-Vergleiche bedeutungslos.
Rob
4
Diese Methode ist tragisch fehlerhaft. Sogar zwei verschiedene Entwickler in demselben Unternehmen, die dieselbe Entwicklungsumgebung verwenden, produzieren häufig drastisch unterschiedliche SLOCs, um denselben Funktionsumfang zu implementieren.
17. vom 26.
8
Die Verwendung von SLOC zur Messung der Produktivität ist genauso sinnvoll wie die Verwendung von Schadstoffemissionen zur Messung der zurückgelegten Strecke, wenn Sie auf die Kraftstoffeffizienz achten sollten. Die Art und Weise, wie dies richtig ist, ist immer noch falsch. Verwenden Sie dies .
candied_orange

Antworten:

65

Das Argument des leitenden Architekten könnte zwei Dinge bedeuten.

  1. Dies kann bedeuten, dass ein durchschnittlicher Entwickler im Unternehmen bei Verwendung statischer Sprachen mehr Codezeilen erzeugt als bei Verwendung dynamischer Sprachen. Wenn beispielsweise fünfzehn Entwickler sechs Monate lang mit Java arbeiten, schreiben sie 100 KLOC, und wenn dieselben fünfzehn Entwickler sechs Monate lang mit Python arbeiten, schreiben sie nur 50 KLOC.

    Hier besteht keine Korrelation zwischen LOC und Produktivität. Was ist, wenn in Java viermal mehr Codezeilen erforderlich sind, um dasselbe Feature wie in Python zu erzeugen? Wenn dies zutrifft, würde die Verwendung von Python die doppelte Produktivität ergeben, basierend auf den oben genannten KLOC-Metriken.

  2. Er kann auch bedeuten, dass ein durchschnittlicher Entwickler im Unternehmen mit statischen Sprachen weniger Codezeilen erzeugt als mit dynamischen: Fünfzehn Entwickler würden in sechs Monaten 100 KLOC in Java oder 200 KLOC in Python schreiben.

    Während weniger Codezeilen normalerweise besser sind (weniger Code zum Schreiben, Lesen und Warten), ist immer noch unklar, wie viele Funktionen Java-Entwickler im Vergleich zu Python-Funktionen erstellt haben. Vielleicht haben sie im Vergleich zu Python-Entwicklern halbe Codezeilen geschrieben, aber auch die Hälfte der Features produziert?

In beiden Fällen ist LOC keine wertvolle Metrik, da dieselbe Funktion nicht in der gleichen Menge an Codezeilen in verschiedenen Sprachen übersetzt werden kann . Einige Sprachen sind in der Regel ausführlicher. andere - kompakter. In einigen Fällen ist Kompaktheit zwar wertvoll, es gibt jedoch keine allgemeine Regel dafür. Ein extremes Beispiel wäre die Brainfuck-Sprache, die extrem kompakt ist, aber wegen ihrer Lesbarkeit nicht beliebt ist. Das Vergleichen auch ähnlicher Sprachen kann schwierig sein: Beispielsweise folgt Java bei geschweiften Klammern dem K & R-Stil, während in C # die öffnende geschweifte Klammer in den meisten Fällen in einer eigenen Zeile steht, wenn dem offiziellen Stil gefolgt wird, was zu einer künstlichen Klammer führt Erhöhung der LOCs für C #. Und was passiert, wenn man eine prozedurale Sprache mit einer objektorientierten oder einer funktionalen Sprache vergleicht?

Anstatt eine fehleranfällige Metrik zu verwenden, kann sich der leitende Architekt auf eine Gruppe von Metriken verlassen, die die Produktivität messen, wenn sie zusammen verwendet werden: die Anzahl der pro Monat entwickelten Funktionen, die Anzahl der in die Codebasis eingeführten Fehler und die Zeit, die für die Behebung dieser Fehler aufgewendet wird , die Entwicklung der technischen Schulden usw. Dieser Vergleich könnte zu Beginn schwierig sein, da man die Unvertrautheit des Teams mit der neuen Sprache berücksichtigen muss. Sobald sich das Team ausreichend damit vertraut gemacht hat, sollte die Auswahl auf den stabilen Metriken sowie zum größten Teil auf den Vorlieben der Teammitglieder selbst basieren.

LOC hat in einigen engen Situationen einen Wert. Beispielsweise könnte es einen Hinweis auf die Größe des Projekts und von Teilen des Projekts geben (und im Durchschnitt mit Funktionspunkten korrelieren, obwohl es oft einfacher zu messen ist), oder es könnte die Methoden und Klassen angeben, die möglicherweise weitere Aufmerksamkeit erfordern, weil von ihrer großen Größe. LOC sollte jedoch mit Vorsicht angewendet werden, da es von Personen, die sich eine Korrelation zwischen nicht verwandten Dingen vorstellen, zu häufig missbraucht wird. Die menschlich katastrophalste Verwendung von LOCs war in der Vergangenheit der Versuch, die Produktivität eines einzelnen Entwicklers basierend auf den pro Monat erstellten LOCs zu messen.

Arseni Mourzenko
quelle
8
Jep. Die einzige Metrik, der ich vertraue, ist die Anzahl der Tickets (Features, Bugs, Recherchen usw.), die pro Zeiteinheit abgeschlossen wurden. Es variiert je nach Team (verschiedenes Team bricht Karten mit unterschiedlicher Granularität) , aber innerhalb der gleichen Mannschaft oder eine Gruppe von Teams eine Kultur entstehen , um das Ticket Größe ziemlich genau (solange Sie sie nicht von außerhalb dieser Kultur vergleichen) zu machen
Slebetman
10
Die Sache, die ich mehr mag: "Verlassen Sie sich nie nur auf eine Metrik"
Chococroc
30
@slebetman Ich bin eifersüchtig auf die Genauigkeit / Konsistenz der Person, die Ihre Tickets erstellt, aber ich muss Probleme lösen, die von "2 Wörter korrigieren" bis "Feature X hinzufügen" reichen. Die Metrik der Tickets ist für mich noch weniger nützlich als LOC. Die Reduzierung des Klassencodes um 20 LOC gibt mir zumindest eine Vorstellung von der geleisteten Arbeit. Das Auflösen von 5 Tickets kann eine Arbeitsstunde sein, aber auch eine Woche.
R. Schmitz
3
@ R.Schmitz Das ist bei mir auch so, aber mit jedem Ticket ist auch eine Größe verbunden, sodass das Summieren über Ticketgrößen funktionieren würde.
Nico Burns
1
Auch der Versuch, diese Metriken zu verwenden, hat Probleme. Was ist, wenn die hinzugefügten Funktionen komplex und schwer zu implementieren sind? Oder es kann sogar eine Situation sein, in der bestimmte Funktionen für eine Sprache besonders einfach oder schwierig zu implementieren sind, die Sprache jedoch im Allgemeinen einfacher / schwerer zu bearbeiten ist. Die mangelnde Produktivität kann auch darauf zurückzuführen sein, dass die derzeitigen Mitarbeiter zunächst keine Sprachkenntnisse haben. Man sollte sich nicht primär auf Metriken verlassen, um zu bestimmen, welche Sprache verwendet werden soll.
John Smith
26

Über Produktivität und SLOC

Das Problem mit SLOC

Das Problem mit der SLOC- Metrik ist, dass sie eine Annäherung an die Menge des geschriebenen Codes misst, ohne Folgendes zu berücksichtigen:

  • die Qualität des Codes (dh was ist, wenn Sie aufgrund von Fehlern für jeweils 100 SLOC weitere 90 SLOC hinzufügen müssen, aber im Moment, in dem Ihr Code ausgeliefert wird, nicht wissen, ob dies der Fall ist?)
  • die mit dem Code erreichten Ziele (dh behandelt der 10K SLOC alle erwarteten Use Cases oder User Stories? oder nur eine winzige Teilmenge?)
  • die Wartbarkeit des Codes (dh müssen Sie 1% oder 50% mehr Code hinzufügen, um den Code an die zu erwartenden sich ändernden Anforderungen anzupassen?).

Andernfalls wird die Produktion von fehleranfälligem, nicht wartbarem Spaghetti-Code mit vielen kopiert eingefügten Teilen als produktiver angesehen als sorgfältig entwickelter, wiederverwendbarer Code.

SLOC ist also definitiv nicht der beste Weg, um die Produktivität zu messen.

Welche Produktivität erwägen wir?

Die Produktivität wird für einen Prozess gemessen. Somit könnte SLOC ein perfekter Indikator für den Codierungsprozess sein.

Wenn Sie beispielsweise schlechte Anforderungen missverstehen, fünf Monate für die Erstellung der Software aufwenden, diese dem Benutzer zeigen, feststellen, dass sie völlig falsch ist, und weitere fünf Monate für das endgültige Neuschreiben der Software aufwenden, haben Sie die gleiche Produktivität in SLOC / Monat, dass ein Team den Code gleich beim ersten Mal schreibt, zum Beispiel weil es einen agilen Prozess verwendet, der Missverständnisse durch häufiges Feedback reduziert. Diese scheinbar gleiche Produktivität birgt große Probleme.

Um die Produktivität der Softwareentwicklung zu messen, muss der gesamte Prozess berücksichtigt werden, einschließlich der Analyse der Anforderungen, des Entwurfs von Code, des Codierens, Testens, Debuggens und der Überprüfung, ob die Erwartungen der Benutzer erfüllt werden. Da all diese Aktivitäten sehr unterschiedlich sind, ist es am besten, den einzigen entscheidenden Gedanken zu messen: funktionierende Software, dh was die erzeugte Software für den Benutzer bedeutet .

Wie messe ich Software-Ergebnisse?

Es gibt verschiedene Ansätze:

  • Der typische Ansatz in der klassischen Softwareentwicklung ist Function Points (FP). Funktionspunkte werden anhand der zu erfüllenden Anforderungen gemessen (z. B. Anzahl der Formulare, Anzahl der Felder in den einzelnen Formularen usw.). Die Produktivität wird dann in FP pro Zeiteinheit und pro Person gemessen. Einige Unternehmen haben sogar Daten, die angeben, wie viele Funktionspunkte ein Entwickler pro Zeiteinheit in einer bestimmten Sprache für eine bestimmte Domäne erzeugen kann. Das Problem bei FP ist, dass es sehr detaillierte Anforderungen im Voraus erfordert und zeitaufwendig ist.
  • Ein moderner und pragmatischer Ansatz ist Story Points (SP). Diese dienen zur Bewertung der Komplexität des zu erstellenden Codes und werden routinemäßig zur Bewertung der Geschwindigkeit von Entwicklungsteams verwendet. SP ist jedoch ein Schätzmaß für die geleistete Arbeit, bevor alle Details bekannt sind. Es ist kein endgültiges Maß dafür, was tatsächlich passiert ist. Daher muss bei der Verwendung als Produktivitätsmaß vorsichtig vorgegangen werden, da dies zu Fehlschlägen beim Schätzungsprozess führen kann .

Über die Produktivität des statischen und dynamischen Tippens

Ich muss gestehen, dass ich persönlich ein Fan von statisch getippten Sprachen bin, weil ich in meinem Inneren weiß, dass es zuverlässiger ist (jahrelange Codierung hat mir das bewiesen).

Ich gehe davon aus, dass statisch typisierte Sprachen beim Kompilieren wesentlich mehr Fehler / Bugs (z. B. Tippfehler, Nichtübereinstimmung der erwarteten Typen usw.) verhindern können als nicht statisch typisierte Sprachen. Aber bei aller Objektivität würde ich es nicht wagen, dies missbräuchlich als höhere Produktivität zu verallgemeinern.

Hat Ihr Architekt Recht?

Vielleicht, vielleicht nicht.

Seine Argumente scheinen jedoch nicht zu stimmen: Der Produktivitätsgewinn statisch typisierter Sprache beruht auf einer erheblichen Anzahl von Fehlern, die der Compiler im Voraus abfängt.

Infolgedessen ist es nicht möglich, diesen "höheren" Produktivitätsgewinn zu ermitteln, indem nur SLOC betrachtet wird, ohne die für dynamisch typisierte Sprachen erforderliche Überarbeitung zu berücksichtigen. Sein Vergleich kann also nicht fair sein.

Das Argument der vergleichbaren Umstände trifft auch nicht zu. Einige dynamisch typisierte Sprachen ermöglichen Konstruktionen höherer Ebenen, die weniger Code erfordern, als dies in einer der klassischen statisch typisierten Sprachen der Fall ist. Sie könnten also weniger Zeit benötigen, weniger Code schreiben, aber den gleichen Aufwand für Analyse, Test und Überprüfung aufwenden. Das Messen der Produktivität durch das SLOC würde also die potenziellen Produktivitätsgewinne verwässern und somit eine Tendenz gegenüber dynamisch getippter Sprache erzeugen.

Irgendeine Studie, die diese Behauptung stützt?

Zu diesem Thema existieren mehrere neuere akademische Studien. Obwohl einige von ihnen den Vorteil der statischen Typisierung sehen, ist sie im Allgemeinen auf einen bestimmten Zweck beschränkt (Dokumentation, Wiederverwendung von schlecht dokumentiertem Code oder API usw.). Vorsichtige Formulierungen werden auch verwendet, weil moderne IDE die mit dynamischer Typisierung verbundenen Risiken erheblich verringert hat:

Christophe
quelle
3
Ihre Kritikpunkte wurden bereits in der Frage angesprochen: „ Innerhalb eines Unternehmens mit einer ähnlichen Kultur, einem ähnlichen Geschäftszweig und mit genügend Daten vermischen sich die Unterschiede (in Bezug auf bestimmte Situationen und Fähigkeiten von Personen) so weit, dass die SLOC-Metrik nützlich ist. “ Das heißt, das Argument war, dass auf dieser Skala alle Codebasen von vergleichbarer Qualität wären. Ich persönlich bezweifle sehr, dass das stimmt.
amon
Wir verwenden gitprime ( gitprime.com ) für konkrete Messungen. Dabei wird unter anderem verfolgt, wie oft ein Entwickler dieselben Codezeilen neu schreibt. Wenn Sie also Code schreiben, einen Fehlerbericht abrufen und den Code neu schreiben, misst er tatsächlich Ihre Effizienz und meldet Ihre Nettoproduktivität. Kurz gesagt, ich glaube nicht, dass Ihre Kommentare Probleme mit der Verwendung von SLoC als Maß für die Produktivität darstellen. Ich denke eher, dass Ihre Beschwerden bei Systemen liegen, die SLoC nicht "richtig" messen.
Conor Mancone
8
@ConorMancone Niemand wird dafür bezahlt, Code zu schreiben. Sie werden dafür bezahlt, Lösungen zu entwickeln. Eine Analogie wäre, einen Schreiner daran zu messen, wie viele Nägel und Bretter er verbraucht. Ein Clown, der Bretter zu kurz schneidet und mehr Nägel biegt, als er nach Hause fährt, ist nach dieser Metrik produktiver als ein Tischlermeister.
JimmyJames
1
@Christophe Ich habe mit der Messung der Ergebnisse für die Produktion als Hauptkennzahl für die Produktivität experimentiert. Der einzige schwierige Teil ist, dass einige Dinge mehr Arbeit als andere sind, aber nach dem, was ich sagen kann, tendieren die Dinge im Laufe der Zeit zu einem ziemlich (statistisch) konsistenten Durchsatz, der auf der Größe und Zusammensetzung des Teams basiert. Natürlich steckt viel dahinter, Zuschreibung kann eine Herausforderung sein, aber sie ist der Anker für jede andere Messung der Entwicklungsproduktivität.
JimmyJames
2
Vor Jahren haben einige Leute in mindestens einer Programmierwerkstatt Logikdiagramme geschrieben und andere Leute haben diese Logikdiagramme in kompilierbaren Code umgewandelt. Im Wesentlichen hatte der Compiler dieses Shops menschliche Präprozessoren. Es wäre fair, SLoC / Monat zu verwenden, um die Produktivität eines dieser menschlichen Präprozessoren zu messen. Das entspricht der Anzahl der Schrauben, die ein Fließbandarbeiter in den Löchern anbringen kann, in die die Ingenieure gehen sollten. Der Ingenieur, der 100 Schrauben spezifiziert, wenn es um 15 geht, senkt die Produktivität des Unternehmens. (Ebenso, wenn sie 5 Schrauben angeben!)
David K
7

Hier ist ein Gegenbeispiel für Ihren leitenden Architekten: Angenommen, ich möchte eine Hierarchie von drei Klassen schreiben, von denen zwei von der dritten abgeleitet sind und einige von der Basisklasse definierte virtuelle Funktionen implementieren.

Wenn ich diese drei Klassen in C ++ schreibe, ist das ziemlich einfach. Ich erkläre die Klassen, verwende virtuell an den richtigen Stellen und mache das.

Wenn ich diese drei Klassen in C schreibe, muss ich einiges an Code hinzufügen: Ich muss structs für die v-Tabellen definieren, ich muss einen v-Tabellenzeiger zur Basisklasse hinzufügen, ich muss hinzufügen Ich muss den Konstruktoren Code hinzufügen, um die V-Table-Zeiger tatsächlich zu setzen. Ich muss den Konstruktoren Code hinzufügen, um den Basisklassenkonstruktor tatsächlich aufzurufen. Ich muss Code hinzufügen, um die Speicherzuweisung explizit durchzuführen, bevor ich einen Konstruktor aufrufe (was C ++ newin einem einzigen Schritt erledigt) ), ebenso muss ich die Zerstörung vom nachfolgenden free()Aufruf trennen und so weiter und so fort.

Der Punkt ist, all diese zusätzlichen Dinge sind ziemlich sinnlos. Ich kann sie sehr schnell machen. Ich brauche also nicht viel länger, um die C-Version zu schreiben, als um die C ++ - Version zu schreiben. Trotzdem habe ich viel mehr C-Code-Zeilen als C ++ - Code erzeugt. So sehr, dass ich in Bezug auf SLOCs in C anscheinend produktiver gewesen bin.

Jede Sprache, die eine bestimmte Menge an Code für das Boilerplate erfordert, erscheint in Bezug auf SLOCs produktiver als eine Sprache, die nicht die gleiche Menge an Code für das Boilerplate erfordert.

Sie sehen, das SLOC-Argument ist so grundlegend fehlerhaft, dass ich es genau umgekehrt sehen würde: Ich würde die Aussage "Programmierer tendieren dazu, mehr SLOCs in statischen Sprachen zu produzieren" als "statische Sprachen erfordern anscheinend mehr Kesselcode und damit die Produktivität reduzieren ".

cmaster
quelle
1
Ich mag deinen letzten Satz.
Peter - Setzen Sie Monica
1
"Statische Sprachen scheinen mehr Boilerplate-Code zu erfordern und somit die Produktivität zu verringern": Dies zeigt erneut, wie fehlerhaft die SLOC-Metrik ist. Die endgültige Anzahl der Zeilen berücksichtigt nicht (1), wie oft der Code neu geschrieben werden musste, bevor die endgültige Lösung erhalten wurde (2), wie viele zusätzliche Codezeilen in Form von Komponententests erforderlich sind (dynamisch typisierte Sprachen erfordern durchschnittlich mehr Komponententests, um ein vergleichbares Vertrauen in die Richtigkeit des Produktionscodes zu haben). Die SLOC-Metrik ist definitiv fehlerhaft.
Giorgio
6

Ich werde der Gegenspieler sein.

Wir verfolgen SLoC bei unserer Arbeit (obwohl wir es nicht direkt bei Personalentscheidungen verwenden), und ich habe Leute dazu gebracht, sich darüber zu streiten, was die meisten Leute in ihren Antworten sagen. Tatsächlich spielt "LoC keine Rolle, weil wir mit der X-Technologie mehr mit weniger Code erreichen können" oder "Bessere Entwickler schreiben besseren, kürzeren Code und schreiben daher nicht mehr als alle anderen". Nach meiner Erfahrung (obwohl ich keine festen Zahlen habe, um diese Dinge zu belegen) sind diese Einwände einfach nicht korrekt. In meiner Freizeit habe ich eine klare Korrelation zwischen der Geschwindigkeit und der Qualität der Code-Produktion für unsere Entwickler gesehen, verglichen mit allen anderen aussagekräftigen Messungen ihrer gesamten "Kompetenz" als Ingenieur. Um einige Gegenbeispiele zu den oben angeführten Argumenten zu geben:

  1. Ja, manche Sprachen können mit weniger Code mehr. Tatsächlich verfügen wir über ein vollständiges Framework, das große Teile der Entwicklung für unsere speziellen Geschäftsprobleme "automatisiert" (nur Back-End). Das Ergebnis all dessen ist nicht, dass die Leute weniger Code schreiben, sondern einfach, dass wir mehr Zeit haben, Code zu schreiben. Infolgedessen ist in unserem Unternehmen die Gesamtrate des Codeschreibens über Technologien hinweg ziemlich konstant und hängt in erster Linie vom Kompetenzniveau des Ingenieurs ab.
  2. Die Idee, dass ein besserer Entwickler weniger Code produziert, weil er schlauer schreibt, ist definitiv nicht wahr. Ja, ein besser gestaltetes Programm benötigt möglicherweise weniger Codezeilen. Ich persönlich habe jedoch festgestellt, dass die "besseren" Entwickler, die effizienteren Code schreiben, nicht länger brauchen, um ihn zu planen, als die jüngeren Entwickler, die den langen Weg zurücklegen. Infolgedessen werden die erfahreneren Entwickler ihre Codierungsaufgaben schneller erledigen und verschiedene Codes mit derselben hohen Rate schreiben.

Dieser letzte Teil ist meine Gesamtzusammenfassung, übrigens. Was ich festgestellt habe, ist, dass die meisten Entwickler unabhängig von der Technologie oder der Art des Projekts ihr eigenes Tempo haben, mit dem sie arbeiten. Wenn eine Sprache viele Funktionen enthält, die den Code der Entwickler effektiver machen, ist dies eine große Bereicherung für das Unternehmen. Dies bedeutet jedoch nicht, dass sie weniger Code schreiben. Stattdessen erledigen sie Funktionen schneller und wechseln schnell zu neuem Code. Das Endergebnis ist wiederum, dass die Rate, mit der sie codieren, in erster Linie von ihren Fähigkeiten und weniger von ihrem technischen Stack abhängt. Aus diesem Grund würde ich allgemein erwarten, dass der Tech-Stack mehr Einfluss auf die Rate hat, mit der Tickets und Features entwickelt werden, als auf die Rate, mit der Personencodes erstellt werden.

Trotzdem ist weder die Code-Writing-Rate noch die Ticket-Closing-Rate ein perfektes Maß für die Produktivität, weshalb wir Personalentscheidungen nicht direkt auf der Basis von SLoC treffen. Stattdessen ist es ein Teil des Prozesses, und die Bewertungen der Mitarbeiter werden unter Verwendung möglichst vieler Datenpunkte durchgeführt. Ich würde allerdings sagen, dass Ihr Architekt mit Sicherheit nicht verrückt ist.

Eine Ausnahme

Die einzige Ausnahme, der ich zustimme, ist die Möglichkeit des Kesselschildcodes. Wenn von einer Klasse (oder was auch immer) viel kopiert und eingefügt wird, um sie zum Laufen zu bringen, wird dies offensichtlich die Metriken verzerren. Dies gilt auch, wenn Sie über Tools verfügen, mit denen große Codemengen automatisch generiert werden können. Ich denke jedoch, dass dies oft eher die Ausnahme als die Regel ist. Wenn Ihre Entwickler einige Zeit damit verbringen, den Code der Kesselplatte zu kopieren, um loszulegen, verwenden Sie das falsche Tech-Set. Wenn sie den Code tatsächlich schreiben, auch wenn er sich ziemlich wiederholt, dann erwarte ich, dass dies die Messungen nur geringfügig verzerrt: Beim Schreiben von Code sind wir die meiste Zeit davon abhängig, wie schnell wir das Problem eher durchdenken können als wie schnell wir tippen können. Selbst wenn relativ sich wiederholender Code geschrieben wird,

Offensichtlich basiert alles oben auf meiner eigenen persönlichen Erfahrung. Ihre Laufleistung kann variieren, und ich bin offensichtlich in der Minderheit. Fühlen Sie sich frei zu widersprechen. Zusammenfassend jedoch:

Ich finde, dass die Codierungsrate mehr davon abhängt, wie schnell Sie Ihre Probleme durchdenken können, als von irgendetwas anderem. Infolgedessen habe ich festgestellt, dass die Codierungsrate mit nur wenigen möglichen Ausnahmen ein angemessenes Maß für die Produktivität ist, selbst über Tech-Sets hinweg.

Conor Mancone
quelle
4
Es gibt auch eine andere Ausnahme: die Fehlersuche. Die Fehlersuche nach besonders bösen Fehlern kann lange dauern, führt jedoch in der Regel zu einer einzigen Code-Änderung.
Nathan Merrill
@ NathanMerrill Das ist ein guter Punkt, auch wenn er für das OP weniger relevant ist: Debuggen ist in allen Sprachen möglich, und ich sehe keinen Grund, warum es von einem Techstack zum anderen wesentlich einfacher oder schwieriger sein würde. Abgesehen davon ist dies ein Grund, warum Sie die Produktivität im Großen und Ganzen nicht mehr ausschließlich anhand des geschriebenen Codes beurteilen können, als anhand einer anderen Metrik.
Conor Mancone
Wir verwenden gitprime ( gitprime.com ) in unserem Unternehmen und als Manager und Ingenieur denke ich, dass es das Beste auf der Welt ist. Auch hier ist es nur ein Teil des Bildes für uns, aber es war äußerst hilfreich, um potenzielle Probleme mit Ingenieuren zu identifizieren, lange bevor es ein tatsächliches Problem gab. Die Transparenz ist fantastisch und alles, was sie tun, läuft letztendlich auf SLoC hinaus. Angesichts des Mehrwerts und der damit verbundenen Einsichten bin ich immer sehr zweifelhaft, ob einige Ingenieure dazu neigen, SLoC aus der Hand zu legen. Jeder ist willkommen zu seiner Meinung, aber es funktioniert definitiv
Conor Mancone
Es stellt sich die Frage, ob LoC zum Vergleichen von Tools und Sprachen verwendet werden kann. Der Senior-Entwickler gibt an, dass es in "statischen" Sprachen eine höhere Produktivität aufweist. Sie scheinen eine andere Frage zu beantworten - LoC kann zum Vergleichen von Entwicklern verwendet werden, Sie stimmen jedoch zu, dass es nicht zum Vergleichen von Sprachen verwendet werden kann, da ein bestimmter Entwickler unabhängig von Tool / Sprache die gleiche Anzahl von LoCs schreibt? Sie sagen, dass Sie den anderen Antworten hier widersprechen, aber es scheint, dass Sie einer Meinung sind?
TessellatingHeckler
Als Entwickler fällt mir oft ein, dass ich einen Haufen nicht-DRY-Code genommen und durch einen kleinen Satz wiederverwendbarer Funktionen ersetzt habe. Ich habe dann eine erhebliche Menge an neuen Funktionen hinzugefügt. Das Reduzieren der Codemenge bei gleichzeitiger Steigerung des realen Werts ist in meinem Buch eine gute Sache. Nach meiner Erfahrung schreiben die besten Ingenieure die wenigsten Codezeilen und die schlechtesten die meisten.
JimmyJames
6

Obwohl ich auf den Zug springe. Ich denke, die Auswirkungen auf das Verhalten von Programmierern müssen hervorgehoben werden.

Die Verwendung von SLOC als Maß für die Produktivität wirkt sich toxisch auf die Moral der Programmierer aus. In dem Moment, in dem ein Ingenieur in Ihrem Team / Unternehmen merkt, dass er an SLOC gemessen wird, passieren mehrere Dinge:

  1. Sie beginnen, viel längeren Code zu schreiben, um dieselbe Funktion auszuführen
  2. Sie werden sich weniger um die Qualität ihres Codes kümmern
  3. Sie werden aufhören, andere Dinge zu tun, die Ihrem Team helfen (Rekrutieren, Debuggen, Junioren helfen).
  4. Sie werden ihre Arbeit hassen und wahrscheinlich gehen

Ich kann nicht genug betonen, wie ätzend es ist, die Moral zu entwickeln, da ich es zweimal bei 2 verschiedenen Firmen gesehen habe. Unabhängig von den scheinbar gültigen Anwendungsfällen, die Sie dafür haben, ist es meiner Meinung nach unwahrscheinlich, dass sich dies auf Ihr Team / Unternehmen auswirkt, selbst wenn nur eine geringe Chance besteht, dass seine Verwendung entdeckt wird. Auch wenn es in einigen Fällen eine Korrelation zwischen der Anzahl der geschriebenen Zeilen und der Anzahl der nützlichen Funktionen gibt, fördert dies alle falschen Verhaltensweisen in Ihren Programmierern und sendet die Nachricht, dass die Qualität nicht wichtig ist.

Nath
quelle
In der Tat ... jede Metrik, die jemanden davon abhält, redundanten Code zu entfernen ("Sie hatten diese Woche eine negative SLoC-Metrik!"), Ist falsch, einfach falsch!
Andrew
1

Dies wird im Allgemeinen nicht als gültige Methode zur Messung der Produktivität angesehen. Kleinerer Code ist normalerweise besser als größerer Code, sodass ein produktiverer Entwickler normalerweise weniger Code produziert. Die Produktivität wird beim Debuggen am stärksten beeinträchtigt. Effiziente Entwickler verbringen wenig Zeit mit dem Debuggen.

Statisch typisierte Sprachen sind produktiver (wenn Sie alle anderen Unterschiede zwischen den Sprachen berücksichtigen), da sie bei kluger Verwendung die Debugging-Zeit verkürzen und Fehler in der Kompilierungsphase erkennen, in der sie schneller behoben werden können.

Frank Hileman
quelle
1
Dies könnte ein wichtiger Punkt sein, wenn wir die Produktivität einzelner Entwickler vergleichen. Die Frage betrifft jedoch den Vergleich zwischen Sprachen, so dass der Kontext sehr unterschiedlich ist. Dies bedeutet beispielsweise auch, dass kleinerer Code nicht besser oder schlechter ist als größerer Code. Vergleichen Sie den in Brainfuck geschriebenen LOC-Code mit dem in Ruby geschriebenen Code.
Arseni Mourzenko
1
@ArseniMourzenko Abgesehen von Witzen wie Brainfuck werden gut gestaltete Sprachen anhand der zur Lösung einer Aufgabe erforderlichen Codemenge verglichen. Normalerweise nennt man einen solchen Vergleich Ausdruckskraft. Es ist jedoch wahr, dass ich über LOC in einer einzigen Sprache gesprochen habe, nicht über mehrere Sprachen hinweg. Produktivität ist im Allgemeinen definiert als die Zeit, die zur Ausführung einer Aufgabe benötigt wird. Das ist nicht spezifisch für die Programmierung.
Frank Hileman
0

Die einzige Metrik, mit der Sie die Produktivität von Entwicklern zwischen Sprachen vergleichen können, ist eine Metrik, die den Code zwischen den Sprachen nicht vergleicht. Einige Sprachen sind notorisch ausführlich (COBOL für den Legacy-Gewinn), und andere erfordern mehrere Schritte, um etwas zu tun, das Sie in einer Codezeile tun können (Assemblierung im Vergleich zu fast allem anderen). Auch wenn Sie nur aktive Codezeilen vergleichen (dh Deklarationen nicht zählen und nur Code, der eine Aktion enthält), können Sie Ihre Ergebnisse verzerren.

Möglicherweise können Sie ein Argument für Änderungsraten vorbringen. Dh Codezeilen hinzugefügt, die die Steigung der Produktivität über den gleichen Zeitraum vergleichen. Dies berücksichtigt jedoch keine negativen Änderungen in den Codezeilen. Beispielsweise erben Sie ein Projekt, das überall über Code zum Kopieren und Einfügen verfügt. Sie führen einige schnelle und einfache Refactorings durch, um die Anzahl der wiederholten Codeblöcke zu verringern - per Definition haben Sie eine negative Steigung.

Im Ernst, der Vergleich der Produktivität von Teams / Sprachen ist bedeutungslos, da es so viele zusätzliche Faktoren gibt, die sich auf die Produktivität eines Teams auswirken, dass Sie daraus keine aussagekräftigen Schlussfolgerungen ziehen können.

Ich habe an einem Projekt gearbeitet, bei dem die Infrastruktur sehr instabil und die Tools veraltet waren. Das Projekt wurde auf Java mit einer Single Page App erstellt, die darauf geklappt ist, aber in einem Portlet-Container ohne offensichtlichen Nutzen gehostet wird. Die Zeit, die für einfache Änderungen benötigt wurde, war lächerlich lang. Wenn Sie alle Ihre Schlussfolgerungen auf dieses bestimmte Projekt stützen, können Sie möglicherweise den Schluss ziehen, dass Java oder Single Page Apps fehlerhaft waren. Weder sind wahr. Das System, das das hässliche Projekt ersetzen sollte, wurde auf C # und WebForms aufgebaut. Als wir uns die Geschäftsidee machten, die vorhandene Anwendung zu erweitern, um die Kundenanforderungen zu erfüllen, stieg unsere Produktivität sprunghaft an. Bedeutet das, dass eine eng gekoppelte WebForms-App überlegen ist? Sie können diese Schlussfolgerung nur für diesen speziellen Fall ziehenund es erstreckt sich nicht auf die ganze Welt. Und es ist nur sinnvoll, weil es eine Anwendung gab, deren Laufzeit ausreicht, um sie zu erweitern.

Sogar das Vergleichen der Raten bei der Lösung von Problemen im Issue-Tracking-System ist fehlerhaft, da Sie komplette Projektinfrastrukturen miteinander vergleichen. Die verwendeten Bibliotheken und Frameworks können den Fortschritt beschleunigen oder verlangsamen. Sie befinden sich möglicherweise in der Startphase mit sehr wenig zu überwindendem Trägheitsmoment. Das Projekt, in dem Sie "besser als" sind, befindet sich in einer Wartungsphase, in der die Anzahl der neuen Tickets relativ gering ist. Es geht nie darum, solche Dinge zu vergleichen.

Berin Loritsch
quelle