Group: Java-Entwicklung

Wird ihr Quellcode auf ihre Qualität überprüft?
Nach dem Moto "make it run, make it right, make it fast" bleibt oft keine Zeit um den Sourcecode einem Qualitäts-Check zu unterziehen.
Dabei gäbe es heute viele (open-source) Tools die einen Entwickler unterstüzen.
- Warum werden solche Tool nicht eingesetzt?
- Warum werden Code-Reviews nicht automatisiert?
- Bringen solche Metriken überhaupt etwas?
- Oder liege ich falsch und jeder hat in seiner IDE ein Tool installiert?
Zu diesem Theama schreibe ich gerade an meiner Diplomarbeit und habe dazu eine Umfrage ins Netzt gestellt.
Link zur Umfrage:
http://www.umfrageonline.com/live.php?code=2441562695904
Es würde mich freuen wenn möglichst viele Entwickler an dieser Umfrage teilnehmen würden damit ich aussagekräftige Daten habe.
Nehmt euch doch bitte ein paar Minuten Zeit um die Fragen zu beantworten.
Vielen Dank
Martin Schmid

Hallo,
ich muss sagen, Ihre Fragestellung sind sehr gut, lassen genügend Spielraum um ehrliche Antworten zu geben und sind doch so exact, das sie sehr schnell zu erfassen sind.
Nur hätte ich mir bei einigen Fragen die Checkboxvariante gewünscht, weil es in der Praxis eher selten so ist, das nur ein Weg nach Rom führt.

Viel Erfolg bei Ihrer Arbeit.

MfG
Mathias Hengl

Hallo,

interessante Umfrage, jedoch hätte ich mir mehr Fokus darauf gewünscht, wie mit den Ergebnissen der Erhebung von Metriken umgegangen wird, bzw. wie mit den Metriken an sich umgegangen wird. Alleine Metriken zu erheben, macht Software kein Stück besser. Wie findet man am besten sinnvolle Thresholds? Was tun bei Verletzungen der Thresholds? Wie schafft man Awareness für Codequalität im Team?

Ich bin (trotzdem) an den Ergebnissen der Umfrage interessiert.

Gruß
Ollie

Ich schliesse mich dem Vorredner in seiner Kritik und dem Interesse an den Ergebnissen an ;)

Na, wenn man das Motto 'make it run, make it right, make it fast' ernst nimmt, ist das doch schon mal die halbe Miete, denn das Motto kennzeichnet ja eigentlich die Prioritäten:
erst mal muss die Software überhaupt laufen, dann muss sie korrekt funktionieren. Die Geschwindigkeit der Software hat die geringste Priorität.

Persönlich glaube ich, dass die erreichbare Codequalität schon vor dem Schreiben des Codes festgelegt wird. Wenn das Design nicht stimmt und die Architektur Frameworks stapelt, sieht es schon mal schlecht aus. Wenn mir Methoden begegnen, die deutlich über einer Bildschirmlänge liegen, werde ich misstrauisch. Und wenn ich beim Programmieren schlaue Tricks anwenden muss, stimmt im Allgemeinen etwas nicht.

Es ist schon viel gewonnen, wenn man z.B. bei Eclipse die Warnlevel hochsetzt und die Warnungen ernst nimmt. Ziel muss sein, dass kein gelbes Ausrufezeichen da ist (ohne 'suppress warning'). Ergänzt wird das Ganze bei mir dann noch durch geplantes Testen, wobei das Testen auf Fehler (z.B. das Verhalten bei fehlerhaften Daten) der schwierigste Teil ist. Unittests können hier keinen funktionalen Test ersetzen.
Zu guter Letzt kommt noch ein Profiler zum Einsatz, um zu prüfen, ob unnötig Ressourcen verbraten werden und ggf. bestimmte Teile in eigene Threads auszulagern.

Hallo,

nun muss ich doch mal fragen, wie mein Vorredner denn Architekturen checked, typische Programmierfehler ausmerzt und erkennen lässt, wie schauts mit Testabdeckung aus, wie mit Javadocabdeckung.?

Nur mit Eclipse alleine und, ich sags mal provokativ, schicken Vorsätzen, kommt man nicht weiter, schon gar nicht im typischen Projektumfeld...

2 Entwickler beginnen mit einem guten Vorsatz, man entwickelt, eines Tages entdeckt das Management, dass das Projekt kurz davor ist die Deadline zu brechen ... es kommen schlagartig 5 neue Developer dazu ...

Und nun ? Nun hilft das Warnlevel in Eclipse einfach nicht mehr weiter ;)

Und ein make it run, make it right make it fast ... *erm* Wer von uns hat denn nach einem Make it run noch Budget bekommen für den Rest der angedachten Steps?

Viele Grüße

Achim

P.S Sorry fürs leichte OT
This article was modified on 08 Nov 2009 at 12:40 pm.

Hallo,

ich wuerde es auch begruessen, wenn du die Ergebnisse der Umfrage hier veroeffentlichen wuerdest.

Gruss,
Markus

Joachim Arrasz wrote:

Hallo,
 
nun muss ich doch mal fragen, wie mein Vorredner denn Architekturen checked, typische Programmierfehler ausmerzt und erkennen lässt, wie schauts mit Testabdeckung aus, wie mit Javadocabdeckung.?
 
Nur mit Eclipse alleine und, ich sags mal provokativ, schicken Vorsätzen, kommt man nicht weiter, schon gar nicht im typischen Projektumfeld...
 
2 Entwickler beginnen mit einem guten Vorsatz, man entwickelt, eines Tages entdeckt das Management, dass das Projekt kurz davor ist die Deadline zu brechen ... es kommen schlagartig 5 neue Developer dazu ...
Und nun ? Nun hilft das Warnlevel in Eclipse einfach nicht mehr weiter ;)
Und ein make it run, make it right make it fast ... *erm* Wer von uns hat denn nach einem Make it run noch Budget bekommen für den Rest der angedachten Steps?



Volle Zustimmung :-)

Übersehen wird oft, dass die _Produktion_ besseren Codes nur ein Aspekt von Metriken ist. Das _Bewerten_ von existierendem Code ist mindestens genauso wichtig - denn nur damit kann man effekitiv gegensteueren...

Spannend finde ich auch, dass bei Metriken auch ein Kontrollaspekt mitschwingt. Irgendwie lese ich im OP sowas wie "Metriken brauche ich nicht, denn mein Code ist auch so schon gut".

Wichtig wäre, hier ein Denken zu etablieren, welches genau sowas vermeidet und stattdessen klarstellt, das bei der Entwicklung Metriken helfen, genauso wie eine IDE - nur eben etwas nachhaltiger (aka "langfristiger").

viele Grüße,
Jan

Joachim Arrasz schrieb:
Hallo,
 
nun muss ich doch mal fragen, wie mein Vorredner denn Architekturen checked, typische Programmierfehler ausmerzt und erkennen lässt, wie schauts mit Testabdeckung aus, wie mit Javadocabdeckung.?
 
Nur mit Eclipse alleine und, ich sags mal provokativ, schicken Vorsätzen, kommt man nicht weiter, schon gar nicht im typischen Projektumfeld...
 
2 Entwickler beginnen mit einem guten Vorsatz, man entwickelt, eines Tages entdeckt das Management, dass das Projekt kurz davor ist die Deadline zu brechen ... es kommen schlagartig 5 neue Developer dazu ...
Und nun ? Nun hilft das Warnlevel in Eclipse einfach nicht mehr weiter ;)
Das Problem ist, dass dir da die Metriken auch nicht mehr helfen. Denn in dem Moment heisst es auch, dass jetzt erstmal 'schnell produktiv gegangen werden soll, aufraeumen kann man ja dann spaeter"... :-/

Dass man die Einstellungen nur in Eclipse/<IDE der Wahl> hat ist natuerlich nicht genug.
Richtig ist, dass man diese ganze Ueberpruefungen nicht nur zum Reporting hernimmt, sondern tatsaechlich dadurch den Build-Kaputt (CI) macht.
Und dabei meine ich, dass alles was man eingehalten will dazu gehoert: Coding-Conventions, Metriken, 'Style-Guide' (Copy-Right-Notice, etc), usw.

Nur so kann man aus meiner Sicht die Regeln tatsaechlich einhalten und es gibt erst gar keine Diskussion, ob man nicht hier und da noch ein bisschen aufweichen kann.

Gruss,
Markus

Hallo

Und nun ? Nun hilft das Warnlevel in Eclipse einfach nicht mehr weiter ;)
 
Das Problem ist, dass dir da die Metriken auch nicht mehr helfen.
das sehe ich ein wenig anders, nicht komplett aber ein wenig. Wenn nun im Team ein Architekt ist, welcher die Metriken regelmässig nutzt um die richtigen Stichproben zu ziehen und somit halbautomatisch die aktuellen Sourceentwicklungen betrachtet, so kann er sogar noch vor dem Livegang eingreifen! Wie soll er denn über die IDEwarnings ein Komplettbild bekommen? Das geht nur über CI Metriken (imho)

Meistens ist es jedoch so, dass hier nichts mehr passiert, wenn es nicht schon vorab eingerichtet wurde. Wie soll man denn ohne Erfahrungen der Qualität vorher wissen, was die "neuen" schlechter machen? Von Arbeitsplatz zu Arbeitsplatz hechten ist zu diesem Zeitpunk für den Architekten nicht mehr machbar, letztlich ist es aber er der den Kopf dafür hinhalten muss... ergo sind Metriken die kumuliert über eine CI vorhanden sind dann zumindest ein Sicherungshaken.

Viele Grüße

Achim