Arndt Schönbergs Weblog

Mittwoch Apr 04, 2018

Werkzeuge zur Erhaltung der Softwarearchitektur - SonarQube - Teil 12

SonarQube

Bei SonarQube handelt es sich um ein Serverprodukt, das eine sehr gute Übersicht für den manuellen Prozess bietet. Auch wird der zeitliche Verlauf von Regelverletzungen in einer Datenbank gespeichert, so dass die Historie gut zu verfolgen ist. Sonar benötigt mindestens einen eigenen Server, der über Plugins erweitert wird und die Daten in einem DBMS ablegt. Die folgende Abbildung zeigt die Zusammenfassung eines Projektes in SonarQube

Sonar Projekt

Wir benutzen derzeit SonarQube primär für den manuellen Sicherungsprozess, da die automatischen Regeln sehr gut durch die zuvor vorgestellten Werkzeuge in den Ablauf integriert sind. Sonar verwendet eine Vielzahl von Regeln und kann unter anderem auch auf die Regeln der bisherigen Werkzeuge zugreifen. Für den manuellen Review Prozess ist besonders schön, dass bei Sonar
  • alles gut Integriert ist
  • eine grafische Aufbereitung der Werte (auch Städte) stattfindet
  • der zeitlicher Verlauf in einer Datenbank abgelegt wird
  • False/Positives, die ein Hauptbestandteil des manuellen Prozesses sind, gut verwaltet werden
Eine Darstellung von Werten als Stadt findet sich in der folgenden Grafik.

Code City

Außerdem bewertet SonarQube technischen Schulden in Arbeitszeit mit einer (aus meiner Sicht sehr einfachen) Metrik. Dies kommt häufig dem Management mehr entgegen, als Zahlen zu Bugs und Code-Smells. Aber Vorsicht, solche Werte können niemals sehr genau sein.

Quality Gates

SonarQube fasst die Ergebnisse der Projektanalysen zusammen und stellt sogenannt Quality Gates bereit. Diese können Sonar konfiguriert werden und beschreiben analog zu Jenkins eine Art "Gesundheitszustand" des Projekts. Quality Gates fassen Schwellwerte für verschiedene Bereiche zusammen
  • Veränderte Testabdeckung
  • Regelverstöße
  • Neue blockierende Regelverstöße
  • Neue kritische Regelverstöße
  • Technical Debt Ratio on New Code
  • Doppelter Quellcode
  • usw.

Integration

  • IDE (Plugin unvollständig)
  • Maven-Build
  • Jenkins (Plugin defekt)
    • Quality Gate Plugin
    • https://issues.jenkins-ci.org/browse/JENKINS-43081
  • Sonar-Server
Die Plugins sind derzeit etwas "wackelig" und nicht zu 100% einsatzfähig. Auch wegen dieser derzeit schlechten Plugin-Situation ist Sonar derzeit eher für den manuellen Prozess sinnvoll. Die Plugins für die IDE zeigen derzeit Fehler entsprechend der Konfiguration des Servers. Es ist möglich Projekte mit den SonarQube Projekten zu „verbinden“ und somit die projektspezifischen Status einzusehen. Eine False/Positiv Behandlung in der IDE ist aber derzeit nicht (mehr) möglich.

False/Positive

Eine der Stärken von SonarQube ist die False/Positive Behandlung. Bei False/Positives kann in Sonar festgehalten werden, warum es sich um einen False/Positive handelt und die Begründung in einer Datenbank gespeichert werden. Danach gilt der False/Positive als behandelt und erscheint nicht mehr in den Auswertungen.

Regelerweiterung

  • Eigener Regelsatz / Selektion
  • https://docs.sonarqube.org/display/SONAR/Rules
  • Import weiterer Regelsätze z.B. der bisher betrachteten Werkzeuge

Fazit

SonarQube ist ein schickes Managementtool mit Integrationsschwierigkeiten. Nachdem die zuvor beschriebenen Werkzeuge in den QS Prozess aufgenommen wurden, sollte auch SonarQube insbesondere für den manuellen Prozess verwendet werden.

Alle Teile der Serie zu Architekturerhaltung in Java

Werkzeuge zur Erhaltung der Softwarearchitektur - FindBugs - Teil 11

FindBugs

Der dritte im Bunde der "magischen drei" ist FindBugs. FindBugs hat eine fantastische Fehlererkennung. Wir hatten intern bereits öfter Diskussionen zu den angezeigten Meldungen und mussten im Allgemeinen am Ende immer die Meldungen von FindBugs bestätigen. Im Gegensatz zu den anderen Tools analysiert FindBugs den Byte-Code.

Besonderheiten

  • bestes Werkzeug für Fehlerprüfungen (NPE, ...)
  • Prüfung logischer Ausdrücke

Integration

  • IDE
  • Maven-Build (Ausführung und Erzeugen von Basisdaten)
  • Jenkins (GUI und Grenze für ungültige Artefakte)
Ein (einfacher) SVN Pre-Commit Hook Einsatz ist hier natürlich nicht möglich, da FindBugs den Byte-Code analysierert, der erst erzeugt werden müsste.

False/Positive

  • Parametrisierung
  • Codestellen über Annotation von der Prüfung ausschließen
  • Ausschluss von Projekten / Packages

Regelerweiterung

  • Externe Erweiterungen: z.B. Security Regeln http://find-sec-bugs.github.io/
  • Eigene Regeln in Java mit Wissen über ByteCode erstellen
  • https://www.ibm.com/developerworks/library/j-findbug2/
Beispiel Blacklist für Regeln
<?xml version="1.0" encoding="UTF-8"?>
<FindBugsFilter>
    <Match>
        <Bug code="EI,EI2,Se,SECSQLIJPA,SECHCP,SECPTI,SECCI,SECPTO,SECUR" />
    </Match>
    <Match>
        <Class name="~.*\.R\$.*" />
    </Match>
    <Match>
        <Class name="~.*\.Manifest\$.*" />
    </Match>
</FindBugsFilter>

Stand bis hierher

Mit den bis hier vorgestellten Werkzeugen haben wir die Pflicht der QS sichergestellt. Mit der Grundausstattung Open Tasks, FindBugs, PMD und Checkstyle können eine Vielzahl technischer Schulden vermieden und automatisch gefunden werden. Die Regeln sind bei allen Tools konfigurierbar und können sukzessive eingeführt werden.

Aus meiner Sicht sollte niemand auf dies Tools verzichten. Wenn im aktuellen Projekt noch zu viele Probleme existieren, kann mit kleinen Regelsätzen gearbeitet werden. Wenn die Integration in den Build-Prozess nicht möglich ist, können die Werkzeuge auch nur in der IDE eingesetzt werden.

Alle Teile der Serie zu Architekturerhaltung in Java

Dienstag Apr 03, 2018

Werkzeuge zur Erhaltung der Softwarearchitektur - PMD / DRY - Teil 10

PMD

Das Werkzeug PMD analysiert den Quellcode. Nach Angaben der Entwickler ist PMD kein Akronym. Besonders hervorzuheben sind folgende Analysepunkte
  • Cut and Paste Detector - Duplizierter Quellcode
    • bläht den Quellcode auf
    • erschwert die Wartung
    • erhöht den Testaufwand
  • Zuweisungen in Schleifenbedingungen
  • Komplexitätsanalyse / Lose Kopplung (Law of Demeter)
  • Umfangreiches, strukturiertes Regelwerk
  • Erkennung von doppelten unäre Operationen (!!)
Für den Bereich Kommentare und Dokumentation ist PMD nicht geeignet (vergl. Checkstyle).

Integration

  • IDE
  • SVN Pre-Commit Hook
  • Maven-Build (Ausführung und Erzeugen von Basisdaten)
  • Jenkins (GUI und Grenze für ungültige Artefakte)
    • DRY: Darstellung Cut and Paste Detector

False/Positive

False/Positives können auf folgende Weisen markiert werden
  • Parametrisierung der Regeln
  • Codestellen über Annotation oder Kommentare markieren
  • Ausschluss von Projekten / Packages

Regelerweiterung

Es werden verschiedene Regelpakete / Module bereitgestellt.
  • Java für JEE / Android
  • https://pmd.github.io/pmd-5.4.1/pmd-java/rules/index.html
  • nicht Java Code (z.B. JSF, JSP, JavaScript)
Des Weiteren sind eigene Erweiterungen möglich, wenn auch meistens nicht notwendig
  • Java / Xpath
  • http://pmd.sourceforge.net/pmd-4.3.0/howtowritearule.html
  • http://pmd.sourceforge.net/pmd-4.3.0/xpathruletutorial.html
  • https://pmd.github.io/latest/pmd-java/rules/index.html

Beispiel Blacklist für Regeln

<pre class="codeContent">
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         name="pmd-eclipse"
         xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0 http://pmd.sourceforge.net/ruleset_2_0_0.xsd">
    <description>shoeso RuleSet</description>

    <!-- Regeldefinition siehe https://pmd.github.io/latest/pmd-java/rules/index.html -->

    <rule ref="rulesets/java/basic.xml">
        <exclude name="AvoidUsingHardCodedIP"/>
        <exclude name="CollapsibleIfStatements"/>
    </rule>

    <rule ref="rulesets/java/clone.xml">
    </rule>
    ...
</ruleset>

Alle Teile der Serie zu Architekturerhaltung in Java

Dienstag Mär 27, 2018

Werkzeuge zur Erhaltung der Softwarearchitektur - Checkstyle - Teil 9

Checkstyle

In diesem und den kommenden Posts stelle ich die "magischen drei" im Bereich der statischen Code-Analyse vor.
  • Checkstyle
  • PMD
  • Findbugs
Ohne diese Werkzeuge mit geeigneten Regelwerken sollte keine Entwicklungsarbeit mehr erfolgen. Sie sind die Basis für die dauerhafte Einhaltung der Architekturvorgaben und ebenso die Basis für die Vermeidung technischer Schulden. Die einzelnen Werkzeuge kann man inhaltlich nicht klar von einander abgrenzen, da sie größere Schnittmengen haben. Jedes Tool hat seine Stärken in einem anderen Bereich, deckt aber auch vieles anderes ab. Erst die Kombination alle Tools ergibt ein gutes Grundniveau.

Checkstyle ist besonders stark im Bereich der Einhaltung der Kodierungsrichtlinien. Es schafft somit die Basis für das Verstehen von Code, das wie früher schon erwähnt häufig deutlich mehr als 50% unserer Arbeit ausmacht.

Was wird analysiert?

Checkstyle analysiert den Quellcodes des Projekts - also keinen Bytecode.

Besonderheiten

  • Code-Konsistenz / Struktur / Codestyle
  • Dokumentation (Javadoc)
  • in Teilen Komplexität

Integration

  • IDE
  • In die Übernahme in SVN/Git durch die Verwendung von Pre-Commit Hooks
  • Maven-Build (Ausführung und Erzeugen von Basisdaten)
  • Jenkins (GUI und Grenze für ungültige Artefakte)

False Positive Behandlung

  • Parametrisierung bzw. Reduzierung der verwendeten Regeln
  • Codestellen ignorieren: über Annotationen oder einen Kommentar; Konfiguration im SuppressionFilter
  • Ausschluss von Paketen bei der Prüfung: insbesondere auch bei der Verwendung von Pre-Commit Hooks

Regelerweiterung

Die Erweiterung der Regeln ist aus meiner Sicht hier und bei den anderen Werkzeugen lange Zeit nicht notwendig, da die Basisregeln eine gute Basis bieten. Sind alle diese Regeln erfüllt, ist das Projekt im Bereich QS schon einen weiten Weg gegangen. Anpassungen sind möglich über
  • Java
  • http://checkstyle.sourceforge.net/writingchecks.htm

Beispielkonfiguration

Das folgende Beispiel zeigt eine Whitelist - also eine Beschreibung der Regeln, die angewendet werden sollen.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Puppy Crawl//DTD Check Configuration 1.3//EN" 
  "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
<module name="Checker">
    <property name="severity" value="warning" />
    <property name="localeCountry" value="DE" />
    <property name="localeLanguage" value="de" />

    <module name="JavadocPackage">
        <property name="allowLegacy" value="true" />
    </module>
    <module name="TreeWalker">
        <!-- Klassen und Importe -->
        <module name="AbstractClassName">
            <property name="format" value="^Abstract.*$" />
        </module>
        <module name="AvoidStarImport" />
        <module name="PackageName" />
        <module name="RedundantImport" />
...
    </module>
</module>

Pre-Commit Hook

Ein Pre-Commit Hook ist ein Python oder Shell Skript, das vor dem Einchecken auf dem Server ausgeführt wird. In diesem wird das Change Set im SCM ermittelt und auf diesem Checkstyle mit einem geeigneten Regelwerk angewendet. Sind Regeln nicht erfüllt, wird die Übernahme in das SCM System mit einer entsprechenden Fehlermeldung verweigert.

Auf diese Weise bekommt der Entwickler sehr schnelles Feedback und es wird "schlechter" Code gar nicht erst in das SCM aufgenommen.

Alle Teile der Serie zu Architekturerhaltung in Java

Donnerstag Mär 22, 2018

Werkzeuge zur Erhaltung der Softwarearchitektur - JUnit / Selenium / JaCoCo - Teil 8

JUnit / Selenium / JaCoCo

Die zweite Werkzeuggruppe zur Erhaltung der Code-Qualität und Architektur sind Tests. Ich nenne hier nur einige Plugins, die wir primär einsetzen. Es gibt aber noch viele, viele andere.

Die Verwendung von Tests stellt die Zielerreichung sicher. Es wird mit dem Test ein Sollverhalten definiert und die entsprechende Umsetzung geprüft. Somit wird eine Fehlerreduzierung bei der Wartung der Software erreicht, da die Tests sicherstellen, dass das Sollverhalten erreicht wird. Außerdem dienen Tests in einem gewissen Rahmen der Dokumentation. Sie ersetzen aber nicht die Dokumentation im Quellcode, die gerade für eine dauerhaft gute Software, die entscheidende Dokumentationsform ist. Eine explizite Beschreibung an geeigneter Stelle spart Zeit und bietet weniger Platz für Spekulationen bei der Arbeit

Integration

  • IDE: JaCoCo Plungin / JUnit Integration
  • Maven-Build (Ausführung und Erzeugen von Basisdaten)
    • Maven Surefire Plugin (JUnit)
    • Selenium: FlyWay, Wildfly
  • Jenkins (GUI und Grenze für ungültige Artefakte)

Alle Teile der Serie zu Architekturerhaltung in Java

Calendar

Feeds

Search

Links

Navigation