In meinen Projekten hat sich der Einsatz von Codeanalyse-Tools immer gelohnt. Anfangs war es immer schwer, andere Entwickler von den Vorteilen zu überzeugen. Spätestens, wenn ein Tool einen unentdeckten Fehler, der noch zugleich kritisch war, gefunden hatte, waren alle anderen vom Nutzen überzeugt. Doch wie starte ich am besten in einem Projekt mit einem Codeanalysetool?
Heute gehe ich weniger auf die Vorteile der statischen Codeanalyse oder die verschiedenen Tools ein, sondern erzähle von den Möglichkeiten, wie ihr in euren Projekten
mit der statischen Codeanalyse starten könnt. Ich sehe hier 3 Möglichkeiten:
1. Verwendung des Standardregelsatzes
2. Starten mit einen eigenen, schon bestehenden Regelsatzes
3. Sukzessiver Aufbau eine Regelsatzes
Die Verwendung des Standardregelsatzes, die die Tools wie Checkstyle, PMD oder
FindBugs mitbringen, ist näturlich die einfachste Möglichkeit. Die Entwickler haben sich schon im Vorwege Gedanken gemacht, was wichtig ist wie Naming Convetions, Duplicate Code, Header, Imports, Kommentare, Größen, Modifier und Whitespace. Vorteil ist hier, dass die Entwickler im Projekt sofort sehen, welche Regeln mißachtet wurden, die in der Java Community existieren. Nachteil ist, dass in Brownfield Projekten die Entwickler „vor lauter Kraut die Rüben“, sprich die wichtigsten Regelverletzungen nicht sehen und beheben.
Der Start mit einem eigenen, schon bestehenden Regelsatzes ist eine prima Möglichkeit. Man hat schon Erfahrungen mit Codeanalysetools, kennt die Projekte in einem Unternehmen und die Art und Weise wie bisher in Softwaree entwickelt wurde. Bei dieser Methode ist alles in Ordnung. Voraussetzung ist, dass man schon Erfahrungen mit den Tools gesammelt hat und weiß, welche Dinge bei der Softwareerstellung „vernachläßigt“ werden.
Der sukzessive Aufbau eines Regelsatzes ist eine gute Möglichkeit, die ich schon in mehreren Projekten erfolgreich angewendet habe, wenn man „vor lauter Kraut die Rüben“ nicht sehen kann. Ich bin schon mal mit nur einer Regel gestartet: Nullpointer Check
(FindBugs Bug Description). Nach und nach haben wir dann weitere Regeln hinzugefügt, wenn die Bugs der einen Kategorie behoben wurden sind oder neue Fälle aufgetreten sind, wo das Hinzufügen einer neuen Regel Sinn machte. Vorteil dieses Weges ist, dass beim Start des Einsatzes eines Codeanalysetools der Fokus auf wenige Regeln liegt, nämlich die man als die wichtigsten identizifiziert hat. So bleibt die Motivation bei den Entwickler erhalten, die sich ansonsten von den Bug-Meldungen erschlagen fühlen könnten. Nachteil der Methode ist, dass ohne Plan wie der Aufbau vonstatten gehen soll, z.B. welche Regel wann folgen, ob weitere Tools eingesetzt werden, etc. , der Aufbau langsam und unkoordiniert erfolgt.
Ich selber nutze gerne die erste Möglichkeit, wenn ich in Projekten neu reinkomme. Somit sehe ich sofort, wo der Schuh drückt. Für die eigentliche Arbeit im Brownfield-Projekten empfehle ich aber den sukzessiven Aufbau einese Regelsatzes. Wenn ihr euch für die zweite oder dritte Methode entscheidet, dann ist es wichtig, dass ihr regelmäßig überprüft, welche Regeln noch Sinn machen.
Links:
Checkstyle
PMD
FindBugs
Bildquelle: Pixelio.de/Karl-Heinz Laube
