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


21

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 im Rahmen der Projektplanung.

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

Die Gruppe war sich einig, dass dies fast unmöglich zu spezifizieren ist, da es von einer langen Liste von Umständen abhängen würde. Aber wir könnten sagen, dass der Mann nicht gehen würde (oder sehr enttäuscht von uns wäre), 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? (nebenbei oder sogar mit etwas Analyse)


7
Müssen diese Leitungen eine eingebettete Qualität haben? > _>
Dr. Hannibal Lecter

4
Kann es sich um computergenerierten Code handeln? Wenn ja, bin ich mir ziemlich sicher, dass ich mit der richtigen Hardware das Zetta-Leistungspräfix (10 ^ 21) in Zeilen eingeben kann. Es wird nichts tun, wohlgemerkt ...
GroßmeisterB

6
Glaubwürdige Quelle: Mythical Man Month.
Martin York

2
Wie viel Holz kann ein Waldmurmeltier spannen, wenn ein Waldmurmeltier Holz spannen könnte? Ich kann nicht glauben, dass diese Frage immer noch gestellt wird! Was ist das 1975? Es gibt viel bessere Fragen: "Wie viele Systeme hat das Entwicklerteam in diesem Jahr erfolgreich implementiert?" oder "Wie viele Stunden pro Monat wurden mit dem aktuellen System im Vergleich zu zuvor eingespart?" Die Frage sollte von Wert sein, nicht die Menge einer irrelevanten Metrik.
Mark Freedman

3
Die Frage sollte nicht beantwortet werden, da sie auf falschen Annahmen wie "mehr ist besser" oder "mehr Code bedeutet mehr Qualität" basiert.
ThomasX

Antworten:


84

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 Vertrags. 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 eines Anwalts sind.

Aber dir zu geben eine Antwort auf Ihre eigentliche Frage zu geben: Meiner Erfahrung nach sind für ein neues Projekt ein paar hundert SLOC pro Tag und Entwickler keine Seltenheit. Sobald aber die ersten Bugs auftauchen, wird diese Zahl stark sinken.


18
Diese Zahl könnte sogar so stark sinken, dass sie ins Negative geht ...
Hans Ke st ing

Es ist keine korrekte Analogie. Es ist völlig in Ordnung, einen Übersetzer zu fragen, wie viele Seiten eines englischen Textes er in einer Woche ins Deutsche übersetzen kann. Und sie portieren eine Anwendung von einer Sprache / Plattform auf eine andere, ähnlich einer Übersetzung.
SK-logic

4
@ SK-Logic ist das? Versuchen Sie, ein ungezwungenes Gespräch zu übersetzen, und versuchen Sie dann, ein langes juristisches Dokument zu übersetzen.
BlackICE

@ SK-logic - Jede Zeile in einem übersetzten Quelldokument wird im Allgemeinen einer einzelnen Zeile im Zieldokument zugeordnet - es ist eine sehr lineare Zuordnung. Wenn es um Software geht, ist es unwahrscheinlich, dass zwei Programmiersprachen in ihrer Struktur und Leistungsfähigkeit ähnlich genug sind, um dasselbe erwarten zu können. Es wird wahrscheinlich zahlreiche Bereiche geben, in denen Einsparungen erzielt werden könnten, und einige Bereiche, in denen Sie vergleichsweise mehr Code schreiben müssen.
cjmUK

1
@KristofProvost, eine 1-zu-1-Übersetzung ist normalerweise der Ausgangspunkt für einen langwierigen und schmerzhaften Refactoring-Prozess. Aber es ist notwendig, dass zuerst etwas funktioniert. Bei allen Übersetzungsprojekten, die ich getroffen habe, lag die Hauptmotivation in der Alterung der ursprünglichen Toolchain (z. B. PL / I bis C ++) und dem Mangel an Vertrauen in ihre Zukunft. Sauberer und idiomatischer Code hatte in solchen Projekten nie höchste Priorität.
SK-logic

33

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

Wenn sie gut sind, weniger als Null.


5
+1: Bei der Pflege von Legacy-Code wird ein negativer LOC-Check-In angestrebt (unter Beibehaltung oder Verbesserung der Funktionalität). Einer meiner Kollegen hat es geschafft, mehr als 2.500 Codezeilen bei einem Check-in zu entfernen. Das Refactoring dauerte ungefähr eine Woche, aber der Gesamtdurchschnitt lag immer noch bei über -300 Zeilen pro Tag. :-)
Peter K.

Das Messen mit reduzierten Codezeilen ist genauso bedeutungslos wie das Messen mit reduzierten Codezeilen - diese Anzahl von Codezeilen ist ein gültiges Maß für etwas anderes als die Anzahl von Codezeilen. Geben Sie mir 40.000 Zeilen guten Codes und mehr als 10.000 Zeilen unlesbarer, mit Fehlern durchsetzter Spaghetti pro Tag.
Maximus Minimus

1
Natürlich ist es sinnlos , @mh. dies ist eher eine tongue-in-cheek Antwort
quentin-starin

21

Führen Sie die andere Art und Weise ... Jetzt.

LoC ist eine der schlimmsten Metriken können Sie verwenden.

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

Je nach Komplexität des Codes, Portierung kann durch Automatisierungsprozesse durchgeführt werden, die sich ergeben würden in großen tausend + LoC einen Tag ändert, während schwieriger Abschnitte, in denen die Sprachkonstrukte wild unterschiedlich sind Code am 100LoC täglich portiert werden.

Schick er die Wikipedia - Seite über lesen SLOC . Gibt ein paar nette und einfache Beispiele, warum es so eine schlechte Metrik ist.


1
MxGrath: SLOC ist nur schlecht, um den Fortschritt zu messen, aber es ist oft nützlich, um die Gesamtkomplexität zu messen, insb. da, wie Les Hatton betonte, "McCabe Cyclomatic Complexity die gleiche Vorhersagefähigkeit wie Codezeilen hat."
pillmuncher

18

Die richtige Antwort: Nein ...

Diese Führungskraft sollte darauf hingewiesen werden, dass SLOC keine gültigen Messgrößen für den Analysefortschritt sind

Die Sloppy Antwort: Jede Anzahl Sie bilden können.

Gib ihm eine gewisse Zahl, Sie und Ihr Team leicht sowieso, dass die Zahl bis zu machen. (Indem es sei denn, Linie, Leerzeilen, Kommentare etc etc, nur dieser Typ ermöglichen, weiterhin in seiner Phantasiewelt zu leben, und spukt noch ein anderes Team und weiterhin das Elend Zyklus verstärkt, die eine Geschichte zu thedailywtf macht.

Nicht schön, aber machbar.


Ich würde sagen , dass die Kommentare könnten die Nützlichkeit des Codes erhöhen, though.
Nitrodist

2
@Nitrodist in der Tat gute Kommentare sind die Kommentare , die ich mich beziehe , wird nur verwendet , um „make“ die Exekutive glücklich. Welche wäre völlig nutzlos ...
Zekta Chan

10

Auf den ersten Blick sieht diese Frage absolut dumm aus, und jeder hier hat nur auf den dummen C # LoC-Teil geantwortet. Aber es ist eine wichtige Nuance - es ist eine Frage über eine Portierung Leistung. Der richtige Weg, diese Frage zu stellen, besteht darin, zu fragen, wie viele Codezeilen des Quellprojekts (diejenige, die portiert wird) ein Entwickler innerhalb einer bestimmten Zeiteinheit verarbeiten kann. Dies ist eine durchaus begründete Frage, da die Gesamtzahl der Codezeilen bekannt ist und genau die Menge der zu erledigenden Arbeiten. Der richtige Weg, um diese Frage zu beantworten, besteht darin, ein paar historische Daten zu sammeln - beispielsweise eine Woche lang zu arbeiten und die Leistung jedes Entwicklers zu messen.


1
Wie ist dies ein Hinweis auf den genauen Arbeitsaufwand? Wenn Sie 1000 Codezeilen portieren müssen, ist es möglicherweise möglich, diese auf 50 Codezeilen zu portieren, wenn verfügbare Bibliotheken / vorhandene Funktionen usw. verwendet werden. Und es könnte auch 50 Zeilen zu portieren eine bestehende 100 Zeilen Code als auch. Völlig abhängig vom Code.
Mark Freedman

I gesagt , dass eine Anzahl von Quellen LoC eine richtige Metrik ist, nicht den Ausgang.
SK-logic

2
Ich stimme dir nicht zu. Wenn im Original Codeabschnitte vorhanden sind, die im Port keinen Sinn ergeben, werden sie niemals als "portiert" betrachtet und daher niemals gezählt. OTOH, das Erstellen eines Feature- und Support-Sets für das Original, kann einen aussagekräftigeren Hinweis auf den Fortschritt bis zur Fertigstellung geben. Einfach ausgedrückt, die Fortschrittsmetrik ist nur die Mühe wert, die man bereit ist, sie zu generieren und aufrechtzuerhalten.
Mama

1
@mummey, Effekte, von denen du sprichst, sind nur Schwankungen. Sie sollten statistisch gesehen verschwinden und groß genug sein.
SK-logic

7

Ich habe nur eins zu sagen:

"Das Messen des Programmierfortschritts anhand von Codezeilen ist wie das Messen des Flugzeugbaufortschritts anhand des Gewichts."

-- 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!


5
I 
can
write
large
numbers
of
lines
of
code
per
month.

Proportional zur Anzahl der Wörter.

Sie sehen, mein Punkt?


1
Die meisten Tools , die loc Statistiken geben Ihnen logische LOCs erzeugen - dh „Code Aussagen“ nicht „Editor Linien“. So Ihre Antwort wäre eine Bewertung von 1 LLOC bekommen. Sie erzeugen auch nützliche Metriken wie Verhältnis von Kommentaren zu Code und die Komplexität des Codes, so theyr'e nicht völlig nutzlos.
gbjbaanb

1
@ gbjbaanb Das ist nur eine andere Art von nutzlos. Deklarative Sprachen haben keine Anweisungen oder daher "Anweisungszeilen". Guter Code kann sich selbst dokumentieren und enthält sinnvolle Bezeichnernamen anstelle von Kommentaren. Anderer Code wird grafischer geschrieben, wenn es kein sinnvolles Konzept für "Linien" gibt, z. B. Mathematica-Notizbücher.
Jon Harrop

4

Ich habe vielleicht eine etwas andere Einstellung dazu, aber ich denke, ich kann verstehen, warum die Führungskraft nach diesen Informationen gesucht hat, wenn sie gerade eine Projektplanung durchführt. Da es schwer abzuschätzen , wie lange ein Projekt dauern wird, eine der Methoden , die verwendet wird (siehe: Software Estimation: Entmystifizierung der schwarze Kunst ) darin, anhand der Anzahl der Projekte abzuschätzen, wie lange es dauern wird SLOCs in ähnlichen Projekten und können nun die Entwickler produzieren im Durchschnitt. In der Praxis sollen hierfür historische Aufzeichnungen verwendet werden, 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 im Projekt zu bestimmen, 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

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

Einige Menschen, die nicht wirklich Idioten betrachtet haben gebrauchte Metriken, die auf Codezeilen beruhten. Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan und Steve McConnell alle ihnen verwendet. Wahrscheinlich haben Sie sie auch dann verwendet, wenn nur an einen Kollegen zu sagen, das Gott-Modul ist 4000 Zeilen, muss es in kleinere Klassen, gebrochen werden.

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 über die gesamte Laufzeit des Projekts ziemlich hoch sein wird. Sobald jedoch Fehler gefunden und behoben werden, werden neue Codezeilen hinzugefügt, um Probleme zu lösen, die auftreten können waren nicht Teil der ursprünglichen Schätzungen, und Codezeilen, die entfernt wurden, um Duplikationen zu vermeiden und die Effizienz zu verbessern, zeigen, dass LOC / h andere Faktoren als die Produktivität angibt.

  • Wenn Code schnell, schlampig, aufgebläht und ohne Umgestaltungsversuche geschrieben wird, ist die scheinbare Effizienz am höchsten. Die Moral hier wird sein, dass Sie vorsichtig sein müssen, was Sie messen.
  • Für einen bestimmten Entwickler, wenn sie hinzufügen oder eine große Menge an Code zu berühren in dieser Woche, nächste Woche dort kann eine technische Schulden zu bezahlen sein in Bezug auf die Code-Review, testen, debuggen und Nacharbeit.
  • Einige Entwickler arbeiten mit einer gleichmäßigeren Ausgaberate als andere. Es kann festgestellt werden, dass sie die meiste Zeit auf immer gute User Stories, dreh dich um sehr schnell und machen entsprechende Unit-Tests, und dann umdrehen und schnell machen Code ausgeben, die nur auf die User Stories fokussiert ist. Die Take hier weg ist, dass methodische Entwickler wahrscheinlich schnell haben wird sich umdrehen, wird kompakter Code schreiben, und haben eine geringe Nacharbeit, weil sie das Problem und die Lösung sehr gut verstehen, bevor sie zu Code starten. Es erscheint vernünftig, dass sie weniger programmieren, weil sie erst nach dem Überlegen programmieren, anstatt vorher und nachher.
  • Wenn Code für seine Defektdichte ausgewertet, so wird es als einheitliches weniger sein wird gefunden. Einige Codes sind für die meisten Probleme und Mängel verantwortlich. Es wird ein Kandidat für das Umschreiben sein. Wenn das passiert, wird es das teuerste Code, weil durch sie hohe Maß an Nacharbeit werden. Es werden 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 Stunde investiert. Dies kann sein eine Kombination aus dem Code am Ende entweder das komplexeste Problem oder die komplizierteste Lösung zu implementieren.

Unabhängig davon, wie die Debatte über die Produktivität der Programmierer in Codezeilen abwechselnd aus werden Sie feststellen, dass Sie mehr Menschen Macht brauchen, als Sie sich leisten können, und das System niemals rechtzeitig abgeschlossen werden. Sie echte Werkzeuge sind nicht Metriken. Sie basieren auf einer überlegenen Methodik, den besten Entwicklern, die Sie einstellen oder schulen können, und der Kontrolle von Umfang und Risiko (wahrscheinlich mit agilen Methoden).


The take away here is that methodical developers will probably have quick turn around, will write compact code, and have low rework.Nicht zustimmen. Es ist entweder ein wenig umformuliert oder eine schnelle Abwicklung. Okay, die dritte Option ist Ausbrennen und Verlassen der Entwicklerkarriere.
Neolisk

3

Geben Sie ihm eine bessere Metrik, mit zu arbeiten

Statt LOC , erklärt dies ist die schlechteste Metrik zu verwenden. Dann gib ihm eine Alternative:

Anzahl der Funktionen / Eigenschaften Pro Eigenschaft / Funktion Requests -> 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 irgendetwas ist besser als SLOC ...


3

Ich kann Ihnen sagen, dass eine Last von Auftragnehmern für ein großes Projekt schreibt 15000 LOC (jeweils) in einem Jahr. Das ist eine unglaublich grobe Antwort, aber es war für uns von Nutzen, da wir 400.000 bestehenden C ++ LoC haben und wir konnten herausfinden, dass sie alle zu C # Umwandlung nehmen würde uns etwa 26 Mann-Jahre in Anspruch nehmen. Geben oder nehmen.

So, jetzt wir die grobe Größenordnung kennen, können wir besser für sie planen - immer 20 Devs und einem Jahr Arbeit für sie schätzen alle ungefähr richtig sein würde. Vor dem Zählen, hatten wir keine Ahnung, wie lange es dauern würde zu migrieren nehmen.

Also mein Rat für Sie den gesamten Code zur Kasse Sie in einer bestimmten Zeit geschrieben habe (ich hatte das Glück , ein neues Projekt zu Arbeit mit haben), dann eine der vielen Code - Metrik - Tools darauf laufen. Teilen Sie die Zahl durch die Zeit , und man kann ihm eine genaue Antwort geben - wie viel LOC Sie tatsächlich schreiben pro Tag. Für uns, dass kamen pro Tag bei 90 LOC out! Ich denke , wir haben an diesem Projekt eine Menge von Sitzungen und Dokumentation haben, aber dann denke ich , dass wir viele Sitzungen und Unterlagen über die nächsten haben , würden :)


2

Sounds über richtig.

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

Wenn Sie das Debuggen, Dokumentieren, Planen usw. berücksichtigen, beträgt der Durchschnitt etwa 10 Codezeilen pro Tag. Eigentlich würde ich 10 Zeilen pro Tag hoch bewerten (dh einen sehr produktiven Entwickler).

Auch wenn Sie an einem Tag ein paar Hundert Zeilen produzieren können (dies ist nicht nachhaltig). Es kann kein Qualitätscode sein, bis Sie dann alle Gerätetests der Dokumentation hinzugefügt und natürlich den Code nach Ihrem Gerätetest debuggt haben, um die Fehler anzuzeigen. Nach alledem sind Sie wieder bei 10.


1

Ich vermute, ein Entwickler, der mit einer Sprache wie C # arbeitet, sollte in der Lage sein, ungefähr 10 KB LoCs / Tag zu schreiben / generieren. Ich schätze, das könnte ich machen. Ich würde nur nie.

Was Sie von einem Entwickler erwarten, ist, dass er seine Arbeit in 10 LoCs / Tag erledigt. Weniger Code ist immer besser. Ich oft mal beginnen einen Großteil der Code produzieren und dann Wegschneiden, bis ich den nackten maximal Einfachheit zu erreichen, so dass ich mit negativen LOCS haben tatsächlich Tagen.

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


5
10K LoC? IMO, das kann nur ein Generator. Soweit handgeschriebener LoC geht, würde ich eher die Obergrenze im Bereich von 1 K LoC setzen. Und das muss ein außerordentlich produktiver Tag sein.
user281377

@ammoQ: Es ist machbar. Wenn jemand Sie gefragt , wie viel Code wie möglich zu schreiben, könnten Sie das tun. Es ist wahrscheinlich nur ein Mythos, aber ich habe gehört, dass Programmierer gezwungen sind, viele LoCs zu erstellen, indem sie toten oder doppelten Code einbinden, Schleifen erweitern und Funktionen von Hand inlinieren (oder gar keine Schleifen und Subroutinen haben) und viele andere Dummheiten Dinge. Außerdem hilft der übermäßigen Einsatz von Standardcode: D
back2dos

@ back2dos: OK, ich habe eher über Code nachgedacht, der tatsächlich Sinn macht.
user281377

@ammoQ: naja das ist sicher nichts wofür ich dir die schuld geben würde. Mein Punkt war eher, dass die Metriken, die keinen Sinn führen zu Code machen, das keinen Sinn macht;)
back2dos

1

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

In alle Ernst, könnten Sie tim es ausgeben, was die Exekutive kann am Ende der richtigen und falsche Methoden bei der Erläuterung eines Projektes Fortschritte in Richtung Abschluss der Messung ein aussichtsloses Unterfangen zu sein. In Wirklichkeit jedoch, wofür Ingenieure und Projektmanager sind.

In der anderen Seite sind die Umstände so , dass die Exekutive-in-Frage IST Ihr Engineering und / oder Projektmanager. Sie haben viel größere und grundlegendere Probleme zu lösen, auch wenn sie sich noch nicht ergeben haben. In diesem Fall kann ein solches Problem als "Warnschuss" für größere Probleme dienen.


1

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

Es geht um 3000 Zeilen C # -Code ohne XML-Dokument. Ich implementierte neue Funktionen und bekam diese Menge in einem Monat oder einem Monat und einer Woche. Es ist alles, was in der Quellcodeverwaltung gelandet ist, 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 mir viel Mühe gegeben, um die Wartung zu vereinfachen. Ich habe nur ein- oder zweimal Kommentare in diesen Code eingefügt.

Ich weiß nicht, ob es sich um zu viele oder zu wenige Codezeilen handelt, und ich muss sagen, es ist mir eigentlich egal. Es handelt sich um bedeutungslose Daten, die in keiner Weise sicher für die Extrapolation verwendet werden können. Aber ich kenne diese Daten zufällig und habe beschlossen, sie zu teilen.


0

Nun, ich bin wie immer ein bisschen zu 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 habe jedoch die Antwort von SK-logic gelesen und festgestellt, dass es sich um eine sinnvolle, unsinnig gestellte Frage handelt. Oder anders ausgedrückt, hinter der Frage steckt ein berechtigtes Problem.

Manager müssen oft versuchen, Machbarkeit, Finanzierung, Personal usw. für ein Projekt zu bestimmen. Das ist ein vernünftiges Problem. Für einen Straightford-Port ist eine Schätzung basierend auf den Codezeilen des Ports geteilt durch die geschätzten durchschnittlichen Codezeilen pro Entwickler und Tag in der Einfachheit ansprechend, aber aus allen auf dieser Seite genannten 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 Vor-Ort-Schätzung, wie lange dies dauern wird. Dies muss aus vielen Gründen falsch sein, auf die ich hier nicht eingehen werde, aber es ist das Beste, was sie von Anfang an tun können. Zumindest sollten sie eine Vorstellung davon haben, ob es auch mit zusätzlichen Ressourcen in einer Woche oder in Jahren einfach zu schaffen sein wird. Wenn Häfen oder Arbeiten mit ähnlicher Größe ausgeführt wurden, kann dies als Leitfaden dienen.
  2. Schätzen Sie den Port nach Komponenten, um eine Gesamtgröße zu erhalten. Aufgaben, die sich nicht direkt auf den Port beziehen, müssen berücksichtigt 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 mit diesen. Diese dürften die Schätzung am meisten zunichte machen, sollten also möglichst im Voraus durchgeführt werden, damit es im späten Hafen nur begrenzte Überraschungen gibt.
  4. Behalten Sie den Überblick über die Fortschritte gegen die Dimensionierung in Schritt 2 durchgeführt, um kontinuierlich die erwartete Dauer des Hafens zu berechnen. Da das Projekt bewegt sich voran sollte dies genauer werden. Die Anzahl der portierten Codezeilen (Funktionen in der ursprünglichen Codebasis, die jetzt im portierten Code enthalten sind) kann natürlich auch als Metrik verwendet werden und ist hilfreich, um sicherzustellen, dass das ursprüngliche Produkt portiert wird, anstatt eine Reihe von coolen neuen Funktionen hinzugefügt werden, während der tatsächliche Port Angriff zu nehmen.

Dies wären die einfachen Schritte, natürlich gibt es viele andere nützliche Aktivitäten, wie die Untersuchung von Portierungswerkzeugen und steckbaren Frameworks, die Erstellung von Prototypen, die Bestimmung der wirklich zu portierenden Komponenten, die Wiederverwendung von Testwerkzeugen und Infrastrukturen usw.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.