nicht angemeldet
Effizient Programmieren
0 0 1 0 0 2 0 0 
Der Martin
2
0 
MudGuard
1
Effizient Programmieren
Hi,
ich suche Fachbegriffe zum Thema. Lines of Code (LOC) habe ich schon gefunden und LOC/Zeiteiheit wäre z.B. ein Faktor, was die Produktivität bestimmt. Da gibts bestimmt noch mehr Faktoren, für eine gezielte Suche fehlen mir die Fachbegriffe, habt Ihr da ein paar?
Hotti
--
Ein Drama ist eine Handlung, die nicht so ausgeht, wie wirs gerne hätten.
Ein Drama ist eine Handlung, die nicht so ausgeht, wie wirs gerne hätten.
-
Testabdeckung fiele mir da so ein.
Bei Scrum nimmt man die Anzahl der Storypoints / Sprint, die ein Team bearbeitet hat, um dessen Performance zu messen (velocity).
Hope thal helps,
Viele Grüße,
Jörg-
Danke Jörg, das bring mich schon weiter!
-
Testabdeckung fiele mir da so ein.
Das ist meiner Erfahrung nach keine sinnvolle Maßeinheit. Das führt mit hoher Wahrscheinlichkeit zu schlechten Tests und Code under Test, der sich nicht für das Testing eignet aber trotzdem getestet wird. Nur damit eben die Abdeckung gesteigert wird.
-
Testabdeckung fiele mir da so ein.
Das ist meiner Erfahrung nach keine sinnvolle Maßeinheit. Das führt mit hoher Wahrscheinlichkeit zu schlechten Tests und Code under Test, der sich nicht für das Testing eignet aber trotzdem getestet wird. Nur damit eben die Abdeckung gesteigert wird.
Du hast recht, als absolutes Maß sicher nicht sinnvoll.
Allerdings finde ich Testabdeckung als unscharfes Kriterium für die Code-Qualität schon wichtig. Ab einer bestimmten Untergrenze (die sicher von Anwendung zu Anwendung verschieden ist), ist eine sehr geringe Testabdeckung ein ziemlich sicheres Indiz dafür, dass der vorhandene Code nicht ausrecihend automatisiert testbar ist.Das Steigern der Testabdeckung auf Teufel-komm-raus um einen bestimmten (meist völlig willkürlich festgelegten) Wert zu erreichen, ist natürlich Quatsch.
-
-
-
Lines of Code (LOC) habe ich schon gefunden und LOC/Zeiteiheit wäre z.B. ein Faktor, was die Produktivität bestimmt.
Ich hoffe ja nicht.
Wenn es so wäre würd ich nach Produktivität bezahlt werden wollen und nur gedankenlos irgendwelchen unperformanten und nicht durchdachten Code rein hacken. -
Hi,
meiner Ansicht nach ist eine solche Bewertung nicht nur Blödsinn, sondern auch noch kontraproduktiv. Warum sollte man soetwas tun?
Wenn man es doch tun möchte, könnte man bspw. auch die Anzahl der Bugs miteinbeziehen, die (in einem definierten Zeitraum) produziert wurden. Interessant wäre auch, die Zeit die für Refactoring genutzt wird, zu messen.
Allerdings führen alle diese Messungen, unabhängig vom gemessenen Faktor, sicherlich dazu, dass schlechter programmiert wird als zuvor.
LoC ist (in einem Scrum-Projekt auf jeden Fall) keine sinnvolle Maßeinheit. Oftmals müssen bestehende Funktionalitäten geändert werden, was dazu führt, dass durchaus ein Mehrwert generiert aber die Anzahl der LoC nicht merklich verändert wurde.
Viele Grüße
-
hi,
meiner Ansicht nach ist eine solche Bewertung nicht nur Blödsinn,
Ja, vieles ist Blödsinn ;)
Meine Frage bleibt und ich präzisiere die mal so:
"Was versteht ein Unternehmer(*) unter Produktivität"*Chef einer Softwareschmiede.
Hotti
-
Meine Frage bleibt und ich präzisiere die mal so:
"Was versteht ein Unternehmer(*) unter Produktivität"*Chef einer Softwareschmiede.
Oh Gott du hast schon so gut wie verloren...
Da muss eine wasserdichte Erklärung her warum es Mist ist.
Zum Beispiel:
Ist ein verkauftes Gerät besser, nur weils mehr Teile hat und dafür mehr kaputt gehen kann?
Kauft man lieber teuere gleichwertige Rohstoffe (und dafür das Endprodukt teurer), damit man mit mehr Umsatz protzen kann?
Ist ein schwereres Gerät besser, weil man es für höhere Windstärken als Türstopper nehmen kann? -
Meine Frage bleibt und ich präzisiere die mal so:
"Was versteht ein Unternehmer(*) unter Produktivität"*Chef einer Softwareschmiede.
Den interessiert ausschließlich das Geld. Also wie viel Geld musste ich in die Hand nehmen um Produkt X zu entwickeln, das mir dann den Umsatz Y einbringt (Stichwort ROI). Ob die Testabdeckung 80 oder 10% beträgt oder 20% mehr LoC als durchschnittlich in der Zeit erstellt wurden, ist dem Unternehmer egal.
Insofern ist deine Frage nicht wirklich an die Programmierung gekoppelt, da der betriebswirtschaftliche Erfolg nicht mit der Qualität des Codes korreliert.
Ich gehe davon aus, dass die Effizienz, mit welcher programmiert wird, nicht sinnvoll messbar ist.
Viele Grüße
-
hi,
Ich gehe davon aus, dass die Effizienz, mit welcher programmiert wird, nicht sinnvoll messbar ist.
Ja, ok, danke.
Mich interessiert neben der Messbarkeit, welche Faktoren die Effizienz aus der Sicht eines Unternehmers bestimmen bzw, wie diese Faktoren fachbegrifflich definiert sind.
Viele Grüße,
Hotti-
Hallo,
Ich gehe davon aus, dass die Effizienz, mit welcher programmiert wird, nicht sinnvoll messbar ist.
naja, nicht direkt. Man kann aber den Aufwand, der zur Entwicklung des Produkts nötig war, zu dem Aufwand ins Verhältnis setzen, der für Reklamationen und Support-Anfragen draufgeht. Das könnte IMO durchaus ein Qualitätsmaßstab sein. Leider nur rückwirkend.
Ciao,
Martin--
Die meisten Menschen werden früher oder später durch Computer ersetzt.
Für manche würde aber auch schon ein einfacher Taschenrechner genügen.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:( -
Moin,
Stichwort zyklomatische Komplexität oder Wartbarkeitsindex. Da gab's hier im Forum auch mal eine Diskussion drüber (2010 oder so).
-
-
-
-
-
Hi,
ich suche Fachbegriffe zum Thema. Lines of Code (LOC) habe ich schon gefunden und LOC/Zeiteiheit wäre z.B. ein Faktor, was die Produktivität bestimmt.
Naja.
Bei den meisten Sprachen kann man zwischen den Token beliebigen Whitespace einfügen - also auch Zeilenumbrüche.Wenn ich in derselben Zeit statt
if (x == y)
also
if
(
xy
)
schreibe, bin ich dann 6mal so produktiv? Ich hab ja 6mal soviele Zeilen/Zeiteinheit erzeugt ...Oder wenn jemand zig Zeilen Code zusammenfummelt, wo ein anderer einfach einen Aufruf einer lang-bewährten Methode aus irgendeiner Standard-Library hinschreibt, wer ist dann produktiver?
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
Hi,
Lines of Code (LOC) habe ich schon gefunden und LOC/Zeiteiheit wäre z.B. ein Faktor, was die Produktivität bestimmt.
D.h. mit besonders viel Copy & Paste ist ein Entwickler besonders produktiv? Gruselig. Obwohl es tatsächlich Vorgesetzte gibt, die genau so denken. Die glauben auch, wenn ein Entwickler gerade mal nicht auf der Tastatur klappert und Zeilen erzeugt, dann arbeitet er nicht.
Ohne eine Betrachtung der verbleibenden Bugs bleibt die Produktivität von SW-Erstellung wohl sinnlos. Ein Anhaltspunkt dafür könnten z.B. auch die Fehler und Hinweise sein, die ein Tool wie Lint noch aufzeigt.
Betriebswirtschaftlich betrachtet ist ja fehlerloser Code vielleicht gar nicht immer wünschenswert... Wenn ich ein Produkt verkaufe, werden Fehler darin durch Garantie-Ansprüche auf mich zurück fallen. Oder - wenn es denn Konkurrenz gibt - durch zukünftigen Kunden-Schwund. Aber bei manchen Dienstleistern dagegen hat man latent das Gefühl, dass sie sich durch schlampige Programmierung und Bugs die zukünftigen Aufträge sichern...
Gruss
Stefanie