it-swarm-eu.dev

Wie viele Codezeilen kann ein C # -Entwickler pro Monat produzieren?

Eine Führungskraft an meinem Arbeitsplatz stellte mir und meiner Gruppe von Entwicklern die Frage:

Wie viele Codezeilen kann ein C # -Entwickler pro Monat produzieren?

Ein altes System sollte nach C # portiert werden, und er möchte diese Maßnahme als Teil der Projektplanung.

Aus einer (anscheinend glaubwürdigen) Quelle hatte er die Antwort "10 SLOC/Monat", aber er war damit nicht zufrieden.

Die Gruppe stimmte zu, dass dies nahezu unmöglich zu spezifizieren sei, da dies von einer langen Liste von Umständen abhängen würde. Aber wir konnten sagen, dass der Mann nicht gehen würde (oder sehr enttäuscht von uns sein würde), wenn wir keine Antwort finden würden, die besser zu ihm passt. Also ging er mit der um ein Vielfaches besseren Antwort von "10 SLOC/Tag"

Kann diese Frage beantwortet werden? (spontan oder sogar mit einer Analyse)

21
lox

Fragen Sie Ihre Führungskraft, wie viele Vertragsseiten sein Anwalt pro Monat schreiben kann. Dann wird er (hoffentlich) feststellen, dass es einen großen Unterschied zwischen dem Schreiben eines einseitigen Vertrags und dem Schreiben eines 300-seitigen Vertrags ohne Lücken und Widersprüche gibt. Oder zwischen dem Schreiben eines neuen Vertrags und dem Ändern eines bestehenden. Oder zwischen dem Schreiben eines neuen Vertrags und dem Übersetzen in eine andere Sprache. Oder zu einem anderen Rechtssystem. Vielleicht stimmt er sogar zu, dass "Vertragsseiten pro Zeiteinheit" kein sehr gutes Maß für die Produktivität von Anwälten sind.

Aber um Ihnen einige Antwort auf Ihre eigentliche Frage zu geben: Nach meiner Erfahrung sind für ein neues Projekt ein paar hundert SLOC pro Tag und Entwickler keine Seltenheit. Sobald jedoch die ersten Fehler auftreten, sinkt diese Zahl stark.

84
nikie

Wie viele Codezeilen kann ein C # -Entwickler pro Monat produzieren?

Wenn sie gut sind, weniger als Null.

33
quentin-starin

Lauf in die andere Richtung ... Jetzt.

LoC ist eine der schlechtesten Metriken, die Sie verwenden können.

Schlechte Entwickler können möglicherweise mehr LoC pro Tag schreiben als gute Entwickler, produzieren aber Müllcode.

Abhängig von der Komplexität des Codes kann die Portierung durch Automatisierungsprozesse erfolgen, die zu mehr als tausend LoC-Änderungen pro Tag führen würden, während schwierigere Abschnitte, in denen die Sprachkonstrukte stark unterschiedliche Codes enthalten, mit 100LoC pro Tag portiert werden.

Senden Sie ihn, um die Wikipedia-Seite auf SLOC zu lesen. If gibt einige nette und einfache Beispiele dafür, warum es so eine schlechte Metrik ist.

21
Dan McGrath

Die richtige Antwort: Nein ...

Diese Führungskraft sollte darüber informiert werden, dass SLOC keine gültige Metrik für den Analysefortschritt ist

Die schlampige Antwort: Jede Zahl, aus der Sie bestehen können.

Geben Sie ihm einfach eine Nummer, Sie und Ihr Team können diese Nummer trotzdem leicht erfinden. (Indem Sie nur Zeilen, Leerzeilen, Kommentare usw. usw. einfügen, um diesem Kerl zu ermöglichen, weiterhin in seiner Fantasiewelt zu leben, ein weiteres Team zu verfolgen und den elendverstärkten Zyklus fortzusetzen, der dem Alltag eine Geschichte macht.

Nicht schön, aber machbar.

18
Zekta Chan

Auf den ersten Blick sieht diese Frage absolut dumm aus, und alle hier haben nur auf den dummen C # LoC-Teil geantwortet. Aber es gibt eine wichtige Nuance - es ist eine Frage zu einer Portierung Leistung. Der richtige Weg, um diese Frage zu stellen, besteht darin, zu fragen, wie viele Codezeilen des Quellprojekts (die portierte) ein Entwickler innerhalb einer bestimmten Zeiteinheit verarbeiten kann. Dies ist eine durchaus berechtigte Frage, da die Gesamtzahl der Codezeilen bekannt ist und genau der Arbeitsaufwand zu erledigen ist. Der richtige Weg, um diese Frage zu beantworten, besteht darin, ein paar historische Daten zu sammeln - arbeiten Sie beispielsweise eine Woche lang und messen Sie die Leistung jedes Entwicklers.

10
SK-logic

Ich habe nur eins zu sagen:

"Das Messen des Programmierfortschritts anhand von Codezeilen ist wie das Messen des Fortschritts beim Flugzeugbau nach Gewicht."

-- Bill Gates

Danach können Sie argumentieren, dass Bill Gates nicht wusste, wie man erfolgreiche Software macht;)

Hinweis: SLOC ist jedoch ein sehr gutes Maß für die Komplexität der Codebasis!

7
Matthieu M.
I 
can
write
large
numbers
of
lines
of
code
per
month.

Proportional zur Anzahl der Wörter.

Siehst du meinen Punkt?

5
JBRWilkinson

Es ist im Allgemeinen eine schlechte Idee, Ihren Chef als Idioten zu bezeichnen. Meine Vorschläge beginnen daher damit, Metriken zu verstehen und zu diskutieren, anstatt sie abzulehnen.

Einige Leute, die eigentlich nicht als Idioten gelten, haben Metriken verwendet, die auf Codezeilen basierten. Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan und Steve McConnell verwendeten sie alle. Sie haben sie wahrscheinlich verwendet, auch wenn Sie nur einem Kollegen sagen möchten, dass dieses Gott-Modul 4000 Zeilen umfasst und in kleinere Klassen unterteilt werden muss.

Es gibt spezifische Daten zu dieser Frage aus einer Quelle, die viele von uns respektieren.

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

Ich vermute, dass die beste Verwendung der Codezeile pro Programmierstunde darin besteht, zu zeigen, dass dieser Wert während der Laufzeit des Projekts ziemlich hoch sein wird. Wenn jedoch Fehler gefunden und behoben werden, werden neue Codezeilen hinzugefügt, um Probleme zu lösen, die auftreten waren nicht Teil der ursprünglichen Schätzungen, und Codezeilen, die entfernt wurden, um Doppelarbeit zu vermeiden und die Effizienz zu verbessern, zeigen, dass LOC/h andere Dinge als Produktivität anzeigt.

  • Wenn Code schnell, schlampig, aufgebläht und ohne Refactoring-Versuch geschrieben wird, ist die scheinbare Effizienz am höchsten. Die Moral hier wird sein, dass Sie vorsichtig sein müssen, was Sie messen.
  • Wenn ein bestimmter Entwickler diese Woche eine große Menge Code hinzufügt oder berührt, kann es nächste Woche zu technischen Schulden kommen, die in Bezug auf Codeüberprüfung, Test, Debugging und Nacharbeit zu zahlen sind.
  • Einige Entwickler arbeiten mit einer konsistenteren Ausgaberate als andere. Es kann festgestellt werden, dass sie die meiste Zeit damit verbringen, gute User Stories zu erhalten, sich sehr schnell umzudrehen und entsprechende Unit-Tests durchzuführen und sich dann umzudrehen und schnell Code zu erstellen, der sich nur auf die User Stories konzentriert. Das Problem dabei ist, dass sich methodische Entwickler wahrscheinlich schnell umdrehen, kompakten Code schreiben und nur wenig Nacharbeit leisten müssen, da sie das Problem und die Lösung sehr gut verstehen, bevor sie mit dem Code beginnen. Es scheint vernünftig, dass sie weniger codieren, weil sie erst codieren, nachdem sie es durchdacht haben, anstatt vorher und nachher.
  • Wenn Code auf seine Defektdichte bewertet wird, wird festgestellt, dass er nicht einheitlich ist. Einige Codes werden die meisten Probleme und Mängel erklären. Es wird ein Kandidat für das Umschreiben sein. In diesem Fall wird es zum teuersten Code, da aufgrund dessen ein hohes Maß an Nacharbeit erforderlich ist. Es hat die höchsten Brutto-Codezeilen (hinzugefügt, gelöscht, geändert, wie von einem Tool wie CVS oder SVN gemeldet), aber die niedrigsten Netto-Codezeilen pro investierter Stunde. Dies kann eine Kombination des Codes sein, der entweder das komplexeste Problem oder die komplizierteste Lösung implementiert.

Unabhängig davon, wie sich die Debatte über die Produktivität von Programmierern in Codezeilen entwickelt, werden Sie feststellen, dass Sie mehr Personal benötigen, als Sie sich leisten können, und dass das System niemals rechtzeitig fertiggestellt wird. Ihre echten Werkzeuge sind keine Metriken. Sie verwenden überlegene Methoden, die besten Entwickler, die Sie einstellen oder schulen können, und die Kontrolle über Umfang und Risiko (wahrscheinlich mit agilen Methoden).

4
DeveloperDon

Ich habe vielleicht eine etwas andere Haltung dazu, aber ich denke, ich könnte verstehen, warum die Führungskraft nach diesen Informationen gesucht hat, wenn sie derzeit Projektplanung durchführen. Da es schwierig ist abzuschätzen, wie lange ein Projekt dauern wird, besteht eine der verwendeten Methoden (siehe: Softwareschätzung: Entmystifizierung der schwarzen Kunst ) darin, abzuschätzen, wie lange das Projekt dauern wird auf der Grundlage der Anzahl der SLOCs in ähnlichen Projekten und jetzt können die Entwickler durchschnittlich produzieren. In der Praxis soll dies unter Verwendung historischer Aufzeichnungen erfolgen, die die Gruppe für ähnliche Projekte mit denselben oder ähnlichen Entwicklern zur Verfügung hat.

Es ist jedoch nichts wert, dass diese Schätzungen nur für die grundlegende Projektplanung gedacht sind und nicht dazu gedacht sind, das Tempo der Entwickler für das Projekt festzulegen, da sich die Dinge von Tag zu Tag ändern. Das meiste, was Sie über die Verwendung von SLOCs als Schätzwerkzeug lesen, ist, dass sie auf lange Sicht gut sind, wenn Sie bereits über gute Kenntnisse verfügen, aber für den täglichen Gebrauch mies sind.

4
rjzii

Ich kann Ihnen sagen, dass eine Menge Auftragnehmer für ein großes Projekt 15000 LOC (jeweils) pro Jahr geschrieben haben. Das ist eine unglaublich grobe Antwort, aber es war nützlich für uns, da 400.000 C++ LoC vorhanden sind und wir herausfinden konnten, dass die Konvertierung in C # ungefähr 26 Mannjahre dauern würde. Geben oder nehmen.

Jetzt, da wir die grobe Größenordnung kennen, können wir besser planen - 20 Entwickler zu bekommen und ein Jahr Arbeit für sie alle zu schätzen, wäre ungefähr richtig. Vor dem Zählen hatten wir keine Ahnung, wie lange die Migration dauern würde.

Mein Rat für Sie ist daher, den gesamten Code, den Sie in einer bestimmten Zeit geschrieben haben, zu überprüfen (ich hatte das Glück, ein neues Projekt zu haben) und dann eines der vielen Tools für die Codemetrik auszuführen. Teilen Sie die Zahl durch die Zeit und Sie können ihm eine genaue Antwort geben - wie viel LOC Sie schreiben tatsächlich pro Tag. Für uns lag das bei 90 LOC pro Tag! Ich denke, wir hatten viele Besprechungen und Dokumentationen zu diesem Projekt, aber dann werden wir auch viele Besprechungen und Dokumentationen zu dem nächsten haben :)

3
gbjbaanb

Geben Sie ihm eine bessere Metrik zum Arbeiten

Erklären Sie anstelle von LOC , dass dies die schlechteste zu verwendende Metrik ist. Dann geben Sie ihm eine Alternative:

Anzahl der Funktionen/Features Per Feature-/Funktionsanforderungen -> NOFF/RFF

Möglicherweise müssen Sie zusätzlich zu NOFF/RFF eine Gewichtung/Normalisierung hinzufügen, um die Anzahl der Anfragen pro Woche zu berücksichtigen.

:) klar das obige ist erfunden, aber alles ist besser als SLOC ...

3
Darknight

Klingt ungefähr richtig.

https://stackoverflow.com/questions/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

Wenn Sie das Debuggen, die Dokumentation, die Planung usw. berücksichtigen, beträgt der Durchschnitt etwa 10 Codezeilen pro Tag. Eigentlich würde ich 10 Zeilen pro Tag auf der hohen Seite bewerten (dh einen sehr produktiven Entwickler).

Auch wenn Sie an einem Tag ein paar hundert Zeilen produzieren können (dies ist nicht nachhaltig). Es ist kein Qualitätscode, bis Sie dann alle Unit-Tests der Dokumentation hinzugefügt und natürlich den Code debuggt haben, nachdem Ihr Unit-Test die Fehler angezeigt hat. Nach all dem sind Sie wieder bei 10.

2
Martin York

Andere Antworten sind richtig, es ist eine dumme Frage und die Antwort bedeutet nichts Verdammtes. Es ist alles wahr, aber ich weiß zufällig, wie viele Codezeilen ich in ungefähr einem Monat produziert habe.

Es sind ungefähr 3000 Zeilen C # -Code ohne XML-Dokument. Ich habe neue Funktionen implementiert und diesen Betrag in einem Monat oder einem Monat und einer Woche erhalten. Es ist alles, was in der Quellcodeverwaltung endete. Viel Code wurde geschrieben und dann überarbeitet oder gelöscht.

Ich bin ein C # -Entwickler und versuche gut darin zu sein, aber ich kann Ihnen nicht sagen, wie objektiv gut ich bin. Ich habe versucht, guten Code zu schreiben, und mich sehr bemüht, die Wartung zu vereinfachen. Ich habe nur ein- oder zweimal Kommentare in diesen Code eingefügt.

Ich weiß nicht, ob es zu viele oder zu wenige Codezeilen sind, und ich muss sagen, dass es mich nicht wirklich interessiert. Es ist ein bedeutungsloses Datenelement und kann in keiner Weise sicher für die Extrapolation verwendet werden. Aber ich kenne diese Daten zufällig und habe mich entschlossen, sie zu teilen.

1
Dyppl

Lassen Sie Ihren Manager damit umgehen oder beginnen Sie mit der Jobsuche.

In aller Ernsthaftigkeit könnten Sie Zeit damit verbringen, was letztendlich ein hoffnungsloses Unterfangen sein könnte, der Führungskraft die richtigen und unangemessenen Methoden zu erklären, um den Fortschritt eines Projekts bis zum Abschluss zu messen. In Wirklichkeit jedoch, wofür Ingenieur- und Projektmanager sind.

Andererseits sind die Umstände so, dass die betreffende Führungskraft Ihr Ingenieur und/oder Projektmanager ist. Sie haben viel größere und grundlegendere Probleme zu lösen, auch wenn sie sich noch nicht offenbart haben. In diesem Fall kann ein solches Problem als "Warnschuss" für größere Probleme dienen.

1
mummey

Ich vermute, ein Entwickler, der mit einer Sprache wie C # arbeitet, sollte in der Lage sein, ungefähr 10.000 LoCs/Tag zu schreiben/zu generieren. Ich nehme an, ich könnte das tun. Ich würde es einfach nie tun.

Was Sie von einem Entwickler erwarten, ist, dass er seine Arbeit in 10 LoCs/Tag erledigt. Weniger Code ist immer besser. Ich fange oft an, einen Großteil des Codes zu produzieren und dann wegzuschneiden, bis ich das absolute Maximum an Einfachheit erreicht habe, also habe ich tatsächlich Tage mit negativen LoCs.

In gewissem Sinne ist Codierung wie Poesie. Die Frage ist nicht, wie viele Zeilen ein Dichter schreiben kann, sondern wie viel er in den 14 Zeilen eines Sonetts vermitteln kann.

1
back2dos

Nun, ich bin wie immer etwas spät zu dieser Party, aber das ist tatsächlich eine interessante. Ich hatte anfangs den gleichen Gedanken wie die meisten, dass die Frage der Exekutive dumm ist. Ich las jedoch die Antwort von SK-Logik und stellte fest, dass es sich um eine vernünftige Frage handelt, die auf unsinnige Weise gestellt wurde. Oder anders ausgedrückt, hinter der Frage steckt ein gültiges Problem.

Manager müssen häufig versuchen, die Machbarkeit, Finanzierung, Personalausstattung usw. für ein Projekt zu bestimmen. Dies ist ein vernünftiges Problem. Für einen Straightford-Port ist eine Schätzung basierend auf Portcodezeilen geteilt durch die geschätzten durchschnittlichen Codezeilen pro Entwickler und Tag ansprechend ansprechend, aber aus allen auf dieser Seite angegebenen Gründen zum Scheitern verurteilt.

Ein vernünftigerer Ansatz wäre:

  1. Fragen Sie die Entwickler mit der größten Erfahrung mit dem Code nach einer Darmschätzung, wie lange es dauern wird, um eine Schätzung vor Ort zu erhalten. Dies muss aus vielen Gründen falsch sein, auf die ich hier nicht näher eingehen werde, aber es ist das Beste, was sie zu Beginn tun können. Zumindest sollten sie eine Vorstellung davon haben, ob es auch mit zusätzlichen Ressourcen in einer Woche oder in Jahren einfach sein wird. Wenn Ports ähnlicher Größe oder Arbeiten ausgeführt wurden, können sie diese als Richtlinie verwenden.
  2. Schätzen Sie den Port nach Komponenten, um eine Gesamtgröße zu erhalten. Aufgaben, die nicht direkt mit dem Port zusammenhängen, müssen einbezogen werden, z. B. das Einrichten der Infrastruktur (Maschinen, Build-Systeme usw.), das Untersuchen und Kaufen von Software usw.
  3. Identifizieren Sie die riskantesten Komponenten des Ports und beginnen Sie zuerst mit diesen. Diese werden die Schätzung wahrscheinlich am meisten in die Luft jagen. Sie sollten daher nach Möglichkeit im Voraus durchgeführt werden, damit es spät im Hafen nur begrenzte Überraschungen gibt.
  4. Verfolgen Sie den Fortschritt anhand der in Schritt 2 vorgenommenen Größenbestimmung, um die erwartete Dauer des Ports kontinuierlich zu berechnen. Wenn das Projekt voranschreitet, sollte dies genauer werden. Natürlich kann die Anzahl der portierten Codezeilen (Funktionen in der ursprünglichen Codebasis, die jetzt im portierten Code enthalten sind) auch als Metrik verwendet werden und ist tatsächlich hilfreich, um sicherzustellen, dass das ursprüngliche Produkt portiert wird und nicht Eine Reihe cooler neuer Funktionen wird hinzugefügt, ohne den eigentlichen Port in Angriff zu nehmen.

Dies wären die eigentlichen Schritte. Natürlich gibt es viele andere Aktivitäten, die hilfreich sind, z. B. das Untersuchen von Portierungswerkzeugen und steckbaren Frameworks, das Erstellen von Prototypen, das Bestimmen, was wirklich portiert werden muss, das Wiederverwenden von Testwerkzeugen und Infrastruktur usw.

0
acarlon