Sensibilität für Codequalität fördern

[peez]

Ich bin jetzt ca. ein Jahr in meiner neuen Firma und habe mittlerweile das Standing, um auch mal tiefergreifende Änderungen vorzuschlagen oder durchzubringen.
Was mich von Anfang an gestört hat, ist die Qualität des Codes den unsere Programmier produzieren. Um es kurz zu machen, teilweise ist von hinten durch die Brust programmiert u. das völlig ohne Kommentare. GUI-Fenster die exakt gleich aussehen und funktionieren, sind doppelt programmiert, nur weil Daten aus einer minimal anderen Quelle angezeigt werden und und und...

Kurz vielleicht zu unserer Situation - wir haben keine Einzelprojekte sondern eines, das kontinuierlich weiterentwickelt wird. So gibt es monatliche Verteilungszeitpunkte. D.h. die Programmierer haben für die meisten Aufgaben gerade mal 3 Wochen (dann Codefreeze etc.) Zeit. Wenn man es aus dieser Sicht sieht, kann man es ihnen nicht allzu übel nehmen, dass sie etwas "nachlässig" programmieren.
Dennoch sollte man das Problem angehen. Ausser SVN und diesen Codefreeze Zeiten verwenden wir bisher keinerlei Werkzeuge zur Qualitätssicherung.

Mein erster Ansatz wäre jetzt erst mal ein monatlicher Code-Review und die Pflicht, wenigstens für alle Methoden der EJBs Unit-Tests zu entwickeln.
Ein Bug-Tracking Tool wäre auch ganz nett. Wir haben mal kurz BugZilla versucht aber das ist - jedenfalls so wie ich es gesehen habe - einfach nicht integriert genug.

Evt. kennt jemand von euch das Problem und hat es schon erfolgreich gelöst? Würde mich sehr über eure Erfahrungen freuen.

Auch frage ich mich, ob es evt. ein Codereview-Tool gibt, das mehr oder weniger nahtlos mit SVN zusammenarbeitet u. beispielsweise nur gereviewten Code ins finale Release aufnimmt. Dann evt. noch ein Bugtracking tool das ebenfalls mit SVN zusammenarbeitet u. der Programmierer beim Einchecken direkt den entspr. Bug auswählen kann, den er gerade gefixt hat...

 

[slawaweis]

klingt alles nach fehlenden Soft Skills. Ein Haufen von Software-Werkzeugen wird nicht helfen, wenn es kein eingespieltes Team mit einem fähigen Projektleiter gibt. Sind den die Mitarbeiter ausreichend motiviert? Werden diese regelmäßig gelobt für gute Arbeit? Was wird in den Meetings besprochen? Wird da konstruktiv diskutiert oder einfach nur genickt, damit man schneller abhauen kann? Wie ist die Kommunikation im Team? Sprechen die Leute oft miteinander über das Projekt oder erst wenn man sie mehrmals dazu aufgefordert hat? Was ist mit den Vorgesetzten und/oder den Projektleitern? Lassen sie genügend Raum für Vorschläge und Kritik seitens des Teams? Hören sie darauf und versuchen sofort eine Lösung für technische wie nicht-technische Probleme zu finden? Welchen Führungsstill haben sie? Als General, als Kapitän, als der beste Kumpel oder als die missverstandene und am meisten leidende Person des Unternehmens?

Meiner bisherigen Erfahrung nach, macht in einem echten Softwareprojekt der reine Programmieranteil um die 15% aus. Sehr viel Zeit geht auf andere Sachen drauf, die teilweise nichts mit der Software zu tun haben. Letztendlich arbeiten Menschen daran und die sind launisch. Das sind keine Roboter. Also ist es sehr wichtig, an der Atmosphäre und der Kommunikation im Team zu arbeiten, damit die Mitarbeiter frei und entspannt miteinander sprechen können. Dabei sollten sie auch einander kritisieren können ohne in persönliche Angriffe oder wilde Unterstellungen zu verfallen. Ich habe dieses Buch gelesen:

Softwareentwicklung im Team - Erfolgreiche Planung und Durchführung von IT-Projekten: Amazon.de: Georg Erwin Thaller: Bücher

und das hat mir sehr geholfen einige Sachen besser zu verstehen. Es gibt hunderte Bücher zu diesem Thema und bestimmt gibt es bessere, aber das genante Buch ist einfach zu lesen und ich fand es hilfreich.

Jedenfalls muss immer ein fähiger Projektleiter vorhanden sein, der nicht nur die technische, sondern auch die soziale Komponente versteht und managen kann. Weiterhin muss man Leute abstellen, die nicht nur an der Software arbeiten, sondern sich mit anderen, genauso wichtigen Bereichen, beschäftigen. Z.B. eine Gruppe, die sich rein mit der Dokumentation beschäftigt. Was muss dokumentiert werden, was nicht? Im welchen Format, mit welcher Software? Kommen damit alle zurecht? Machen es auch alle? Wo mangelt es? Vielleicht eine Schulung machen, damit alle auf den selben Stand sind? Dann z.B. eine Utility-Gruppe. Was wird häufig an Hilfsfunktionen benötigt? Was ist ähnlich und kann in ein globales Utility-Framework eingebunden werden, was dem ganzen Unternehmen zu Verfügung gestellt und auch ausreichend beworben wird? Was brauchen die Mitarbeiter noch an Hilfsfunktionen, woran mangelt es? Regelmäßige Umfragen? Eine weitere Gruppe könnte z.B. eine Testgruppe sein. Diese programmiert nicht an der Software selber, sondern beschäftigt sich täglich mit den Gedanken, Tests und Verfahren, wie man die Software kaputt kriegt. D.h. eine reine Demolition-Gruppe die alles im Rahmen der Kreativität einsetzt, um die Software auf Herz und Nieren zu testen und regelmäßig gute Fehlerberichte und -analysen zu erstellen.

Slawa

 

[Murray]

<slightly-off-topic>

Ich bin jetzt ca. ein Jahr in meiner neuen Firma und habe mittlerweile das Standing, um auch mal tiefergreifende Änderungen vorzuschlagen oder durchzubringen.

Nach einem Jahr kannst Du tiefgreifende Änderungen auch durchbringen (vorschlagen kann man das sicher schon eher)? Respekt...

Ich nehme mal an, dass die Entwickler, über die Du hier sprichst, zumindest teilweise schon länger im Unternehmen sind als Du - da brauchst Du wohl ziemlich gute Rückendeckung.

Auf jeden Fall wünsche ich Dir viel Erfolg - wir "Langgedienten" können bestimmt manchmal etwas frischen Wind gut gebrauchen, selbst wenn man erstmal automatisch eine Abwehrhaltung einnimmt.
</slightly-off-topic>

M.E. ist die Idee mit den verpflichtenden Unit-Test ganz gut; obligatorischen Code-Reviews dürften am Zeitaufwand scheitern - denn die Entwickler machen die von Dir beschriebenen Dinge ja vermutlich nicht aus Unwissenheit oder Böswilligkeit, sondern durch den Zeitdruck; wo sollte man da zusätzliche Zeit für Reviews hernehmen?

Vielleicht hilft auch der Einsatz eines Architektur-Management-Tools wie PMD, Findbugs oder Checkstyle weiter .

Technisch erzwungene organisatorische Hürden für das Einchecken würde ich lieber nicht aufstellen wollen, weil garantiert irgendwann die Situation kommt, in der eine Lösung ganz schnell produktiv gestellt werden muss, egal, ob vorher Code-Reviews gelaufen sind oder nicht.

 

[code404]

I
Dann evt. noch ein Bugtracking tool das ebenfalls mit SVN zusammenarbeitet u. der Programmierer beim Einchecken direkt den entspr. Bug auswählen kann, den er gerade gefixt hat...

The Trac Project

 

[kama]

Hallo,

Was mich von Anfang an gestört hat, ist die Qualität des Codes den unsere Programmier produzieren. Um es kurz zu machen, teilweise ist von hinten durch die Brust programmiert u. das völlig ohne Kommentare. GUI-Fenster die exakt gleich aussehen und funktionieren, sind doppelt programmiert, nur weil Daten aus einer minimal anderen Quelle angezeigt werden und und und...

Das hört sich danach an, als ob die Applikation ein Refactoring benötigen würde...Refactoring ist aber realistisch nur dann machbar wenn man eine gute Abdeckung durch Unit Tests hat...

Dennoch sollte man das Problem angehen. Ausser SVN und diesen Codefreeze Zeiten verwenden wir bisher keinerlei Werkzeuge zur Qualitätssicherung.

Also jetzt bin ich mal ein wenig pingelig...SVN ist ein Version Control Tool und hat nichts mit QS zu tuen...

Mein erster Ansatz wäre jetzt erst mal ein monatlicher Code-Review und die Pflicht, wenigstens für alle Methoden der EJBs Unit-Tests zu entwickeln.
Ein Bug-Tracking Tool wäre auch ganz nett. Wir haben mal kurz BugZilla versucht aber das ist - jedenfalls so wie ich es gesehen habe - einfach nicht integriert genug.

Code Reviews werde hier scheitern. Warum? Weil die Kultur nicht existiert...der Erste Schritt ist verbindlich Unit Tests einzuführen...

Evt. kennt jemand von euch das Problem und hat es schon erfolgreich gelöst? Würde mich sehr über eure Erfahrungen freuen.

Wenn jemand diese Art von Problemen gelöst hätte dass wären wir alle glücklich ;-)

Auch frage ich mich, ob es evt. ein Codereview-Tool gibt, das mehr oder weniger nahtlos mit SVN zusammenarbeitet u. beispielsweise nur gereviewten Code ins finale Release aufnimmt. Dann evt. noch ein Bugtracking tool das ebenfalls mit SVN zusammenarbeitet u. der Programmierer beim Einchecken direkt den entspr. Bug auswählen kann, den er gerade gefixt hat...

Also ich eher der Meinung ein Code Review bringt hier zuerst einmal garnichts...auch ein Tool hilft nicht weiter...
Das Erste sind Unit Tests weiterhin wäre hier der richtige Einsatz einer Branching Strategie basierend auf einem Issue Tracking System (Ein Branch pro Issue etc.). Dann der Einsatz eines Continious Integration System (z.B. Hudson) und entsprechende Anpassung der Arbeitsweise darauf..
Issue Tracking System: z.B. Redmine (Redmine - Overview - Redmine)...

Branching und insbesondere Merging ist auch nur realistisch möglich mit einer guten Abdeckung durch Unit Tests...

Wenn man Unit Tests einführt kommt man zwangläufig an Orte wo oft gesagt wird, dass ich schwierig zu Testen oder eventuell garnicht. Das sind dann Punkte die gefactored werden müssen, um Sie testbar zu machen...

 

[kama]

Hallo,

Vielleicht hilft auch der Einsatz eines Architektur-Management-Tools wie PMD, Findbugs oder Checkstyle weiter .

Was haben PMD, Findbugs und Checkstyle mit Architektur Management Tools zu tuen ? Hier werden duplicate Code, Einhaltung Code Style Richtlinien geprüft...und typische Bug Situation?

Gruß
Karl Heinz Marbaise

 

[Marco13]

Jedenfalls muss immer ein fähiger Projektleiter vorhanden sein...
Z.B. eine Gruppe, die sich rein mit der Dokumentation beschäftigt...
Dann z.B. eine Utility-Gruppe. Was wird häufig an Hilfsfunktionen benötigt? ...
Eine weitere Gruppe könnte z.B. eine Testgruppe sein....

Der Fall, dass jeder einzelne Mitarbeiter EIN Projekt "managt", "programmiert", "dokumentiert" und "testet" ist damit wohl auch abgedeckt

 

[bygones]

Wenn man Unit Tests einführt kommt man zwangläufig an Orte wo oft gesagt wird, dass ich schwierig zu Testen oder eventuell garnicht. Das sind dann Punkte die gefactored werden müssen, um Sie testbar zu machen...

legacy code zu testen ist so und so zu 99% nicht möglich oder so umständlich, dass einem die Mission "Unit Tests helfen uns weiter" in keiner weise geglaubt wird.

Weiterhin hat man das Problem dass bei nicht vorhandenen Testwissen dass alleinige Schreiben von Unittests (womöglich sogar mit einer hohen Coverage) leider Qualitätsmäßig nicht immer einen vorwärtsbringt.

Dennoch ist es natürlich richtig das ganze in kleinen Schritten anzugehen - ich sehe aber definitiv Schwierigkeiten in der Vermittlung von QS aktivitäten, wenn man mit legacy code anfängt.

 

[Vayu]

Atlassian Jira in Verbindung mit Fisheye und evtl ein paar Hookskripte im svn bilden ein gutes Werkzeug

 

[bygones]

Atlassian Jira in Verbindung mit Fisheye und evtl ein paar Hookskripte im svn bilden ein gutes Werkzeug

wenn man dafür geld ausgeben will...

 

[peez]

wenn man dafür geld ausgeben will...

...und trotzdem keinen Service haben möchte...

Wir haben schon Confluence als Wiki und von denen kommt mir nach Möglichkeit nichts mehr ins Haus...

 

[Landei]

Wie schon gesagt wurde: Die Werkzeuge sind nicht das Problem, sondern die Leute.

Wenn man sie nicht überzeugen kann, dass es hier nicht um Rumgemecker geht, sondern um konstruktive Kritik, die sie selbst weiterbringt und ihnen ihre Arbeit im Endeffekt erleichtert, ist Hopfen und Malz verloren.

Sanfter Zwang kann helfen, aber nur bis zu einem gewissen Grad, dann machen sie "zu".

 

[Vayu]

...und trotzdem keinen Service haben möchte...

Wir haben schon Confluence als Wiki und von denen kommt mir nach Möglichkeit nichts mehr ins Haus...

hmm kann ich nicht nachvollziehen, als ich noch mit denen zutun hatte und service brauchte ging das eigentlich relativ flott und kompetent.

Geld ist ne andere Sache, klar kostet Geld, aber ich fand das war sein Geld wert. Und in ner Firma kann man ja schonmal Geld für sowas ausgeben.

 

[fastjack]

Wahrscheinlich ist das alles eine Frage der Motivation der Mitarbeiter bei Euch. Vielleicht haben die einfach keinen Bock, oder wollen nicht mehr, weil abgestumpft etc. Kurzum: Motivationslag.
Codestil und JavaDoc könnt Ihr durch Checkstyle mit Checkstyle-Reports prüfen.
Testen sollte auch Selbstschutz der jeweiligen Entwickler sein. Gerade bei größeren Projekten, oder bei vielen Wiederverwendbaren Teilen kann nur so die Stabilität anderer Projekte, bei Änderungen, gewahrt bleiben. Zur Testabdeckung kann man Emma benutzen, das erzeugt auch Reports.
Wenn man die Reports automatisiert etwas "schöner", "bunter" macht, sind viele Entwickler gleich motivierter.
Vielleicht sollte Ihr auch den Arbeitstil ändern, z.B. agile Teams bilden etc. Das fördert auch die Motivation.
Die Leute müssen einfach den Zweck vom Testen, Dokumentieren etc. verstehen und der lautet: Streß vermeiden.

 

[fastjack]

Mit Streß vermeiden meine ich genau diesen Streß, den man hat, wenn man Methode X geändert hat und ein paar Wochen später die darauf aufbauenden Projekte A, B und C schief laufen.

 

[bygones]

passend dazu:

nette Geschichte + Die Clean Code Developer Initiative

 

[maki]

Evt. kennt jemand von euch das Problem und hat es schon erfolgreich gelöst? Würde mich sehr über eure Erfahrungen freuen.

Ist gar kein Problem, es müsste sich nur alles ändern... inkl. der Entwickler

Vorgehensmodelle und Literatur gibt es ja mehr als genug zu diesem Thema (Clean Code, Refactoring, XP, etc. pp.), das ist, wie schon von anderen erwähnt, eine kulturelle Angelegenheit: Arbeitet man sauber, oder ist es "fertig" wenn erstmal etwas funktioniert.

Sehe das anders als slawaweis, Aufgaben zu trennen (Implementierung, Test, Doku, etc. pp.) ist der falsche Weg imho, der richtigere Weg wäre das Teammitglieder Aufgaben wahrnehmen und Verantwortung tragen, finde Trennung zwischen Testern & Entwicklern nie gut, da wird zuviel Verantwortung weitergeschoben und die Wege werden unnötig lang.

Die Techniken wurden schon genannt, Code Reviews, Unittests, Refactoring, würde da noch CI mitreinnehmen.
Aber ohne die passende Kultur in den Köpfen, wird das nix, ist kein Toolingproblem.

Nebenbei, Trac würde ich heute niemandem mehr empfehlen, Redmine kann das auch, nur besser.

 

[KSG9|sebastian]

Vorgehensmodelle und Tests als Pflicht zu definieren macht das ganze nur schlimmer.

Die Kultur muss stimmen: Wenn der Entwickler keinen Wert auf Qualität legt dann bringen Unittests auch nichts. Solange das Bewusstsein dafür nicht vorhanden ist bringt es nix.

Wir haben in einem Team ein ähnliches Problem gehabt: Wir haben dann ein Projekt mal nach Testdriven Development gemacht. Am Anfang waren die Leute ziemlich skeptisch, aber wir konnten schließlich alle überzeugen.

Die Leute müssen einen Mehrwert sehen. Unittests zu schreiben damit Unittests da sind hilft nichts. Wenn man den Leuten aber erklären kann warum und wieso dann gehts, z.B. "schreib zuerst einen Test und dann den eigentlich Code. Dadurch bist du schnell, du weißt von Anfang an welche Schnittstellen benötigt werden und es wird kein unnützer Code geschrieben"