Hallo,
hat jemand Erfahrungen bezüglich Messen der Programmqualität anhand von Metriken, sowohl für das gesamte Projekt (Afferent/Efferent Coupling, Cohesion etc.) als auch für einzelne Klassen (z. .B. RFT, LCOM, Coupling usw.).
Wie aussagekräftig sind solche Analyseergebnisse im Allgemeinen. Und wie steht es damit in Bezug auf .NET Programme? Sind diese (wenn überhaupt) auch hier anwendbar?
Vielen Dank für Eure Hilfe (im Voraus)
Morrigan
Hallo Morrigan,
hat jemand Erfahrungen bezüglich Messen der Programmqualität
anhand von Metriken, sowohl für das gesamte Projekt
(Afferent/Efferent Coupling, Cohesion etc.) als auch für
einzelne Klassen (z. .B. RFT, LCOM, Coupling usw.).Wie aussagekräftig sind solche Analyseergebnisse im
Allgemeinen. Und wie steht es damit in Bezug auf .NET
Programme? Sind diese (wenn überhaupt) auch hier anwendbar?
Ich halte allgemein nicht viel vom Metriken.
Kommentare:
c = a + b; // addiere a und b und leges es in c ab
Wird zwar al Kommentar gewichtet, bringt aber gar nichts.
Bezeichner:
void machwas(void);
void MachWas(void);
int Machwasanderes(char c);
int diesisteinint;
char unddieseinchar;
Auch hier kann die Metrik nichts über die Lesbarkeit aussagen.
Und hier gerade was konkretes. Wobei ich gerade nicht weiss wie komplex dies beurteilt wird:
#define MesFieldSize(x) ptr->r.flags.Flags.Has##x ? sizeof(ptr->r.##x) : 0;
…
RecSize += MesFieldSize(RlData );
RecSize += MesFieldSize(QdData );
RecSize += GPSFieldSize(GPS );
RecSize += MesFieldSize(Temp );
RecSize += MesFieldSize(Hrel );
RecSize += MesFieldSize(WetTimer);
Wenn man Metriken zuviel Beachtung schenkt, wird der Code nicht lesbarer, sondern es besteht die Gefahr so zu schreiben wie es das verwendete Programm gerade als gut bewertet.
MfG Peter(TOO)
Hallo Peter,
danke für Deine Antwort. Ungefähr den Eindruck habe ich derzeit auch. Vielleicht fällt noch jemanden eine sinnvolle Einsatzmöglichkeit für Metriken ein. Wäre gespannt.
Danke nochmals für Deine Antwort,
Gruß
Morrighan
Hallo Morrigan,
Softwaremetrik ist letzlich der Versuch, die Qualität von Software automatisch messen zu können. Ich zweifle am Erfolg schon deshalb, weil damit selbst menschliche Intelligenz überfordert ist, und ausserdem haben verschiedene Betrachter ganz unterschiedliche Kriterien:
Der Entwickler will seine Software schnell und mit wenig Schreibaufwand zum Funktionieren bringen.
Sein Arbeitsgeber legt Wert darauf, dass die Software auch von jemand anderem gewartet und weiterentwickelt werden kann, bzw. dass bei Bedarf ein grösseres Team die Arbeit fortsetzen kann. Es soll Entwickler geben, die das überhaupt nicht wünschenswert finden.
Der User will eine übersichtliche, intuitive Bedienung und ausreichende Hilfen - das macht dem Entwickler viel Arbeit. Merke „der User ist der natürliche Feind des Programmierers“.
Wie man sieht, widersprechen sich die Anforderungen teilweise diametral. In einem trivialen Umfang können Metriken schon eine Aussage machen, etwa dass ein C+±Programm ohne jeden Kommentar schlecht wartbar ist, aber dafür brauche ich kein Metrik-Programm, dafür genügt ein Blick auf einige Seiten Sourcecode.
Gruss Reinhard
PS zur Bedienung: es wäre schon interessant, wieviel Aufwand anteilig für das eigentliche Problem und wieviel für das Userinterface getrieben wurde, aber dafür fällt mir keine Messmethode ein und der Aufwand allein besagt auch noch nichts über den Erfolg.
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Reinhard,
danke für Deine Antwort. Mir gehts ausschließlich um Metriken, die versuchen Aussagen über maintainabiltiy, reusability und understandability der Klassen und Module machen. Daher auch im Ausgangsposting die entsprechenden Beispiele wie LCOM, Cohesion, Coupling.
Für mich sieht es jedoch wieder nach einem (akademischen) Versuch aus, komplexe Kriterien auf eine Zahl zu reduzieren. Ähnlich wie eine Aufwandschätzung nach LOC oder Function Point. Oder aus dem Nicht-Informatik Bereich die Messung des IQ.
Gruß
M.
Hallo Morrigan,
Softwaremetrik ist letzlich der Versuch, die Qualität von
Software automatisch messen zu können. Ich zweifle am Erfolg
schon deshalb, weil damit selbst menschliche Intelligenz
überfordert ist, und ausserdem haben verschiedene Betrachter
ganz unterschiedliche Kriterien:Der Entwickler will seine Software schnell und mit wenig
Schreibaufwand zum Funktionieren bringen.Sein Arbeitsgeber legt Wert darauf, dass die Software auch von
jemand anderem gewartet und weiterentwickelt werden kann, bzw.
dass bei Bedarf ein grösseres Team die Arbeit fortsetzen kann.
Es soll Entwickler geben, die das überhaupt nicht
wünschenswert finden.Der User will eine übersichtliche, intuitive Bedienung und
ausreichende Hilfen - das macht dem Entwickler viel Arbeit.
Merke „der User ist der natürliche Feind des Programmierers“.Wie man sieht, widersprechen sich die Anforderungen teilweise
diametral. In einem trivialen Umfang können Metriken schon
eine Aussage machen, etwa dass ein C+±Programm ohne jeden
Kommentar schlecht wartbar ist, aber dafür brauche ich kein
Metrik-Programm, dafür genügt ein Blick auf einige Seiten
Sourcecode.Gruss Reinhard
PS zur Bedienung: es wäre schon interessant, wieviel Aufwand
anteilig für das eigentliche Problem und wieviel für das
Userinterface getrieben wurde, aber dafür fällt mir keine
Messmethode ein und der Aufwand allein besagt auch noch nichts
über den Erfolg.
Hallo Reinhard,
danke für Deine Antwort. Mir gehts ausschließlich um Metriken,
die versuchen Aussagen über maintainabiltiy, reusability und
understandability der Klassen und Module machen. Daher auch im
Ausgangsposting die entsprechenden Beispiele wie LCOM,
Cohesion, Coupling.Für mich sieht es jedoch wieder nach einem (akademischen)
Versuch aus, komplexe Kriterien auf eine Zahl zu reduzieren.
Ähnlich wie eine Aufwandschätzung nach LOC oder Function
Point. Oder aus dem Nicht-Informatik Bereich die Messung des
IQ.Gruß
M.
Hallo Morrigan,
ja, die IQ-„Messung“ ist ein guter Vergleich, irgendwie sind die Probleme ja auch verwandt.
Gruss Reinhard
Wenn man Metriken zuviel Beachtung schenkt, wird der Code
nicht lesbarer, sondern es besteht die Gefahr so zu schreiben
wie es das verwendete Programm gerade als gut bewertet.
Hallo Peter, Hallo Morrigan,
diese Aussage spricht ja geradezu für Metriken, die auf Reviews basieren. Also Mensch schaut und berichtet wie gut er versteht. Wenn es um den Geschmack und die Konsistenz eines Joghurts geht, würde niemand fragen wie man das feststellt.
Andere, automatische Metriken können allerdings den Sinn haben Trends zu signalisieren „warum der Joghurt sich im Mund so komisch anfühlt“.
Gruß D.K.
Erstmal Hallo,
Wenn man Metriken zuviel Beachtung schenkt, wird der Code
nicht lesbarer, sondern es besteht die Gefahr so zu schreiben
wie es das verwendete Programm gerade als gut bewertet.Hallo Peter, Hallo Morrigan,
diese Aussage spricht ja geradezu für Metriken, die auf
Reviews basieren. Also Mensch schaut und berichtet wie gut er
versteht. Wenn es um den Geschmack und die Konsistenz eines
Joghurts geht, würde niemand fragen wie man das feststellt.
Aber meiner Freundin schmeckt cremig gerührtes Joghurt und mir nicht.
Ausserdem möchte ich den armen Kerl sehen, der ein 100.000 LOC Programm, das er zuvor noch nie gesehen hat, durch Code Review beurteilen soll.
Andere, automatische Metriken können allerdings den Sinn haben
Trends zu signalisieren „warum der Joghurt sich im Mund so
komisch anfühlt“.
Eben daran zweifle ich. Dass man mit Metriken irgendwas sinnvolles erkennen kann. Ich habe konsequent OO-designete Programme in Metriken schlecht abschneiden sehen, gleich schlecht wie grottenschlechte Programme, bei denen ich erst nach 3 Wochen Wartung das Ausmaß der Misere erkannt habe.
Vielleicht sind bei eventbasierten Anwendungen Metriken nicht adäquat, weil z.B. Eventhandler ja nie explizit durch das Programm aufgerufen werden und damit verschiedene Parameter verfälschen. Gibt es weitere Beispiele?
Gruß D.K.
Gruß
Mo.
Hallo,
ich habe kein Erfahrung mit derartigem. Aber das einzige Kriterium eines Programmierers ist doch:
Wie gut gefällt das Programm meinem Chef? (wobei das auch ein Kunde sein kann - oder beides)
Wie der das nun feststellt, ist doch desen Sache. Wenn er dazu ein Metrikprogramm verwendet, sollte der Programmierer dementsprechend programmieren. Wenn er das Programm ausdruckt und auf eine Waage legt, eben anders. Und wenn der Chef die ersten 3 Seiten nach Kommentaren absucht, die er versteht - dann eben so.
Es kommt überhaupt nicht darauf an, was der Programmierer für wichtig hält. Das Gras muß der Ziege schmecken, nicht dem Bauern.
Gruß
Axel
Hallo,
Aber meiner Freundin schmeckt cremig gerührtes Joghurt und mir
nicht.
Klar, aber um das festzustellen, müßt ihr beide erstmal probieren (und wenn ihr einen wollt der euch beiden schmeckt, dann muß es ein Kompromiß werden, oder zwei verschiedene Sorten)
Die Joghurt Analogie habe ich nur erwähnt um zu zeigen welcher Aufwand in anderen Branchen durchaus betrieben wird um Qualität zu optimieren.
Ausserdem möchte ich den armen Kerl sehen, der ein 100.000 LOC
Programm, das er zuvor noch nie gesehen hat, durch Code Review
beurteilen soll.
Das wäre unzumutbar.
Lösung 1: 100.000 LOC = 100 x 1000 LOC
Lösung 2: Code reviews aufgehängt an zB. im Test gefundenen Fehlern
Eben daran zweifle ich. Dass man mit Metriken irgendwas
sinnvolles erkennen kann. Ich habe konsequent OO-designete
Programme in Metriken schlecht abschneiden sehen, gleich
schlecht wie grottenschlechte Programme, bei denen ich erst
nach 3 Wochen Wartung das Ausmaß der Misere erkannt habe.
Es kommt auf die Metriken an und die Tools die zur Ermittlung eingesetzt werden. Meine Erfahrung ist, daß Tools und Metriken oft nur zur Gewissensberuhigung bzw. Beruhigung des Kunden benutzt werden. Man könnte durchaus auch für toolgesteuerte Metriken bessere Konzepte erarbeiten um mehr rauszuholen. Man muß es aber wollen.
Gruß D.K.
Gruß D.K.
Es kommt auf die Metriken an und die Tools die zur Ermittlung
eingesetzt werden. Meine Erfahrung ist, daß Tools und Metriken
oft nur zur Gewissensberuhigung bzw. Beruhigung des Kunden
benutzt werden. Man könnte durchaus auch für toolgesteuerte
Metriken bessere Konzepte erarbeiten um mehr rauszuholen. Man
muß es aber wollen.
Ja, das Gefühl habe ich auch, leider habe ich gerade ein Programm, das sowohl beim Test, beim Überarbeiten und bei der Metrik (NDepend) grottenschlecht abschneidet. Ein anderes ist vom Kunden abgenommen (der ist zufrieden, also nicht „abgenommen aus Resignation“) es ist leicht zu warten und schneidet in der Metrik genauso schlecht ab. Daher meine Frage.
lg
Mo.