C/C++ Forum :: Projektgrösse

Unregistrierter

Hallo

Ich arbeite derzeit an einem Job Portal und dieses Projekt umfasst ca. 20 Klassen und einige Funktionen. Irgendwie habe ich fast das Gefühl, als wären 20 Klassen nicht gerade viel für eine Jobbörse und da frage ich mich natürlich, habe ich den Software Entwurf sauber und vollständig gemacht? Ich denke ja eigentlich schon. Später poste ich gerne mal ein Klassen-Diagramm von dem Projekt.

Was denkt Ihr? Aus wie vielen Klassen besteht wohl Monster, JobScout24 und co.? Bei meinem Projekt finde ich einfach keine Unterteilungen mehr und daraus entstanden dann die 20 Klassen aus dem Software Entwurf. Danke für Euer Feedback.

Unregistrierter

also ich rechne immer in büchern... 30ksloc wären dann bei mir eins. das ist bei mir dann schon ein etwas größeres projekt!

KingKarl

Unregistrierter

unkommentiert versteht sich

Unregistrierter

Wie witzig. Wäre nett wenn sich nur ernsthafte Postings sammeln. Danke.

Unregistrierter

sach mal bist du doof?

10ksloc => klein
20ksloc => mittel
30ksloc => groß

jetzt ordne deine 20 klassen ein, kasper :rolleyes:

Unregistrierter

Verzeihnung der Herr, dass mir das Kürzel ksloc noch nicht geläufig war. Dennoch bezieht sich meine Frage nicht auf die Anzahl Source Lines, sondern auf die Anzahl Klassen, um so feststellen zu können, dass ich entweder alles richtig gemacht habe, oder meinen Entwurf nochmals überdenken sollte.

Unregistrierter

am besten lässt du es bleiben! es gibt unzählige seiten, wenn du dir solche fragen stellst und diese auch noch hier im forum breittreten musst, kann ich mir kaum vorstellen, dass deine qualitativ besser ist.

Unregistrierter

Deine Überheblichkeit brauche ich bestimmt nicht. Daher würde ich es begrüssen, wenn Du Dich von diesem Thread einfach fern hälst und die Antworten den Leuten überlässt, die nicht so Arrogant sind wie Du. Danke.

Unregistrierter 13:41:09 29.01.2012 Titel:

Ich denke mal deine Frage lässt sich objektiv schwer beantworten. Für mich sind kleine Projekte immer die die jemand auch Alleine stemmen kann, das können aber auch Webprojekte mit 100 Klassen sein, denn ein Framework wie z.B. Zend bringt schon einiges an Klassen mit.

Minecraft zum Beispiel wurde wiederum nur von einem Einzelnen programmiert, aber ich würde es gefühlsmäßig zwischen klein und mittel einordnen.

Facebook z.B. war anscheinend ein sehr kleines Projekt da der Kern innerhalb weniger Stunden realisiert wurde. Ich denke hier ist die Schwierigkeit weniger die Lines of Code sondern eher Datenbank-/Serverarchitektur.

Vielleicht gibt es für dich eine Möglichkeit, bei den ganzen OpenSource Portalen eine Statistik über z.B. Klassenanzahl herauszufinden und damit kannst du dann dein Projekt vergleichen.

cooky451 Mitglied 14:11:05 29.01.2012 Titel:

Was interessiert dich denn die Klassenzahl? Wenn du es mit weniger Klassen schaffst, und diese nicht völlig überladen sind, ist doch alles in Butter. Einfacher Test: Geh zur Konkurenz, überlege für alle Features die dein Framework nicht hat aber irgendwann man brauchen könnte, ob man sie implementieren kann ohne das ganze Design umzuwerfen.

Mechanics Mitglied 17:07:15 29.01.2012 Titel:

Ich kann dir sagen was wir in der Arbeit schreiben: etwas über 15 000 Klassen, über 6 Millionen Zeilen Code. Das nur C+++, dazu kommt noch ein ganzer Haufen anderer Sprachen...
Ich selbst schätze das Projekt als mittelgroß ein. Kommt an die ganze großen Projekte, wie Open Office oder Visual Studio nicht ganz heran.

Unregistrierter

Mechanics schrieb:

Das nur C+++...

Ist das deutlich besser als C++?

Unregistrierter

Mechanics schrieb:

Ich kann dir sagen was wir in der Arbeit schreiben: etwas über 15 000 Klassen, über 6 Millionen Zeilen Code. Das nur C+++, dazu kommt noch ein ganzer Haufen anderer Sprachen...
Ich selbst schätze das Projekt als mittelgroß ein. Kommt an die ganze großen Projekte, wie Open Office oder Visual Studio nicht ganz heran.

also wenn 6msloc nicht groß ist, weiß ich auch nicht :rolleyes:

Mechanics Mitglied 18:27:35 29.01.2012 Titel:

Nee, so viel besser als C++ ist C+++ auch nicht

Erst in der Version C++++ wirds wirklich besser

Naja, "wirklich groß" sind für mich als Richtwert die bekannten großen Programme. Und Visual Studio umfasst angeblich 65 Millionen Zeilen Code. Bei Open Office sind es glaub so 15-20 Mio. Also ist unsere Software im Moment noch eine Stufe drunter.

Unregistrierter

Mechanics schrieb:

Ich kann dir sagen was wir in der Arbeit schreiben: etwas über 15 000 Klassen, über 6 Millionen Zeilen Code.

Ist das alles für nur ein Programm? Wie lang kompiliert ihr?

Ethon Mitglied 18:35:44 29.01.2012 Titel:

Mechanics schrieb:

Nee, so viel besser als C++ ist C+++ auch nicht

Erst in der Version C++++ wirds wirklich besser

Naja, "wirklich groß" sind für mich als Richtwert die bekannten großen Programme. Und Visual Studio umfasst angeblich 65 Millionen Zeilen Code. Bei Open Office sind es glaub so 15-20 Mio. Also ist unsere Software im Moment noch eine Stufe drunter.

Jo, Linux 2.6 hatte nichtmal 6msloc, aber das ist ja auch nur ein kleines Projekt.

Mechanics Mitglied 18:36:22 29.01.2012 Titel:

90000.1 schrieb:

Mechanics schrieb:

Ich kann dir sagen was wir in der Arbeit schreiben: etwas über 15 000 Klassen, über 6 Millionen Zeilen Code.

Ist das alles für nur ein Programm? Wie lang kompiliert ihr?

Das könnte man als Programmsuite bezeichnen... Sind mehrere zusammengehörende Programme, die auf denselben Bibliotheken von uns basieren. Alles durchkompilieren dauert so 4 Stunden.

Mechanics Mitglied 18:38:52 29.01.2012 Titel:

Ethon schrieb:

Jo, Linux 2.6 hatte nichtmal 6msloc, aber das ist ja auch nur ein kleines Projekt.

Mittlerweile hat Linux ja 15 Mio Zeilen. Und ich hab gesagt, dass ich unser Projekt als mittelgroß einschätze, nicht klein

Und "Linux 2.6" gibts nicht, es gibt den Kernel. Und außer dem Kernel gibt es bei Linux schon einen ganzen Haufen anderer Programme, ich schätze, eine übliche Installation mit X-Server, KDE, paar Programmen wird es auf über 100 Mio Zeilen bringen.

Unregistrierter

da haben auch paar affen ganz schön geklotzt :cool:

Unregistrierter

Mechanics schrieb:

Und Visual Studio umfasst angeblich 65 Millionen Zeilen Code.

Wo hast Du das gelesen?
VS ist schon ein mächtiges Programm, aber 65 Mio scheinen mir arg übertrieben. Zum Vergleich: Win XP hat laut Wiki gerade mal 45 Mio.

Neee. Glaub ich nicht

nman Moderator 10:20:44 31.01.2012 Titel:

Mechanics schrieb:

Und "Linux 2.6" gibts nicht, es gibt den Kernel.

Doch, gibt es. Linux 2.6 ist der Kernel. In Version 2.6.

Projektgrößen in Zeilen Code zu messen ist… Eigenartig.

pumuckl Moderator 10:53:36 31.01.2012 Titel:

nman schrieb:

Projektgrößen in Zeilen Code zu messen ist… Eigenartig.

In Klassen aber genauso. Ich wüsste so aus dem Stehgreif keine sinnvolle Messgröße. Unterliegt alles alles entweder menschlichen Einflüssen, die naturgemäß subjektiv sind, oder aber Codestil oder anderen Dingen. Ein und das selbe Projekt kann je nach Umsetzung bei einer gegebenen Messgröße sehr unterschiedliche Messungen ergeben.

_Vic_ Mitglied 12:00:18 31.01.2012 Titel:

Ein Mittel zur Aufwandsschätzung im Projektmanagement ist das Function-Point-Verfahren
http://de.wikipedia.org/wiki/Function-Point-Verfahren
Wie der Name vermuten lässt, wird hier der Aufwand anhand der Funktionalität gemessen und nicht anhand der Codezeilen. Dadurch ergibt sich der Vorteil, dass man nicht von der eingesetzten Programmiersprache abhängig ist.

Jester Moderator 12:06:02 31.01.2012 Titel:

nman schrieb:

Projektgrößen in Zeilen Code zu messen ist… Eigenartig.

Findest du? Ich bin fast sicher, dass Unterschiede von 10000 vs. 100000 vs. 6 Mio Zeilen vs. 60Mio Zeilen sich in allen anderen Metriken ebenfalls widerspiegeln. Die Einteilung ist zwar grob, aber für eine erste Einschätzung scheint mr das gut hinzuhauen -- zumindest bei diesen stark unterschiedlichen Größenordnungen.

Funktionspunkte sind zwar nett, aber leider kennt man die hält bei Fremdprojekten nicht, deswegen sind die zum vergleichen nicht so gut geeignet.

_matze Mitglied 12:47:11 31.01.2012 Titel:

Bei uns gibt's um die 600.000 LOC und ca. 3000 Labview-Vi's (allerdings fast alles in einer exe, keine "Programmsuite"). Das sehe ich als mittelgroßes Projekt an. 6 Mio. hört sich schon groß an, ehrlich gesagt.

Dobi Mitglied 13:11:49 31.01.2012 Titel:

_Vic_ schrieb:

Ein Mittel zur Aufwandsschätzung im Projektmanagement ist das Function-Point-Verfahren
http://de.wikipedia.org/wiki/Function-Point-Verfahren
Wie der Name vermuten lässt, wird hier der Aufwand anhand der Funktionalität gemessen und nicht anhand der Codezeilen. Dadurch ergibt sich der Vorteil, dass man nicht von der eingesetzten Programmiersprache abhängig ist.

Interessanter Ansatz, allerdings sieht es für mich ein bischen so aus, als würde man das Kernproblem damit teilweise einfach verschieben:
"Die Functional-Size wird bestimmt, in dem man die funktionalen Anforderungen an eine Anwendung in kleinste, für den Anwender sinnvolle Aktivitäten, die Elementarprozesse, zerlegt. Gleiche Elementarprozesse werden nur einmal gewertet. Jedem Elementarprozess wird ein definierter Punktwert zugeordnet. Die Summe der Punktwerte aller Elementarprozesse ergibt die Functional-Size."
Für den Anwender ist beispielsweise das Gesamtverhalten der Software, an der ich gerade arbeite (Objekterkennung), selbst die kleinste sinnvolle Aktivität. Bild rein -> Erkennungsergebnis raus. Wieviele Punkte gibt man dem nun im Vergleich zu einem zusätzlichen Eingabefeld, in das der Benutzer den Namens seines Haustiers eintragen kann?

Bashar Mitglied 13:25:22 31.01.2012 Titel:

Dobi schrieb:

Für den Anwender ist beispielsweise das Gesamtverhalten der Software, an der ich gerade arbeite (Objekterkennung), selbst die kleinste sinnvolle Aktivität. Bild rein -> Erkennungsergebnis raus. Wieviele Punkte gibt man dem nun im Vergleich zu einem zusätzlichen Eingabefeld, in das der Benutzer den Namens seines Haustiers eintragen kann?

Genau. Diese Function-Points sind für so typische Business-Software mit Eingabemasken und Datenbanken ohne nennenswerte algorithmische Komplexität.

nman Moderator 14:14:21 31.01.2012 Titel:

Jester schrieb:

Die Einteilung ist zwar grob, aber für eine erste Einschätzung scheint mr das gut hinzuhauen -- zumindest bei diesen stark unterschiedlichen Größenordnungen.

Die Frage ist, ob eine Einteilung in "kleine", "mittlere" und "große" Projekte überhaupt irgendwie Sinn macht. Bzw. wozu man die in der Form des Threads hier überhaupt verwenden kann.

Klar kann man Codezeilen zählen; das Problem das ich damit habe ist, dass verdammt viele andere Parameter übereinstimmen müssen, damit die LOC zweier unterschiedlicher Projekte in irgendeiner Form brauchbar vergleichbar sind.

nman Moderator 14:16:25 31.01.2012 Titel:

pumuckl schrieb:

nman schrieb:

Projektgrößen in Zeilen Code zu messen ist… Eigenartig.

In Klassen aber genauso.

Klar, absolut. Häufig sogar noch eigenartiger.

Unregistrierter 18:37:46 31.01.2012 Titel:

Die Anzahl Klassen/LOC machen z.B. wenig bis überhaupt keinen Sinn wenn man ewig an dem Knowhow gegrübelt hat und mit viel Manpower über Jahre dann unter dem Strich in "wenig" LOG oder Klassen gepackt hat. Wie z.B 3D-Engines, Datenbanken und so weiter und so fort.

EDIT: Wie viel legacy code unter Klassen/LOG zu finden sind müsste auch für einen guten Vergleich bekannt sein.

Unregistrierter

nman schrieb:

Projektgrößen in Zeilen Code zu messen ist… Eigenartig.

Was ist besser?

Dobi Mitglied 21:09:52 31.01.2012 Titel:

RAM-Verbrauch.

Unregistrierter

Mannjahre

noch besser: Problemkomplexität desjenigen Problems, dessen Lösungsimplementation das Projekt ist. Aber dazu müßte man erstmal die Problemkomplexität des zugrundeliegenden Problems kennen, und das ist bisher nur in wenigen Fällen gelungen (Sortierprobleme, boolesche netze ...)

Dobi Mitglied 21:19:42 31.01.2012 Titel:

!rr!rr_. schrieb:

Mannjahre

Auch schwierig, weil manche Männer einfach Jahre für Kleinkram brauchen während andere in der selben Zeit spektakuläre Welten aufbauen.
Um das loszuwerden könnte man nicht die tatsächlich gebrauchten Mannjahre nehmen sondern die Zeit, die viele Entwickler aus verschiedenen Bereichen durchschnittlich als Entwicklungszeit dafür schätzen würden wenn sie es selbst machen müssten.
Mal abgesehen davon, dass man dafür viele Entwickler braucht, die alle drüber nachdenken, um eine Schätzung abgeben zu können, hätte man dann wieder das Problem, dass manche Themen vielleicht tendentiell eher unterschätzt und andere tendentiell eher überschätzt werden.

otze Mitglied 23:01:48 31.01.2012 Titel:

Dobi schrieb:

Um das loszuwerden könnte man nicht die tatsächlich gebrauchten Mannjahre nehmen sondern die Zeit, die viele Entwickler aus verschiedenen Bereichen durchschnittlich als Entwicklungszeit dafür schätzen würden wenn sie es selbst machen müssten.

Abre es kann sein, dass a-posteriori Projekte am Code geschätzt als sehr schnell implementierbar gelten "sind ja nur 10000 Zeilen Code", aber hinter dem Projekt a-priori ein Problem steckt, für dessen Lösung enorm viel Denkleistung rein gesteckt werden musste.

Der langsame Programmierer könnte am Ende dann doch der sein, der das Gesamtprojekt von Problemstellung bis Programmierung am Schnellsten hin kriegt.

Jester Moderator 23:05:40 31.01.2012 Titel:

!rr!rr_. schrieb:

noch besser: Problemkomplexität desjenigen Problems, dessen Lösungsimplementation das Projekt ist. Aber dazu müßte man erstmal die Problemkomplexität des zugrundeliegenden Problems kennen, und das ist bisher nur in wenigen Fällen gelungen (Sortierprobleme, boolesche netze ...)

Wieso sollte ausgerechnet das ein gutes Maß sein? Es gibt Probleme, die lassen äußerst effiziente Algorithmen zu, aber implementieren möchte ich die auf keinen Fall. Mir scheint, das ist kein geeignetes Maß.

Unregistrierter

ich bin mittlerweile an dem punkt, wo ich mich einfach freu, wenn mein derzeitiges 'projekt' fertig ist/wird. es ist so verzwickt, hätt ichs nur mit php gemacht, wär ich schon 10 mal fertig

und das ohne komplexität, besondere algorithmen oder eine neue idee :rolleyes:

Mechanics Mitglied 23:18:44 31.01.2012 Titel:

Ich finde, wenn ein Projekt ausreichend "groß" ist, dann gleichen sich die Metriken meist aus... Es ist davon auszugehen, dass in jedem großen Projekt sowohl hochkomplexe Algorithmen sind, die bei wenigen Codezeilen sehr viel Zeit und Hirnschmalz in Anspruch nehmen, als auch viel Code, den man einfach runtertippt und dabei zehntausende von Programmzeilen produziert. Haben wir zumindest in unserem Projekt. Bei meinem Projekten ist es auch meist so, dass die zeilenmäßig größten Teile nicht die meiste Zeit brauchen. Ich kann Klasse mit 1000 Zeilen Code oder mehr an einem Tag runtertippen, aber es gibt auch Tage, da suche ich einfach einen Bug und ändere dabei eine einzige Zeile, oder ich überlege mir eine Lösung für einen Sonderfall.

dot Mitglied 23:19:06 31.01.2012 Titel:

Bill Gates schrieb:

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

Unregistrierter

Jester schrieb:

!rr!rr_. schrieb:

noch besser: Problemkomplexität desjenigen Problems, dessen Lösungsimplementation das Projekt ist.

Mir scheint, das ist kein geeignetes Maß.

wieso? Der Wert einer Lösung richtet sich nach der inhärenten Schwierigkeit des Problems.

Das ist der Idealfall.

Dobi Mitglied 14:43:27 01.02.2012 Titel:

Dann musst du halt ne Metrik für Problemkomplexität erfinden.

Etwas, womit alle zufrieden sind, wird sich hier vermutlich eh nicht finden lassen. Vielleicht bevorzugen einige von uns ja eh die Metrik, in der sie selbst mit ihrem Projekten am besten abschneiden würden.

Selbst sich auf ein Mittelwertsverfahren zur Kombination vieler Metriken zu einigen, könnte ziemlich schwierig werden.

nman Moderator 14:48:41 01.02.2012 Titel:

hustenkuchen schrieb:

nman schrieb:

Projektgrößen in Zeilen Code zu messen ist… Eigenartig.

Was ist besser?

Für Schwanzlängenvergleiche in Programmierforen? Dafür passen sowohl Codezeilen als auch Klassenanzahl ganz gut. Besonders wenn man dann noch Binning über die LOC macht, um in "klein", "mittel" und "groß" einzuteilen.

Ansonsten ist es interessanter, sich anzusehen zu welchem Zweck überhaupt die Projektgröße gecheckt werden soll. Eine sinnvolle Metrik, mit der man jedem fachfremden BWLer ein paar hübsche Diagramme in die Hand drücken kann und damit dann ein brauchbares Bild der Projektgröße vermittelt, gibt es wohl kaum.

Unregistrierter

nman schrieb:

hustenkuchen schrieb:

nman schrieb:

Projektgrößen in Zeilen Code zu messen ist… Eigenartig.

Was ist besser?

Für Schwanzlängenvergleiche in Programmierforen? Dafür passen sowohl Codezeilen als auch Klassenanzahl ganz gut. Besonders wenn man dann noch Binning über die LOC macht, um in "klein", "mittel" und "groß" einzuteilen.

Ansonsten ist es interessanter, sich anzusehen zu welchem Zweck überhaupt die Projektgröße gecheckt werden soll. Eine sinnvolle Metrik, mit der man jedem fachfremden BWLer ein paar hübsche Diagramme in die Hand drücken kann und damit dann ein brauchbares Bild der Projektgröße vermittelt, gibt es wohl kaum.

Zuerst so tun, als ob es eigenartig ist und du das beurteilen kannst, weil du anscheinend was besseres weißt und dann kommt doch nur raus, dass du auch nix weißt, außer dass man LOC eigenartig finden muss... :rolleyes:

nman Moderator 10:55:14 02.02.2012 Titel:

hustenkuchen schrieb:

Zuerst so tun, als ob es eigenartig ist und du das beurteilen kannst, weil du anscheinend was besseres weißt

Das ist eine interessante Interpretation meines Posts. Ich brauche keine bessere Idee zu haben, um eine schlechte Idee zu erkennen.

Vielleicht ist es einfach eine dumme Idee, zu versuchen so etwas kompliziertes wie die Frage wieviel Arbeit bereits in einem Projekt steckt und wieviel man noch hineinstecken muss, in eine einzelne Zahl packen zu wollen, die auch fachfremde Menschen leicht verstehen und vergleichen können. Nein, Moment, du hast natürlich Recht, das kann es doch nicht sein…

Unregistrierter

nman schrieb:

hustenkuchen schrieb:

Zuerst so tun, als ob es eigenartig ist und du das beurteilen kannst, weil du anscheinend was besseres weißt

Das ist eine interessante Interpretation meines Posts. Ich brauche keine bessere Idee zu haben, um eine schlechte Idee zu erkennen.

Vielleicht ist es einfach eine dumme Idee, zu versuchen so etwas kompliziertes wie die Frage wieviel Arbeit bereits in einem Projekt steckt und wieviel man noch hineinstecken muss, in eine einzelne Zahl packen zu wollen, die auch fachfremde Menschen leicht verstehen und vergleichen können. Nein, Moment, du hast natürlich Recht, das kann es doch nicht sein…

Darum, wieviel Zeit man noch reinstecken muss, gings nie. Aber egal, schon ab deinem Post mit dem Schwanzlängenvergleich hätte man dich ignorieren sollen.

nman Moderator 22:28:56 02.02.2012 Titel:

hustenkuchen schrieb:

Darum, wieviel Zeit man noch reinstecken muss, gings nie.

Nein, es ging um überhaupt nichts. Aber irgendwelche Metriken ohne Einsatzzweck definieren zu wollen, ist einfach nicht sinnvoll.

Jester Moderator 22:36:55 02.02.2012 Titel:

!rr!rr_. schrieb:

Jester schrieb:

!rr!rr_. schrieb:

noch besser: Problemkomplexität desjenigen Problems, dessen Lösungsimplementation das Projekt ist.

Mir scheint, das ist kein geeignetes Maß.

wieso? Der Wert einer Lösung richtet sich nach der inhärenten Schwierigkeit des Problems.

Das ist der Idealfall.

Einfache Polygone kann man in Linearzeit triangulieren, das wäre also ein leichtes Problem nach dieser Definition. Sortieren wäre dagegen schon ein bißchen schwerer. Wenn du Lust hast, dann kannst du dir ja mal das triangulierungspaper vonnchazelle anschauen, sind so ca. 40 Seiten und ich glaub nicht, dass das jemals jemand versucht hat zu implementieren. Aber entscheide selbst, was das größere Projekt ist, sortieren (zB mit Quicksort) oder die triangulierung.

Zumindest meine persönliche Einschätzung der Schwierigkeit und des Umfangs dieser Unterfangen sind der Problemkomplexität im algorithmischen Sinne diametral entgegengesetzt.

Jester Moderator 22:40:43 02.02.2012 Titel:

nman schrieb:

Klar kann man Codezeilen zählen; das Problem das ich damit habe ist, dass verdammt viele andere Parameter übereinstimmen müssen, damit die LOC zweier unterschiedlicher Projekte in irgendeiner Form brauchbar vergleichbar sind.

Es geht aber um eine Ordnung, nicht um ein direktes vergleichen. Welche Parameter sorgen denn deiner Meinung nach dafür, dass ich mich bei der Einschätzung, dass ein 100k Zeilen Projekt kleiner ist als ein 6 Mio Zeilen Projekt ist, verhaue?

Jester Moderator 22:44:09 02.02.2012 Titel:

nman schrieb:

hustenkuchen schrieb:

Darum, wieviel Zeit man noch reinstecken muss, gings nie.

Nein, es ging um überhaupt nichts. Aber irgendwelche Metriken ohne Einsatzzweck definieren zu wollen, ist einfach nicht sinnvoll.

Doch, es ging darum Projekte grob der Größe nach zu ordnen. Versuchst du grad dich in eine metadiskussion zu retten?

Dobi Mitglied 22:45:27 02.02.2012 Titel:

Ich glaube, ein Problem ist, dass viele befürchten, dass die bösen Schlipsträger sofort anfangen würden, irgendeine Metrik, auf die man sich als Entwickler einlässt, in Geld umzurechnen.

Unregistrierter

Jester schrieb:

Welche Parameter sorgen denn deiner Meinung nach dafür, dass ich mich bei der Einschätzung, dass ein 100k Zeilen Projekt kleiner ist als ein 6 Mio Zeilen Projekt ist, verhaue?

Es
ist
ja
die
Frage
wie
genau
die
Zeilen
denn
aufgebaut
sind.
Wann
immer
in
der
Vergangenheit
Manager
auf
die
dumme
Idee
gekommen
sind
Entwickler
nach
der
Anzahl
geschrieber
Zeilen
zu
bezahlen
haben
Programmierer
ihrerseits
schnell
Wege
gefunden
möglichst
viele
Zeilen
zu
produzieren.
Loop
Unrolling
FTW!

otze Mitglied 23:00:31 02.02.2012 Titel:

Dobi schrieb:

Ich glaube, ein Problem ist, dass viele befürchten, dass die bösen Schlipsträger sofort anfangen würden, irgendeine Metrik, auf die man sich als Entwickler einlässt, in Geld umzurechnen.

Das Problem ist, dass die bösen Schlipsträger nicht raffen, dass ich meinen Output bequem auf die Metrik anpassne kann um meinen Geld/Aufwand Quotienten zu maximieren.

Auf TDWTF findet man ab und zu das Resultat solcher tollen Stories. Wie zum Beispiel der Schlipsträger, der SVN-Commits für eine brauchbare Metrik hielt. Auf einmal hatte der SVN-Server nachts eine rege Aktivität zu verzeichnen die sich daraufhin begründete, dass Commits Wort für Wort einzeln durchgeführt wurden.

nman Moderator 23:11:21 02.02.2012 Titel:

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?

Zitat:

Welche Parameter sorgen denn deiner Meinung nach dafür, dass ich mich bei der Einschätzung, dass ein 100k Zeilen Projekt kleiner ist als ein 6 Mio Zeilen Projekt ist, verhaue?

Die Frage ist, zu welchem Zweck du wissen möchtest welches Projekt größer ist. Wieviele Situationen sind dir bis dato in der richtigen Welt begegnet, wo du wissen wolltest, wie groß ein Projekt in Codezeilen ist und wo dich nicht in Wirklichkeit irgendwas anderes interessiert hat.

Und zu deiner Frage: LOC sind so unheimlich stark von Banalitäten wie Programmiersprachen und benutzten Libraries abhängig. Ich hatte es schon mit einigen Projekten zu tun, deren Zeilenzahl um einen Faktor n-zig kleiner war, als die von anderen Projekten und für die mehr Entwickler und Zeit benötigt wurde. Passiert doch ständig, wenn wiedermal irgendwelche Firmen Hunderttausende Zeilen selbstgebastelten Standardlibrary-Ersatz überall hin mitschleifen.

Zitat:

Versuchst du grad dich in eine metadiskussion zu retten?

Kennen wir uns nicht lange genug, um solchen Blödsinn nicht mehr nötig zu haben? Ich wüsste nicht, was ich hier wozu retten sollte. Aber das überrascht dich wohl nicht sonderlich.

Mechanics Mitglied 23:12:14 02.02.2012 Titel:

Jester schrieb:

nman schrieb:

hustenkuchen schrieb:

Darum, wieviel Zeit man noch reinstecken muss, gings nie.

Nein, es ging um überhaupt nichts. Aber irgendwelche Metriken ohne Einsatzzweck definieren zu wollen, ist einfach nicht sinnvoll.

Doch, es ging darum Projekte grob der Größe nach zu ordnen. Versuchst du grad dich in eine metadiskussion zu retten?

Das wird hier etwas zu offtopic. Den Standpunkt von nman kann man durchaus verstehen und der Einwand, dass LOC keine gute Metrik ist, ist auch völlig richtig. Nur braucht man sich an der Diskussion nicht zu beteiligen, wenn es einen nicht interessiert.

Ich persönlich finds durchaus interessant, Projekte größenordnungsmäßig einzuschätzen und die Frage, was große Projekte sind und was nicht, und "wie groß" große Projekte sind hat mich auch beschäftigt, seit ich angefangen habe zu programmieren. Als ich angefangen habe, hatte ich irgendwann ein Projekt geschrieben, das 1500 Zeilen hatte. Ich habe Wochen Arbeit reingesteckt, weil ich keinerlei Erfahrung hatte und erstmal alles austüfteln musste. Ich fand die Codemenge damals sehr beachtlich. Und das war auch die einzige Metrik, die ich mir vorstellen konnte. Dann habe ich von jemandem gehört, der in seiner Firma an einem 20 000 Zeilen Projekt arbeitet und konnte mir so was großes gar nicht vorstellen...
Ich habe in mehreren kleinen Firmen gearbeitet und die meisten Projekte hatten eine Größenordnung 10-50 000 Zeilen. Sowas ist untereinander schwer zu vergleichen. 50 000 Zeilen 0815 Enterprise Anwendung in Java, die fast dasselbe macht wie die anderen Millionen 0815 Enterprise Anwendungen in Java und zu 90% aus Boilerplate besteht, ist nicht besonders anspruchsvoll. Hingegen können 10 000 Zeilen komplexer mathematischer Berechnungen wesentlich anspruchsvoller und aufwändiger sein.
Aber wie ich schon früher geschrieben habe, finde ich, dass es sich bei bestimmten Projektgrößen relativiert. Ein Projekt mit mehreren Millionen Zeilen wird wohl kaum ausschließlich aus hochkomplexen Berechnungen oder ausschließlich aus Boilerplate Code bestehen. Und ich kann mir jetzt kaum ein 100k Zeilen Projekt vorstellen, dass "größer" ist, als ein Multi Millionen Zeilen Projekt. Das ist für mich als Größenordnung durchaus aussagekräftig.

Dobi Mitglied 23:20:54 02.02.2012 Titel:

@otze: lol, zusammen mit copy-pasta-Programmierung kann man da ziemlich gut scoren. Ich kann mir gar nicht vorstellen, dass jemand sowas ernsthaft als Bewertung ansetzt, solche Stories hört man ja aber immer wieder mal. Gut, dass mein Chef (Mathematiker) zwar nicht wirklich programmieren kann, aber zumindest weiß, dass sowas Quatsch ist.

nman Moderator 23:20:55 02.02.2012 Titel:

Mechanics schrieb:

Nur braucht man sich an der Diskussion nicht zu beteiligen, wenn es einen nicht interessiert.

Der Vorwurf stimmt natürlich. Sorry, keine Ahnung, was mich da geritten hat, normalerweise schaffe ich es ganz gut, mich aus Sachen rauszuhalten, die ich uninteressant/dämlich finde.

Unregistrierter

Alles Varianten die mir schon begegnet sind.

Eine Zeile Code

C/C++ Code:
for( int i=0; i < 100; ++i) printf("%d", i);

C/C++ Code:
for( int i=0; i < 100; ++i) printf("%d", i);

C/C++ Code:
for( int i=0; i < 100; ++i) printf("%d", i);

Zwei Zeilen Code

C/C++ Code:
for( int i=0; i < 100; ++i) printf("%d", i);

C/C++ Code:
for( int i=0; i < 100; ++i) printf("%d", i);

C/C++ Code:
for( int i=0; i < 100; ++i) printf("%d", i);

Drei Zeilen Code

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

Vier Zeilen Code

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

Fünf Zeilen Code

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

Sechs Zeilen Code

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

Sieben Zeilen Code

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

C/C++ Code:
for( int i=0; i < 100; ++i) { printf("%d", i); }

Mechanics Mitglied 23:31:17 02.02.2012 Titel:

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.

Jester Moderator 23:48:24 02.02.2012 Titel:

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.

Unregistrierter

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.

otze Mitglied 00:17:17 03.02.2012 Titel:

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

Unregistrierter

Aktueller Artikel auf TDWTF passt irgendwie ganz gut zum Thema: http://thedailywtf.com/Articles/The-Percent-Conversion.aspx

Unregistrierter

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.

Unregistrierter

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

Unregistrierter

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

nman Moderator 10:05:55 03.02.2012 Titel:

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.

Zitat:

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.

Zitat:

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.

)

Mechanics Mitglied 20:50:31 03.02.2012 Titel:

@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

Unregistrierter

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.

otze Mitglied 00:44:11 05.02.2012 Titel:

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.