Projektgrösse - Was ist klein, was ist gross?
-
Grad für sowas gibts mehr oder weniger einheitliche Zählweisen. Eine geschweifte Klammer in einer Zeile zählt nicht als eigene Zeile usw. Ich würde die Anzahl der Zeilen natürlich nicht mit einem wc -l zählen. Aber wenn man sich darauf eignet, keine künstlich aufgeblähten Konstrukte zu zählen, dann ist zumindest dieses Argument keins mehr.
-
nman schrieb:
Jester schrieb:
Es geht aber um eine Ordnung, nicht um ein direktes vergleichen.
Wie willst du denn ordnen können, wenn du nicht vergleichen kannst?
Ich will einfach nur feststellen, ob ein Projekt deutlich größer ist als ein anderes. Projekte die nah aneinander sind kann ich damit nicht vergleichen und enthalte mich daher einer Aussage.
Da große Projekte üblicherweise ne halbwegs vernünftige Formatierung verwenden (nicht etwa ein Schlüsselwort pro zeile) und ich Projektgrößen anschauen möchte und nicht die Produktivität eines Programmierers abschätzen möchte, der dann möglicherweise extra aufbläst, scheinen mir eure Einwände bis jetzt am Kern der Sache vorbeizugehen.
Aber okay, wir können natürlich auch sagen, dass projekte ganz grundsätzlich garnicht vergleichbar sind. Ist ja auch total subjektiv und das müsste man dann von Fall zu Fall am besten basisdemokratisch entscheiden.
Ich bleib dabei, die Größenordnung kann man damit schon einschätzen, sieht man imo bis jetzt auch an den genannten beispielen (abgesehen von den leicht unkonkreten "einigen Projekten", die du jetzt ins Spiel gebracht hast). Alles was weniger als Faktor 5 auseinander liegt würde ich nicht ordnen wollen, aber bei Faktor 10 oder mehr wäre ich doch recht zuversichtlich.
-
viel Spaß noch beim Diskutieren
Wie schon geschrieben, der inhärente Wert einer Lösung richtet sich nach der Komplexität des Problems.
in implementationsabhängige Metriken fließt aber die Komplexität der Lösung ein, und die kann fernab der Komplexität einer optimalen Lösung (= Problemkomplexität) liegen.
zum Vergleich:
Kaum jemand würde auf die Idee kommen, einem 6-Stunden-Marathonläufer dreimal so viel Preisgeld zu bezahlen wie einem 2-Stunden-Marathonläufer, obwohl der erstere dreimal so lange "arbeitet".
Der 2-Stunden-Läufer löst ein viel schwierigeres Problem als der 6-Stunden-Läufer, und wird daher zurecht viel besser bezahlt.
-
!rr!rr_. schrieb:
Wie schon geschrieben, der inhärente Wert einer Lösung richtet sich nach der Komplexität des Problems.
in implementationsabhängige Metriken fließt aber die Komplexität der Lösung ein, und die kann fernab der Komplexität einer optimalen Lösung (= Problemkomplexität) liegen.
Ich kann eine Matrix-matrix Multiplikation mit ziemlich genau 4 Zeilen Code schreiben. Das Problem ist nicht komplex. Aber: meine 4 Zeilen Lösung wird in der Praxis gegen die typischen 500+Zeilen Lösungen verlieren. Die Komplexität des Problems selbst ist gering, aber eine effiziente Implementation zu finden ist sehr aufwendig.
-
Aktueller Artikel auf TDWTF passt irgendwie ganz gut zum Thema: http://thedailywtf.com/Articles/The-Percent-Conversion.aspx
-
loks schrieb:
Aktueller Artikel auf TDWTF passt irgendwie ganz gut zum Thema: http://thedailywtf.com/Articles/The-Percent-Conversion.aspx
Ja, für Idioten ist LOC ungeeignet, aber jede andere Metric auch.
PS: Habt ihr nicht auch das Gefühl, dass die hälfte des dailywtf ein Fake ist.
-
poffoldreffer schrieb:
PS: Habt ihr nicht auch das Gefühl, dass die hälfte des dailywtf ein Fake ist.
Die Frage ist nicht unberechtigt da man sich oft denkt: Hey, so dumm kann man doch nicht sein. Und dann hatte ich vorrübergehend einen Mitarbeiter im Team der mich vom Gegenteil überzeugt hat. Der schaffte es auch für die simpelsten Aufgaben Code zu produzieren der immer um den Faktor 10 Umfangreicher war als nötig.
Beispiel:
SQL-Datenbank mit 3 Tabellen: Order, OrderItem, Produkt.
- Zu einer Order gibt es mehrere Orderitens
- In jedem Order-Item steht die ID des Produkt.Aufabe: Liste alle Produkte-Namen einer Order einzeln auf.
Meine Lösung: Ein Select-statement über die Tabellem Produkt und OrderItem.
Seine Lösung: ca 100 Zeilen C#-Code mit mehreren Unterfunktionen, 3 oder 4 Dictionaries und einem Ablauf der so kompliziert war das ich fast einen halben Tag gebraucht habe um zu verstehen was er da versucht hat...
-
otze schrieb:
!rr!rr_. schrieb:
Wie schon geschrieben, der inhärente Wert einer Lösung richtet sich nach der Komplexität des Problems.
Ich kann eine Matrix-matrix Multiplikation mit ziemlich genau 4 Zeilen Code schreiben. Das Problem ist nicht komplex. Aber: meine 4 Zeilen Lösung wird in der Praxis gegen die typischen 500+Zeilen Lösungen verlieren.
dann mußt du die Metrik so modifizieren, daß sie deine Ansprüche widerspiegelt, etwa:
90% * Laufzeiteffizienz + 9% * #sLOC + 1% * #Kaffee
-
Jester schrieb:
Ich will einfach nur feststellen, ob ein Projekt deutlich größer ist als ein anderes. Projekte die nah aneinander sind kann ich damit nicht vergleichen und enthalte mich daher einer Aussage.
Mein Punkt ist: Wenn du größer als "mehr LOC" definierst, dann klappt das natürlich. Ansonsten muss der Code recht ähnlichen Abstraktionsgrad haben, ähnliche Libraries benutzen, in einer ähnlichen Programmiersprache geschrieben sein, uvm.
Ich habe gerade erst letzte Woche knappe 3000 unnötige Zeilen dummen Java-Code geschrieben, der nur deswegen nötig war, weil mein Analysetool unbedingt ein Plug-In für ein anderes Tool werden musste (dabei keine zusätzlichen Library-Dependencies zum Projekt hinzufügen durfte) und nicht ein Matlab/Octave-Tool bleiben durfte (wie mein ~400zeiliger Prototyp es war). Zugegeben, die Java-Variante hat auch ein bisschen mehr Errorhandling, aber ich bin sicher, dass ich den Matlab-Prototypen noch aufräumen hätte können und samt Doku unterm Strich bei <=500 Zeilen geblieben wäre.
Versteh mich nicht falsch; unterm Strich betrachtet war die Aktion vmtl. für dieses Projekt sogar sinnvoll. Als reiner Java-Shop will man sich einfach keinen Code in irgendwelchen exotischen Non-Java-Sprachen einfangen, den man dann warten muss. Und dank Eclipse und dem Matlab-Prototypen war die Arbeit für mich auch recht einfaches Abtippen (und von Zeit zu Zeit Refaktorisieren), das nicht allzuviel Zeit (und somit Geld) gekostet hat.
Ein anderes Beispiel ist eine Firma, bei der ich letztes Jahr war. Die wollten von einem RDBMS auf ein anderes umstellen. Konnten mir allerdings nicht sagen, wieviele ihrer Stored Functions eigentlich noch in Verwendung sind. Nach einem halben Jahr Logging und ein paar Wochen Arbeit eines Praktikanten wussten wir dann: Knapp die Hälfte ist toter Code. Der aber natürlich die LOC gewaltig nach oben trieb.
Aber okay, wir können natürlich auch sagen, dass projekte ganz grundsätzlich garnicht vergleichbar sind. Ist ja auch total subjektiv und das müsste man dann von Fall zu Fall am besten basisdemokratisch entscheiden.
Nein, das vergleichen an sich finde ich ja sehr spannend. Aber normalerweise vergleiche ich, weil ich mir ein Bild von der Komplexität machen möchte. Davon, wie schwierig es wäre, etwas auszutauschen. Davon, wieviele Leute bis jetzt daran verschlissen wurden, wieviele Leute sich mit dem Code auskennen, wieviele Leute es weiterhin brauchen wird, um eine Library vernünftig zu erweitern, wieviel Aufräumarbeiten nötig sind, um auch projektfremde Leute effektiv daran arbeiten zu lassen, etc.
Das sind doch alles Aufgaben, denen man ständig begegnet. Aber keine mir bekannten Metriken helfen dabei sehr gut.
Klar, solange du zB. ausschließlich simple .net-GUI-Projekte mit ein bisschen Business-Logik in C# miteinander vergleichst, wird in der Regel die LOC-Sache größenordnungsmäßig recht gut funktionieren. Aber wenn sich die Projekte stärker unterscheiden, wird sowas wirklich schwierig.
Alles was weniger als Faktor 5 auseinander liegt würde ich nicht ordnen wollen, aber bei Faktor 10 oder mehr wäre ich doch recht zuversichtlich.
Faktor 10 funktioniert mit einigen Einschränkungen (siehe oben) vmtl. Aber wenn Anfänger in Programmierforen nach LOC fragen und selbige vergleichen, dann ist zumindest eine dieser Einschränkungen definitiv verletzt. Wir haben doch in jungen Teenagerjahren alle wochenlang pro Tag Tausend Zeilen dummen Code produziert und waren dann sehr stolz auf unsere Projekte, die zigtausend Zeilen Source-Code toll waren. (Nicht? Vielleicht war das auch nur eine Krankheit bei mir und in meinem damaligen Umfeld.
)
-
@nman: ich seh das aber nicht als Gegenbeispiel. Das war eben Teil der Anforderung und damit nötig. Du hast ja nicht gesagt, dass du 3000 Zeilen überflüssigen Codes geschrieben hast. Der Code war nötig, um die gestellte Aufgabe zu lösen. Nicht das Kernproblem der Aufgabe, sondern die ganze Aufgabe. Und wenn es nötig ist, ist es eben nötig. Sonst könntest du auch sagen, ich hab das Problem in 100 Zeilen gelöst, aber weil der dumme Benuter ein Programm mit GUI haben wollte, und auch noch das Ergebnis sehen wollte, musste ich 5000 Zeilen schreiben. Alle Rahmenbedingungen gehören dazu.
Interoperabilität ist ein häufiges Problem und ich geh bei den meisten größeren Projekten davon aus, dass es dazugehört. Und das ist oft nicht der Teil, wo viel Code prodziert wird. So ein Problem hatte ich heute. Habe den ganzen Tag debuggt, und am Ende eine einzige Zeile geschrieben, die für die Lösung des Problems nötig war.
Außerdem bin ich immer noch der Meinung, dass bei vielen Codezeilen viele Argumente gegen die LOC Metrik zumindest abgeschwächt werden. Was spielt es bei einem Multimillionen Zeilen Projekt noch für eine Rolle, ob jemand die Matrizenmultiplikation in 100 oder 500 Zeilen gelöst hat? Irgendwo wird es Codestellen geben, die viel zu viel Code enthalten, andere Stellen werden sehr elegant und kompakt sein. Und zwar bei jedem großen Projekt, somit sind sie wieder vergleichbar
-
loks schrieb:
poffoldreffer schrieb:
PS: Habt ihr nicht auch das Gefühl, dass die hälfte des dailywtf ein Fake ist.
Die Frage ist nicht unberechtigt da man sich oft denkt: Hey, so dumm kann man doch nicht sein.
Ne, bei dem Code fällt mir auf, dass Early Out verwendet wird, was man bei so schlechten Programmierern selten findet. Und der Code schaut einfach viel zu generiert aus.
-
poffoldreffer schrieb:
Ne, bei dem Code fällt mir auf, dass Early Out verwendet wird, was man bei so schlechten Programmierern selten findet. Und der Code schaut einfach viel zu generiert aus.
paid by the line nennt man das dann wohl.