Software Qualität/Code Review

[GilbertGrape]

Hallo liebes Forum,

Wir wollen in unserer Firma jetzt regelmäßig Code Reviews machen um die Qualität zu verbessern.
Ich habe mir jetzt im Netz schon ein paar Sachen (diverse Metriken etc.) angeschaut. Wir nutzen auch Sonar.
Ich würde mir aber trotzdem gern noch ein bißchen mehr allgemeines Wissen dazu aneignen und wollte fragen, ob einer ein Buch-Tipp hat?

Bei Amazon habe ich das hier gefunden:
Metrics and Models in Software Quality Engineering

oder das: Software-Qualität: Testen, Analysieren und Verifizieren von Software

Vermutlich sehr unwahrscheinlich, aber kennt jemand eines davon und kann was dazu sagen?

Ansonsten bin ich über Literaturhinweise dankbar!

Gruß
GG

 

[maki]

"Clean Code" von Robert Martin ist da besser geeignet imho.

Ansonsten:
Metriken sind schön & gut, aber meist nicht so hilfreich wie man meint...

FindBugs dagegen hilft imho immer

Code Reviews am besten sehr häufig machen, wie zB. vor einem Commit.
Besser man fängt die Spinner früh ein anstatt ihnen ewig hinterherzulaufen.

 

[tribalup]

Es gab da glaube auch nen buch zu den Softskills bei Codereviews.
Wenn da nicht ein paar Sachen eingehalten werden springen sich irgendwann alle gegenseitig an die Kehle.

 

[maki]

Es gab da glaube auch nen buch zu den Softskills bei Codereviews.
Wenn da nicht ein paar Sachen eingehalten werden springen sich irgendwann alle gegenseitig an die Kehle.

Hehehe.. kann passieren wenn man ncht gerade ein Diplomat ist.
Aber auch, wenn man sich nciht auf Richtlinien geegnet hat (Styleguides, max. größe der Methoden).

Ansosnten helfen eben statische Analyse Tools wie zB. FindBugs, CPD, etc. auch da, weil es ja keine Kritik von einer Person ist, sondern von einem Tool.

 

[DerFeivel]

"Clean Code" von Robert Martin ist da besser geeignet imho.

Ansonsten:
Metriken sind schön & gut, aber meist nicht so hilfreich wie man meint...

FindBugs dagegen hilft imho immer

Code Reviews am besten sehr häufig machen, wie zB. vor einem Commit.
Besser man fängt die Spinner früh ein anstatt ihnen ewig hinterherzulaufen.

Code-Reviews vor einem (jeden) Commit?

Ein Code-Review vor der Übergabe an die Testabteilung würde ich da doch eher für sinnvoll halten.


Im Allgemeinen sollte m.E. folgendes Vorgehen angestrebt werden:

1. Unit-Test implementieren (siehe Richtlinien Unittests)
2. Implementieren der Funktionalität
(wenn kein Test-Driven Development angestrebt, dann hier spätestens Unit-Test)
3. Refactoring der Implementierung
4. Überprüfen, ob Unit-Tests weiterhin funktionieren (grün sind)


Beim Refactoring würde sich evt. Pair-Programming anbieten. Wobei der eigentlich Entwickler der Umsetztende ist und durch einen erfahrenen Entwickler unterstützt wird.


Also nur als Vorschlag. Dem Hinweis auf "Clean Code" stimme ich natürlich uneingeschränkt zu. Evt. bietet hier die Webseite clean-code-developer.de einen guten kurzen Einstieg (hat allerdings nur thematisch mit dem Buch zu tun)

 

[DerFeivel]

Hehehe.. kann passieren wenn man ncht gerade ein Diplomat ist.
Aber auch, wenn man sich nciht auf Richtlinien geegnet hat (Styleguides, max. größe der Methoden).

Ansosnten helfen eben statische Analyse Tools wie zB. FindBugs, CPD, etc. auch da, weil es ja keine Kritik von einer Person ist, sondern von einem Tool.

Max. größe einer Methode ? :noe:

Was machst du denn, wenn du einen Algorithmus mit 40 Teilschritten hast, welche sich Thematisch nicht gliedern lassen?


FindBugs und CPD ist auch nen guter Einwand, allerdings auch nur mit sinnvollen Einstellungen :rtfm:

 

[tribalup]

Max. größe einer Methode ? :noe:

Was machst du denn, wenn du einen Algorithmus mit 40 Teilschritten hast, welche sich Thematisch nicht gliedern lassen?


FindBugs und CPD ist auch nen guter Einwand, allerdings auch nur mit sinnvollen Einstellungen :rtfm:

Ausnahmen bestätigen die Regel aber sollten Ausnahmen bleiben.

 

[DerFeivel]

Ausnahmen bestätigen die Regel aber sollten Ausnahmen bleiben.

Anhand welche Gesichtspunkte wurde die Regel erstellt?


Persönlich halte eine Zeilenanzahl von weniger/gleich 10 für sinnvoll.



@GilbertGrape:

Alles nur Spaß, aber auf solche Diskussionen sollte man evt. auch eingestellt sein. Entwickler sind manchmal schon ein komisches Völkchen :applaus:

 

[GilbertGrape]

Hallo,

vielen Dank erstmal für die Hinweise, auch für den "Clean Code"-Tipp!

FindBugs und CPD benutzen wir schon. Das wird halt immer zu jedem Jenkins-Build ausgegeben, aber ich glaube, dass das die meisten nicht wirklich interessiert. Ich soll jetzt da so ein bißchen hinterher sein und den Entwicklern dann entsprechende Bugs und sowas anlegen. Damit ich dann etwas fundierter argumentieren kann, brauche ich eben noch etwas Input

 

[tuttle64]

Neben Reviews gibt es noch die Prüfverfahren Walkthrough und Inspection, siehe auch Statisches Software-Testverfahren.

 

[bygones]

bei mir gibts noch UCDetector im Angebot... wenn man mit Eclipse arbeitet ein klasse tool