Mythischer Mann Monat 10 Zeilen pro Entwicklertag - wie nah bei großen Projekten? [geschlossen]

Jeder sagt immer, dass er die "10 Zeilen pro Entwickler und Tag" aus dem "Mythical Man Month" schlagen kann, und wenn ich ein Projekt starte, kann ich normalerweise ein paar hundert Zeilen pro Tag bekommen.

Bei meinem früheren Arbeitgeber waren alle Entwickler sehr scharfsinnig, aber es war ein großes Projekt mit über einer Million Codezeilen, sehr hohen Zertifizierungsanforderungen und einer Schnittstelle zu anderen Projekten mit mehreren Millionen Zeilen. Irgendwann habe ich aus Neugierde Codezeilen in das Versandprodukt meiner Gruppe eingezeichnet (ohne die von uns entwickelten Tools), und es wurden tatsächlich schrittweise etwa 12 Zeilen netto pro Entwickler und Tag hinzugefügt. Ohne Änderungen, Testcode oder die Tatsache, dass Entwickler nicht jeden Tag am eigentlichen Projektcode arbeiteten.

Wie geht es anderen Menschen? Und welchen Anforderungen stehen Sie gegenüber (ich stelle mir vor, dass dies ein Faktor ist)?

Ich denke, die Anzahl der hinzugefügten Zeilen hängt stark vom Status des Projekts ab. Die Rate des Hinzufügens zu einem neuen Projekt ist viel höher als die Rate eines Startprojekts.

Die Arbeit unterscheidet sich zwischen den beiden - bei einem großen Projekt verbringen Sie normalerweise die meiste Zeit damit, die Beziehungen zwischen den Teilen herauszufinden, und nur einen kleinen Teil damit, sie tatsächlich zu ändern / hinzuzufügen. Während in einem neuen Projekt - Sie schreiben meistens ... bis es groß genug ist und die Rate sinkt.

Bei einem meiner aktuellen Projekte in einigen Modulen bin ich stolz darauf, eine negative Zeilenanzahl zur Codebasis beigetragen zu haben. Das Erkennen, welche Codebereiche unnötig komplex geworden sind und mit einem saubereren und klareren Design vereinfacht werden können, ist eine nützliche Fähigkeit.

Natürlich sind einige Probleme von Natur aus komplex und erfordern komplexe Lösungen, aber bei den meisten großen Projekten haben Bereiche mit schlecht definierten oder sich ändernden Anforderungen tendenziell zu komplexe Lösungen mit einer höheren Anzahl von Problemen pro Zeile.

Angesichts eines zu lösenden Problems bevorzuge ich die Lösung, die die Zeilenanzahl reduziert. Natürlich kann ich zu Beginn eines kleinen Projekts mehr als zehn Codezeilen pro Tag generieren, aber ich denke nicht an die Menge an Code, die ich geschrieben habe, sondern nur an das, was es tut und wie gut es funktioniert. Ich würde sicherlich nicht darauf abzielen, zehn Zeilen pro Tag zu schlagen oder es als Erfolg zu betrachten.

Ich mag dieses Zitat:

Wenn wir Codezeilen zählen möchten, sollten wir sie nicht als "erzeugte Zeilen" betrachten, sondern als "ausgegebene Zeilen". - Edsger Dijkstra

Manchmal haben Sie mehr durch Entfernen von Code als durch Hinzufügen von Code beigetragen

Sie sollten diese Metrik nicht mehr verwenden, sie ist größtenteils bedeutungslos. Kohäsion, Kopplung und Komplexität sind wichtigere Metriken als Codezeilen.

Wie geht es anderen Menschen?

Ich bin der einzige Vollzeitentwickler in unserem Unternehmen und habe in den letzten 7 Jahren 500.000 Zeilen OCaml- und F # -Code geschrieben, was ungefähr 200 Codezeilen pro Tag entspricht. Die überwiegende Mehrheit dieses Codes sind jedoch Tutorial-Beispiele, die aus Hunderten von separaten Projekten bestehen, die jeweils einige hundert Zeilen lang sind. Außerdem gibt es viele Überschneidungen zwischen OCaml und F #. Wir pflegen keine internen Codebasen, die größer als 50 kLOC sind.

Neben der Entwicklung und Wartung unserer eigenen Software habe ich in den letzten 7 Jahren auch viele Kunden in der Industrie beraten. Für den ersten Kunden habe ich über 3 Monate 2.000 Zeilen OCaml geschrieben, was 20 Codezeilen pro Tag entspricht. Für den nächsten Client haben vier von uns einen Compiler geschrieben, der in 6 Monaten Millionen Zeilen C / C ++ / Python / Java / OCaml-Code sowie Dokumentation generiert hat, dh 2.000 Codezeilen pro Tag und Entwickler. Für einen anderen Client habe ich in 6 Monaten 50 kLOC C ++ durch 6 kLOC F # ersetzt, was -352 Codezeilen pro Tag entspricht. Für einen weiteren Client schreibe ich 15kLOC OCaml in F # um, was die gleiche Größe hat, also 0 Codezeilen pro Tag.

Für unseren derzeitigen Kunden werde ich in einem Jahr 1.600.000 Zeilen C ++ - und Mathematica-Code durch ~ 160 kLOC F # ersetzen (indem ich einen maßgeschneiderten Compiler schreibe), was -6.000 Codezeilen pro Tag entspricht. Dies wird mein bislang erfolgreichstes Projekt sein und unseren Kunden jährlich Millionen von Dollar an laufenden Kosten einsparen. Ich denke, jeder sollte darauf abzielen, -6.000 Codezeilen pro Tag zu schreiben.

Ohne meine Ausgabe von "The Mythical Man-Month" zu überprüfen (jeder, der dies liest, sollte wirklich eine Kopie zur Verfügung haben), gab es ein Kapitel, in dem Brooks die Produktivität anhand von Zeilen betrachtete. Der interessante Punkt für ihn war nicht die tatsächliche Anzahl der pro Tag geschriebenen Zeilen, sondern die Tatsache, dass es im Assembler und in PL / I ungefähr gleich zu sein schien (ich denke, das war die übergeordnete Sprache).

Brooks wollte keine willkürliche Produktivitätszahl herauswerfen, aber er arbeitete anhand von Daten zu realen Projekten, und soweit ich mich erinnern kann, waren es durchschnittlich 12 Zeilen pro Tag.

Er wies darauf hin, dass die Produktivität voraussichtlich variieren werde. Er sagte, Compiler seien dreimal so hart wie Anwendungsprogramme und Betriebssysteme dreimal so hart wie Compiler. (Er scheint es gemocht zu haben, Multiplikatoren von drei zu verwenden, um Kategorien zu trennen.)

Ich weiß nicht, ob er die individuellen Unterschiede zwischen der Produktivität von Programmierern zu schätzen wusste (obwohl er in einem Größenordnungsargument einen Faktor von sieben Unterschieden postuliert hat), aber wie wir wissen, geht es bei überlegener Produktivität nicht nur darum, mehr zu schreiben Code, aber auch den richtigen Code schreiben, um die Arbeit zu erledigen.

Es gibt auch die Frage der Umwelt. Brooks spekulierte ein wenig darüber, was Entwickler schneller oder langsamer machen würde. Wie viele andere fragte er sich, ob die aktuellen Moden (interaktives Debuggen mit Time-Sharing-Systemen) besser seien als die alten Methoden (sorgfältige Vorplanung für eine zweistündige Aufnahme mit der gesamten Maschine).

Angesichts dessen würde ich jede tatsächliche Produktivitätszahl, die er sich ausgedacht hatte, als nutzlos ignorieren. Der anhaltende Wert des Buches liegt in den Grundsätzen und allgemeineren Lektionen, die die Menschen weiterhin nicht lernen. (Hey, wenn jeder sie gelernt hätte, wäre das Buch nur von historischem Interesse, ähnlich wie alle Argumente Freuds, dass es so etwas wie ein Unterbewusstsein gibt.)

Es ist einfach, ein paar hundert Codezeilen pro Tag zu erhalten. Aber versuchen Sie, ein paar hundert hochwertige Codezeilen pro Tag zu erhalten, und das ist nicht so einfach. Top das mit Debuggen und Durchlaufen von Tagen mit wenig oder keinen neuen Zeilen pro Tag und der Durchschnitt wird ziemlich schnell sinken. Ich habe Wochen damit verbracht, schwierige Probleme zu beheben, und die Antwort waren 1 oder 2 Codezeilen.

Es wäre viel besser zu erkennen, dass das Sprechen von physischen Codezeilen ziemlich bedeutungslos ist. Die Anzahl der physischen Codezeilen (LoC) hängt so stark vom Codierungsstil ab, dass sie von Entwickler zu Entwickler in einer Größenordnung variieren kann.

In der .NET-Welt gibt es eine bequeme Möglichkeit, die LoC zu zählen. Sequenzpunkt . Ein Sequenzpunkt ist eine Debugging-Einheit. Dies ist der Code-Teil, der beim Setzen eines Haltepunkts dunkelrot hervorgehoben wird. Mit dem Sequenzpunkt können wir von logischer LoC sprechen , und diese Metrik kann in verschiedenen .NET-Sprachen verglichen werden. Die logische LoC-Codemetrik wird von den meisten .NET-Tools unterstützt, einschließlich VisualStudio-Codemetrik, NDepend oder NCover.

Hier ist zum Beispiel eine 8-LoC-Methode (Sequenzpunkte für Anfangs- und Endklammern werden nicht berücksichtigt):

Die Produktion von LoC muss langfristig gezählt werden. An manchen Tagen spucken Sie mehr als 200 LoC aus, an anderen Tagen verbringen Sie 8 Stunden damit, einen Fehler zu beheben, indem Sie nicht einmal eine einzige LoC hinzufügen. An manchen Tagen werden Sie toten Code bereinigen und LoC entfernen, an manchen Tagen werden Sie Ihre ganze Zeit damit verbringen, vorhandenen Code zu überarbeiten und keinen neuen LoC zur Gesamtsumme hinzuzufügen.

Persönlich zähle ich eine einzelne LoC in meiner eigenen Produktivitätsbewertung nur dann, wenn:

1. Es wird durch Unit-Tests abgedeckt
2. Es ist mit einer Art Code-Vertrag verbunden (wenn möglich, können natürlich nicht alle LoC durch Verträge überprüft werden).

Unter dieser Bedingung beträgt meine persönliche Punktzahl in den letzten 5 Jahren beim Codieren des NDepend-Tools für .NET-Entwickler durchschnittlich 80 physische LoC pro Tag, ohne die Codequalität zu beeinträchtigen . Der Rhythmus hält an und ich sehe nicht, dass er bald abnimmt. Alles in allem ist NDepend eine C # -Codebasis, die derzeit etwa 115 KB physischen LoC wiegt

Für diejenigen, die es hassen, LoC zu zählen (ich habe viele davon in Kommentaren hier gesehen), bestätige ich, dass das Zählen von LoC nach einer angemessenen Kalibrierung ein hervorragendes Schätzwerkzeug ist . Nachdem ich Dutzende von Features codiert und gemessen hatte, die in meinem speziellen Entwicklungskontext erzielt wurden, erreichte ich den Punkt, an dem ich die Größe eines TODO-Features in LoC und die Zeit, die ich für die Lieferung an die Produktion benötige, genau abschätzen kann.

Es gibt keine Silberkugel.

Eine solche Metrik ist für sich genommen nutzlos.

Zum Beispiel habe ich meine eigene Klassenbibliothek. Derzeit sind die folgenden Statistiken wahr:

Zeilen insgesamt: 252.682 Codezeilen
: 127.323
Kommentare: 99.538
Leere Zeilen: 25.821

Nehmen wir an, ich schreibe überhaupt keine Kommentare, dh 127.323 Codezeilen. Mit Ihrem Verhältnis würde ich ungefähr 10610 Tage brauchen, um diese Codebibliothek zu schreiben. Das sind 29 Jahre.

Ich habe sicherlich nicht 29 Jahre damit verbracht, diesen Code zu schreiben, da alles C # ist und C # noch nicht so lange existiert.

Nun können Sie argumentieren, dass der Code nicht allzu gut ist, da ich offensichtlich Ihre 12 Zeilen pro Tag überschritten haben muss, und ja, ich werde dem zustimmen, aber wenn ich die Zeitachse auf reduzieren will Als 1.0 veröffentlicht wurde (und ich habe erst mit der Veröffentlichung von 2.0 begonnen), also am 13.02.2002, ungefähr 2600 Tage, beträgt der Durchschnitt 48 Codezeilen pro Tag.

Alle diese Codezeilen sind gut? Mist nein. Aber bis zu 12 Codezeilen pro Tag?

Mist nein.

Alles hängt davon ab.

Sie können einen erstklassigen Programmierer haben, der Code in der Größenordnung von Tausenden von Zeilen pro Tag ausgibt, und einen mittleren Programmierer, der Code in der Größenordnung von Hunderten von Zeilen pro Tag ausgibt, und die Qualität ist dieselbe.

Und ja, es wird Fehler geben.

Die Summe, die Sie wollen, ist das Gleichgewicht. Die Menge des geänderten Codes im Vergleich zur Anzahl der gefundenen Fehler im Vergleich zur Komplexität des Codes im Vergleich zur Schwierigkeit, diese Fehler zu beheben.

Steve McConnell gibt in seinem Buch "Software Estimation" (S. 62, Tabelle 5.2) eine interessante Statistik. Er unterscheidet zwischen Projekttypen (Avionic, Business, Telco usw.) und Projektgröße 10 kLOC, 100 kLOC, 250 kLOC. Die Nummern werden für jede Kombination in LOC / StaffMonth angegeben. EG Avionic: 200, 50, 40 Intranetsysteme (intern): 4000, 800, 600 eingebettete Systeme: 300, 70, 60

Was bedeutet: z. Für das Avionic 250-kLOC-Projekt gibt es 40 (LOC / Monat) / 22 (Tage / Monat) == <2LOC / Tag!

Ich denke, dies stammt aus den Tagen der Wasserfallentwicklung , in denen die tatsächliche Entwicklungsphase eines Projekts nur 20 bis 30% der gesamten Projektzeit betragen könnte. Nehmen Sie die gesamten Codezeilen und dividieren Sie sie durch die gesamte Projektzeit. Sie erhalten ungefähr 10 Zeilen pro Tag. Teilen Sie nur durch den Codierungszeitraum, und Sie kommen dem näher, was die Leute zitieren.

Unsere Codebasis ist ungefähr 2.2MLoC für ungefähr 150 Mannjahre Aufwand. Das sind ungefähr 75 Zeilen C ++ oder C # pro Entwickler und Tag über die gesamte Laufzeit des Projekts.

Ich denke, die Projektgröße und die Anzahl der beteiligten Entwickler sind große Faktoren. Ich bin im Laufe meiner Karriere weit darüber hinaus, aber ich habe die ganze Zeit alleine gearbeitet, sodass es keinen Verlust gibt, mit anderen Programmierern zusammenzuarbeiten.

Gute Planung, gutes Design und gute Programmierer. Sie erhalten alles zusammen und Sie werden nicht 30 Minuten damit verbringen, eine Zeile zu schreiben. Ja, bei allen Projekten müssen Sie anhalten und planen, überlegen, diskutieren, testen und debuggen, aber bei zwei Zeilen pro Tag würde jedes Unternehmen eine Armee benötigen, damit Tetris funktioniert ...

Fazit: Wenn Sie mit 2 Zeilen pro Stunde für mich arbeiten, sollten Sie mir besser viele Kassen besorgen und meine Füße massieren, damit Sie nicht gefeuert werden.

Man vermutet, dass dieses mehrjährige Stück Manager-Candy geprägt wurde, als alles eine in C geschriebene System-App war, denn wenn nichts anderes, würde die magische Zahl je nach Sprache, Umfang und Art der Anwendung um Größenordnungen variieren. Und dann müssen Sie Kommentare und Attribute rabattieren. Und wer kümmert sich letztendlich um die Anzahl der geschriebenen Codezeilen? Solltest du fertig sein, wenn du 10K-Linien erreicht hast? 100K? So willkürlich.

Es ist sinnlos.