Dies ist der letzte Post, bevor ich zu den eigentlich Werkzeugen für die Vermeidung technischer Schulden komme. Er behandelt verschiedene Rahmenbedingungen für die Vermeidung technischer Schulden.
QS im Team
Egal ob wir innerhalb eines Scrum-Teams entwickeln oder ein Softwarearchitekt für die Organisation zuständig ist: Qualitätssicherung ist immer eine Aufgabe des gesamten Teams. TEAM bedeutet also nicht „Toll Ein Anderer Machts“, sondern es müssen alle Beteiligte an dem kontinuierlichen Prozess teilnehmen. Teile der technischen Schulden können sicher im Laufe der Realisierung von Feature-Request (mit-)erledigt werden. Es führt aber kein Weg daran vorbei, dass für die Beseitigung der technischen Schulden weitere Ressourcen notwendig sind. Es müssen regelmäßig „Putztage“ eingeplant werden, in den die Ergebnisse der Analysen abgearbeitet und somit Schulden abgebaut werden. Wenn wir in einem Scrum-Team arbeiten, sollte die unbedingt auch in den Teamvertrag aufgenommen werden.
Softwareunterstützung
Für die hier beschriebenen Prozesse gibt es eine sehr gute (insbesondere OpenSource) Softwareunterstützung. Festzustellen ist, dass es nicht „das eine“ Tool gibt, um die Anforderungen zu befriedigen. Aktuell muss immer auf mehrere Werkzeuge zurückgegriffen werden, um eine solide Basis zu schaffen. Die Tools arbeiten auf verschiedene Ebene wie beispielsweise IDE, Build-System (Maven), CI-System (Jenkins), … Dies hat zur Folge, dass viele Plugins für die Systeme benötigt werden. Leider muss man feststellen, dass es sich bei den vielen Plugins um einen „Hühnerhaufen“ handelt, der dazu neigt, in verschiedene Richtungen zu laufen. Man muss immer sehen in welchen Quellen welches Plugin aktuell ist (Quellen: Marketplace vs. Updatesite) und welche Änderungen sich bei der Konfiguration durch neue Versionen ergeben. Ggf. verhalten sich auch Versionen von Maven (3.5 vs 3.3 evtl. auch Gradle) unterschiedlich in Verbindung mit einzelnen Plugins. Aber der Aufwand lohnt sich!!!
Probleme der Automatisierung
Es ist nicht alles automatisierbar. Beispiele hierfür sind
- Funktionserfüllung
- Umsetzungsstil
- Symptombehandlung statt Lösungsfindung
Funktionserfüllung
Auch sehr viele Tests ersetzen keine manuellen Prüfungen und können nicht zu 100% sicherstellen, dass die Software das gewollte umsetzt.
Umsetzungsstil
Kreativität und Erfahrungsgrad der Entwickler führen zu Lösungen, die ggf. stilistisch soweit voneinander abweichen, dass sie angepasst werden müssen, obwohl sie korrekt arbeiten. Grundsätzlich sind les- und wartbare und nicht brillante Lösungen anzustreben.
Symptombehandlung statt Lösungsfindung
Beispielsweise kann bei einer NPE das Symptom durch eine If Bedingung umgangen werden. Es ist aber häufig viel wichtiger zu klären, ob ein Nullwert überhaupt in diesem Kontext vorkommen darf oder ob Validitätsprüfungen nicht greifen. Diese müssten dann statt des „Umgehens“ der NPE korrigiert werden und damit das ganze System in einen konsistenten Zustand versetzt werden.
False Positives
Eigentlich bei allen automatischen Prozessen kann es dazu kommen, dass ein (Fehler)Zustand falsch erkannt wird. Lösungen hierfür sind in Hinblick auf die Werkzeuge
- Parametrisierung der Regeln
- Codestellen ignorieren
- Kennzeichnen der Codestellen durch Kommentare
- Kennzeichnen der Codestellen durch Annotationen
- Artefakte/Projekte/Packages ausschließen
- Insbesondere automatisch generierte Pakete wie beispielsweise bei SOAP-Schnittstellen
- Erfassen von Zusatzinformationen
- Begründungen warum diese Stelle keine technische Schuld ist und dann Filterung dieser Stellen in den Ergebnislisten (Kennzeichen reviewed)
„A fool with a tool is just a fool“
Wichtig ist natürlich auch, dass die Tools kein Selbstzweck sind. Blind laufende Tools, deren Ergebnisse nicht ausgewertet werden sind sinnlos (Marketing und Vertrieb sehen das eventuell anders
). Werkzeuge sollen schrittweise eingeführt werden. Dabei werden die Regeln nach und nach erweitert und unterscheiden, ob die Reglen für die manuellen und automatischen Prüfungen eingesetzt werden. Allgemein gilt: Lieber umgesetzte Minimalanforderungen, als keine Prüfungen!.