Was ist JQL?

JQL ist eine speziell für Jira entwickelte Abfragesprache. Es lassen sich damit komplexe Suchanfragen erstellen, um bestimmte Vorgänge in Jira zu finden. Im Vergleich zur einfachen Suchfunktion bietet es eine deutlich höhere Flexibilität.

Es kombiniert Schlüsselwörter, Felder, Operatoren und Funktionen. Dadurch können Benutzer spezifische Kriterien für ihre Suche definieren.

Dementsprechend ist die Jira Query Language keine vollwertige Programmiersprache, sondern eine Abfragesprache. Während Programmiersprachen wie Java oder Python vollständige Kontrollstrukturen, Variablenzuweisungen und Schleifen enthalten, dient JQL ausschließlich dazu, Daten innerhalb von Jira zu suchen und zu filtern. Es ähnelt eher SQL in Bezug auf seine Suchmöglichkeiten, hat aber keinen Zugriff auf komplexe Programmierlogik oder externe APIs.

Grundlegende Syntax von JQL

Die grundlegende Syntax einer JQL-Abfrage setzt sich aus drei Elementen zusammen:

• Feld: Das Jira-Feld, das abgefragt wird (z.B. status, assignee, priority).
• Operator: Bestimmt die Beziehung zwischen dem Feld und dem Wert (z.B. =, !=, IN).
• Wert: Der Wert, nach dem gesucht wird (z.B. Open, High, John Doe).

Einfache JQL-Abfragen

Einige Beispiele für einfache Abfragen:

1. Um alle offenen Aufgaben anzuzeigen:

   status = Open

2. Wenn man Aufgaben eines bestimmten Benutzers finden möchte:

   assignee = "Max Mustermann"

3. Falls man nur Aufgaben mit hoher Priorität anzeigen möchte:

   priority = High

4. Wenn man alle Aufgaben eines bestimmten Projekts sucht:

   project = "Marketing"

Erweiterte JQL-Funktionen

Es kann nicht nur einfache, sondern auch komplexe Abfragen durchführen. Dabei kommen logische Operatoren, Vergleichsoperatoren und Funktionen zum Einsatz.

Logische Operatoren

• AND: Verknüpft mehrere Bedingungen, sodass beide erfüllt sein müssen.

  status = Open AND priority = High

• OR: Eine der Bedingungen muss erfüllt sein.

  status = Open OR status = In Progress

• NOT: Negiert eine Bedingung.

  status != Closed

Vergleichsoperatoren

• = : Ist gleich
• != : Ist ungleich
• > : Größer als
• < : Kleiner als
• >= : Größer oder gleich
• <= : Kleiner oder gleich

Beispiel:

created >= "2024-01-01" AND created <= "2024-02-01"

Listen-Operatoren

• IN: Vergleicht mit einer Liste von Werten.

  status IN (Open, "In Progress", Reopened)

• NOT IN: Ausschluss einer Liste von Werten.

  priority NOT IN (Low, Medium)

Funktionen in JQL

Es bietet einige eingebaute Funktionen, die flexiblere Suchanfragen ermöglichen:

• startOfDay(): Beginn des aktuellen Tages
• endOfWeek(): Ende der aktuellen Woche
• now(): Aktueller Zeitpunkt
• updated(): Zeigt an, wann ein Vorgang zuletzt aktualisiert wurde

Beispiel:

updated >= startOfDay()

Diese Abfrage liefert alle Vorgänge, deren Aktualisierung heute stattgefunden hat.

Praxisbeispiele für JQL

1. Alle Aufgaben, deren Erstellung in den letzten 7 Tagen erfolgt ist

created >= -7d

2. Alle abgeschlossenen Aufgaben eines bestimmten Benutzers

status = Done AND assignee = "Max Mustermann"

3. Aufgaben mit Kommentaren in den letzten 24 Stunden

updated >= -1d AND comment IS NOT EMPTY

4. Aufgaben in einem bestimmten Sprint

sprint = "Sprint 15"

5. Alle Aufgaben mit bestimmten Schlagwörtern

labels IN (Bug, "Customer Request")

Fazit

JQL ist ein leistungsstarkes Werkzeug, das Jira-Benutzern hilft, gezielt nach Aufgaben zu suchen und komplexe Filter zu erstellen. Dank der Kombination aus Feldern, Operatoren und Funktionen lassen sich nahezu alle gewünschten Abfragen formulieren. Wer JQL beherrscht, kann Jira effizienter nutzen und relevante Informationen schneller finden.

Wenn Du Jira häufig verwendest, lohnt es sich, Dich damit näher zu beschäftigen. So kannst Du individuelle Abfragen erstellen und eine bessere Übersicht über Deine Projekte erhalten.

Der Beitrag JQL (Jira Query Language) – Eine Abfragesprache erschien zuerst auf CEOsBay.

Grundlagen Inkrementelles Entwicklungsmodell

Das inkrementelle Entwicklungsmodell basiert auf der Idee, ein umfangreiches Softwareprojekt in kleinere, handhabbare Teile zu zerlegen. Entwickler implementieren diese Teile in aufeinanderfolgenden Phasen, wobei jedes Inkrement auf dem vorherigen aufbaut und es erweitert. Diese Vorgehensweise ermöglicht eine frühzeitige Auslieferung von Teilfunktionalitäten, was wiederum eine schnelle Rückmeldung von den Endnutzern erlaubt. Die konsequente Einbindung von Nutzerfeedback in den Entwicklungsprozess führt zu einer höheren Benutzerzufriedenheit und ermöglicht eine effektivere Fehlerbehebung.

Ursprung und Entwicklung

Die Ursprünge des inkrementellen Entwicklungsmodells liegen in den 1960er und 1970er Jahren. Als Softwareingenieure nach flexibleren Alternativen zu den bis dahin vorherrschenden, starren Entwicklungsmodellen suchten. Das inkrementelle Modell bildete eine Antwort auf die wachsenden Anforderungen an Softwarelösungen. Besonders, die Notwendigkeit, sich schnell an veränderte Benutzeranforderungen und Marktbedingungen anzupassen.

Optimale Anwendungsmethoden

Für eine erfolgreiche Anwendung des inkrementellen Entwicklungsmodells gilt es, einige Schlüsselelemente zu berücksichtigen:

1. Klare Definition der Inkremente: Teams sollten jedes Inkrement klar definieren und festlegen, welche Funktionen es umfasst.
2. Kontinuierliche Integration und Testing: Die kontinuierliche Integration neuer Inkremente und deren umfassendes Testing sind unerlässlich. Dadurch lassen sich Fehler frühzeitig identifizieren und somit die Softwarequalität sichern. (Siehe meinen Beitrag über CI/CD – Continuous Integration und Continuous Deployment.)
3. Nutzerfeedback einbeziehen: Entwicklerteams müssen Nutzerfeedback aktiv einfordern und in den Entwicklungsprozess integrieren, um die Software stetig zu verbessern.

Inkrementelles Entwicklungsmodell Beispiele aus der Praxis

1. Mobile Applikationen: Bei der Entwicklung mobiler Apps hat sich das inkrementelle Modell als besonders effektiv erwiesen. Entwicklerteams können einzelne Funktionen wie Benutzeranmeldung, Profilerstellung und Nachrichtenfunktion in separaten Inkrementen implementieren und ausliefern.
2. Web-Plattformen: Auch im Bereich der Web-Entwicklung findet das inkrementelle Modell breite Anwendung. Beispielsweise kann ein E-Commerce-Unternehmen seinen Online-Shop schrittweise um Funktionen wie Produktsuche, Warenkorb und Zahlungsabwicklung erweitern.

Fazit

Ein inkrementelles Entwicklungsmodell stellt einen flexiblen und effizienten Ansatz in der Softwareentwicklung dar. Durch die Zerlegung des Gesamtprojekts in kleinere Teile, die man schrittweise implementiert und testet, ermöglicht eine schnelle Reaktion auf Benutzerfeedback und sich verändernde Anforderungen. Zahlreiche Erfolgsbeispiele aus der Praxis belegen die Effektivität dieses Modells. Dies macht es zu einer attraktiven Wahl für Softwareentwicklungsprojekte unterschiedlichster Art.

Der Beitrag Inkrementelles Entwicklungsmodell – Kleine Schritte, große Fortschritte erschien zuerst auf CEOsBay.

Definition – Strukturelle Tests

Auch bekannt als White-Box-Tests oder Glasbox-Tests, konzentrieren sich auf die interne Perspektive einer Softwareanwendung. Im Gegensatz zu funktionalen Tests, die nur die Anforderungen von Außen prüfen, bieten strukturelle Tests eine vollständige Prüfung der internen Logik und Struktur einer Anwendung.

Notwendigkeit

Es gibt mehrere Vorteile. Sie identifizieren verborgene Fehler, die andere Testmethoden möglicherweise übersehen, erhöhen die Codeabdeckung und verbessern die Qualität der Software. Sie ermöglichen auch eine bessere Identifizierung von Problembereichen, wodurch man effektivere Fehlerbehebungsmaßnahmen einleiten kann.

Durchführung von strukturellen Tests

Strukturelle Tests erfordern ein gründliches Verständnis der internen Softwarearchitektur. Dies schließt Wissen über Datenflüsse, Kontrollstrukturen, Schnittstellen und weitere Details ein. Tester führen eine detaillierte Analyse der Codebasis durch, um Schwachstellen und mögliche Fehlerquellen zu identifizieren. Anschließend erstellt man geeignete Testfälle und führt diese aus, um die Funktionsweise der Anwendung zu überprüfen.

Typen – Strukturelle Tests

Verschiedene Typen struktureller Tests richten sich an spezifische Bereiche der Codebasis. Einige der gängigen Arten sind Kontrollflusstests, Datenflusstests, Pfadtests und Schleifentests. Jeder dieser Tests konzentriert sich auf ein bestimmtes Aspekt des Codes und liefert wichtige Informationen über dessen Leistung und Zuverlässigkeit.

Fazit

Zusammenfassend lässt sich sagen, dass strukturelle Tests ein effektives Mittel sind, um die Qualität und Zuverlässigkeit von Softwareanwendungen zu gewährleisten. Durch eine detaillierte Überprüfung der internen Struktur einer Anwendung tragen sie dazu bei, verborgene Fehler zu identifizieren und sicherzustellen, dass alle Komponenten korrekt funktionieren. Mit ihrer Hilfe kann das Vertrauen in die entwickelte Software erhöht und das Risiko von Fehlern reduziert werden. Es lohnt sich also, in diese Tests zu investieren und sie als festen Bestandteil des Softwaretestprozesses zu etablieren.

Der Beitrag Strukturelle Tests in der Softwareentwicklung erschien zuerst auf CEOsBay.

Was sind Blackbox Tests?

Es handelt es sich dabei um eine Methode des Softwaretestens, bei der man die interne Struktur oder Implementierung der zu testenden Software oder Komponente ignoriert. Im Vordergrund steht vielmehr die Überprüfung des Eingabe-Ausgabe-Verhaltens und die Interaktion mit der Nutzer*innenschnittstelle. Sie konzentrieren sich also auf das „Was“ und nicht auf das „Wie“. Das Pendant dazu sind die „Whitebox Tests„, über die ich gestern geschrieben habe.

Prinzipien

Blackbox Tests folgen grundlegenden Prinzipien, um eine effektive Überprüfung der Software sicherzustellen.

1. Man behandelt das System als unsichtbare Blackbox.
2. Die Tests basieren auf Anforderungs- und Funktionsbeschreibungen.
3. Die Kenntnis der internen Struktur des Systems spielt für die Durchführung der Tests keine Rolle.
4. Sie ermöglichen die Identifizierung von Fehlern in Bezug auf falsche oder fehlende Funktionen, Fehler bei der Schnittstelleninteraktion, Datenstrukturfehler und Performance-Probleme.

Vorteile von Blackbox Tests

Sie bieten zahlreiche Vorteile. Sie erfordern kein spezifisches technisches Wissen und auch Nicht-Programmierer*innen können sie durchführen. Diese Testmethode hilft außerdem dabei, Unstimmigkeiten in den Anforderungen zu entdecken, bevor der Testprozess beginnt. Sie ermöglichen auch eine effektive Überprüfung von Systemreaktionen auf Eingaben und deren Handhabung von Ausnahmesituationen.

Anwendungen von Blackbox Tests

1. Sie finden in unterschiedlichsten Phasen und Bereichen der Softwareentwicklung Anwendung.
2. Man setzt sie häufig in der System-, Akzeptanz- und Regressionstestphase ein.
3. Besonders nützlich sind sie für Web- und Mobile-Anwendungen, Datenbanken (Siehe auch den Beitrag über SQL) und Systeme mit benutzerdefinierten Benutzeroberflächen.

Fazit

Blackbox Tests stellen eine unverzichtbare Methode in der Qualitätssicherung von Software dar. Sie ermöglichen es, den Fokus auf die Nutzer*innensicht und die Erfüllung der Softwareanforderungen zu legen, anstatt sich auf die interne Funktionsweise zu konzentrieren. Indem man den Prinzipien, Vorteilen und Anwendungen von Blackbox Tests Beachtung schenkt, können effektive und benutzerorientierte Softwarelösungen erstellt und bereitgestellt werden.

Der Beitrag Blackbox Tests – Software prüfen, ohne eine Zeile Code zu sehen erschien zuerst auf CEOsBay.

Die Grundprinzipien von Scrum

Scrum basiert auf drei grundlegenden Säulen: Transparenz, Inspektion und Adaption. Diese Säulen stellen sicher, dass alle Beteiligten über den Projektstatus informiert sind, kontinuierlich überprüfen, wie die Arbeit voranschreitet, und bei Bedarf Anpassungen vornehmen, um die Ziele zu erreichen.

Transparenz: Alle Projektinformationen müssen für alle Teammitglieder sichtbar und zugänglich sein. Dazu gehören Fortschritt, Hindernisse und Änderungen am Projektplan.

Inspektion: Das Team prüft regelmäßig die Fortschritte und identifiziert Probleme oder Verbesserungspotenziale. Dies geschieht durch verschiedene Meetings und Feedback-Loops.

Adaption: Hat man Probleme identifiziert, müssen Maßnahmen folgen, um diese zu beheben und den Prozess zu verbessern. Die Umsetzung der Änderungen sollte schnell und effektiv erfolgen.

Rollen in Scrum

Product Owner: Der Product Owner ist für die Definition und Priorisierung der Anforderungen an das Produkt verantwortlich. Verantwortlich für den sogenannten „Product Backlog“, eine Liste von Aufgaben und Funktionen, deren Implementierung in das Produkt erforderlich ist.

Scrum Master: Der Scrum Master ist ein Coach und Vermittler für das Team. Verantwortlich für die Einhaltung der Scrum-Prinzipien und -Praktiken. Hilft bei der Beseitigung von Hindernissen, die die Arbeit des Teams beeinträchtigen können.

Entwicklerteam: Das Entwicklerteam ist eine Gruppe von Fachleuten, die zusammenarbeiten, um die Aufgaben des Product Backlogs in funktionsfähige Produktinkremente umzusetzen.

Artefakte

Scrum verwendet mehrere Artefakte, um die Planung und den Fortschritt des Projekts zu verfolgen:

Product Backlog: Eine Liste aller gewünschten Funktionen, Anforderungen und Verbesserungen, deren Umsetzung im Produkt erforderlich ist. Der Product Owner ist für die Priorisierung und Aktualisierung des Backlogs verantwortlich.

Sprint Backlog: Eine Liste der Aufgaben, die das Team im aktuellen Sprint (einem festgelegten Zeitraum von normalerweise zwei bis vier Wochen) abgeschließt. Die Erstellung des Sprint Backlogs ist die Aufgabe des Entwicklerteams und basiert auf den Prioritäten des Product Backlogs.

Inkrement: Das Ergebnis eines jeden Sprints, ein potenziell auslieferbares Stück des Produkts, das neue oder verbesserte Funktionen bietet. Inkremente sollen den Wert des Produkts für den Kunden kontinuierlich steigern.

Events

Scrum definiert verschiedene Events oder Meetings, um den Kommunikationsfluss und die Zusammenarbeit im Team zu fördern und um den Fortschritt zu überwachen:

Sprint Planning: Zu Beginn jedes Sprints trifft sich das gesamte Team, um den Umfang des nächsten Sprints zu planen. Dabei wählen sie die wichtigsten Elemente aus dem Product Backlog aus und erstellen das Sprint Backlog.

Daily Scrum: Ein tägliches, kurzes Stand-up-Meeting, bei dem jedes Teammitglied den Fortschritt, die Pläne für den Tag und mögliche Hindernisse teilt. Dies fördert die Transparenz und hilft, Probleme frühzeitig zu identifizieren.

Sprint Review: Am Ende jedes Sprints präsentiert das Team das fertige Inkrement dem Product Owner und den Stakeholdern, um Feedback zu erhalten und den Fortschritt zu bewerten.

Sprint Retrospektive: Nach dem Sprint Review reflektiert das Team intern über den Sprint und identifiziert Verbesserungsmöglichkeiten für zukünftige Sprints.

Fazit

Scrum ist ein agiles Rahmenwerk, das den Fokus auf Transparenz, Inspektion und Adaption legt, um den Projekterfolg zu fördern. Durch die Definition klarer Rollen, Artefakte und Events unterstützt Scrum die effektive Zusammenarbeit innerhalb des Teams und die kontinuierliche Verbesserung der Arbeitsprozesse. Die Implementierung von Scrum kann zu einer erhöhten Produktivität, schnelleren Anpassungsfähigkeit an Veränderungen und einer besseren Kundenzufriedenheit führen. Unternehmen und Projektteams, die sich für einen agilen Ansatz entscheiden, können Scrum als wertvolles Instrument in Betracht ziehen, um ihre Ziele zu erreichen.

Der Beitrag Scrum – Kontinuierliche Verbesserung und Anpassungsfähigkeit erschien zuerst auf CEOsBay.

Was ist ein Test-Harnisch?

Ein Test-Harnisch (engl. test harness) ist ein Framework oder eine Sammlung von Tools, die dazu beitragen, das Testen von Softwareanwendungen zu automatisieren, zu koordinieren und zu überwachen. Im Wesentlichen stellt ein Test-Harnisch eine Umgebung bereit, in der Entwickler und Tester den Code einer Anwendung testen und sicherstellen können, dass er korrekt funktioniert und die Anforderungen erfüllt. Man kann Test-Harnische sowohl für manuelles als auch für automatisiertes Testen verwenden.

Funktionsweise eines Test-Harnisch

Ein Test-Harnisch besteht aus vier Hauptkomponenten:

1. Testtreiber: Der Testtreiber ist für die Ausführung der Tests verantwortlich. Er stellt die Schnittstelle zur Verfügung, über die die Tester die Testfälle ausführen und die Ergebnisse erfassen können.
2. Testdaten: Testdaten sind die Eingaben, die man während des Testprozesses verwendet. Sie bestehen in der Regel aus verschiedenen Datentypen, die man verwendet, um die verschiedenen Funktionen und Komponenten der Anwendung zu testen.
3. Testskripte: Testskripte sind Skripte, die den Testprozess automatisieren. Sie enthalten Anweisungen, wie die Tests ausgeführt und die Analyse der Ergebnisse stattfinden soll.
4. Testergebnisse: Testergebnisse sind die gesammelten Informationen, die aus dem Testprozess resultieren. Sie enthalten Daten über die Leistung der Anwendung, Fehler, die während des Testprozesses aufgetreten sind, und Informationen über die Korrektheit der Funktionen.

Vorteile von Test-Harnischen

• Automatisierung: Test-Harnische automatisieren den Testprozess und reduzieren so den Zeitaufwand und die Mühe, die mit manuellem Testen verbunden sind. Dies ermöglicht es Entwicklern und Testern, sich auf die Analyse der Testergebnisse und die Verbesserung der Softwarequalität zu konzentrieren.
• Wiederverwendbarkeit: Test-Harnische ermöglichen es, Testfälle und Testdaten wiederverwendbar zu gestalten, sodass man sie in verschiedenen Projekten und Anwendungen einsetzen kann.
• Vereinfachung: Test-Harnische vereinfachen den Testprozess, indem sie alle Testaktivitäten zentralisieren und eine einheitliche Testumgebung bereitstellen.
• Effizienz: Test-Harnische steigern die Effizienz des Testprozesses, indem sie die Testabdeckung erhöhen, den Testaufwand reduzieren und eine schnellere Fehlerbehebung ermöglichen.
• Kontinuierliche Integration: Test-Harnische unterstützen kontinuierliche Integration (CI) und kontinuierliche Bereitstellung (CD) in der Softwareentwicklung, indem sie die automatisierte Ausführung von Tests bei jedem Commit oder Build sicherstellen. Siehe hierzu den Beitrag über CI/CD.
• Berichterstattung und Analyse: Test-Harnische bieten umfangreiche Berichtsfunktionen, die es Entwicklern und Testern ermöglichen, den Fortschritt und den Status der Tests zu überwachen, Fehler und Schwachstellen schnell zu identifizieren und fundierte Entscheidungen über die Softwarequalität zu treffen.

Gängige Test-Harnisch-Tools in der Softwarebranche

Es gibt viele Test-Harnisch-Tools und Frameworks auf dem Markt, die verschiedene Programmiersprachen und Anforderungen unterstützen. Einige der bekanntesten sind:

JUnit: JUnit ist ein weit verbreitetes Testframework für Java-Anwendungen, das Test-Harnisch-Funktionalitäten wie Testausführung, Testdatenverwaltung und Ergebnisberichterstattung bietet.

TestNG: TestNG ist ein Testframework für Java-Programme, das auf JUnit basiert und erweiterte Funktionen wie Paralleltestausführung, Testkonfiguration und flexible Testskripterstellung bietet.

NUnit: NUnit ist ein Testframework für .NET-Anwendungen, das Test-Harnisch-Funktionen wie Testausführung, Testdatenverwaltung und Berichterstattung bietet.

Pytest: Pytest ist ein Testframework für Python-Anwendungen, das Test-Harnisch-Funktionalitäten wie Testausführung, Testdatenverwaltung und Ergebnisberichterstattung bietet.

Jasmine: Jasmine ist ein Testframework für JavaScript-Anwendungen, das Test-Harnisch-Funktionalitäten wie Testausführung, Testdatenverwaltung und Ergebnisberichterstattung bietet.

Fazit

Test-Harnische spielen eine entscheidende Rolle in der Softwareentwicklung, indem sie den Testprozess automatisieren, vereinfachen und effizienter gestalten. Durch den Einsatz von Test-Harnischen können Entwickler und Tester sicherstellen, dass ihre Anwendungen die gewünschte Qualität erfüllen und potenzielle Fehler frühzeitig identifiziert und behoben sind, bevor der Release stattfindet. Mit der wachsenden Anzahl von Test-Harnisch-Tools und Frameworks auf dem Markt können Entwickler und Tester leicht eine Lösung finden, die ihren spezifischen Anforderungen und Projektzielen entspricht.

Der Beitrag Test-Harnisch – Qualität und Zuverlässigkeit von Anfang an durch effektive Teststrategien erschien zuerst auf CEOsBay.

Im Grunde genommen handelt es sich dabei um zwei Arten von Tools, die zum einen Anweisungen dem Java-Quellcode hinzufügen und dessen Neukompilierung einfordern und zum anderen Tools, die den Bytecode entweder vor oder während der Ausführung instrumentieren. Das Ziel von JaCoCo ist es, herauszufinden, welche Teile des Codes getestet werden, indem es die Codezeilen registriert, die man bei der Ausführung eines Tests ausführt. TDD bzw. Test Driven Development ist diesbezüglich ebenfalls ein gutes Stichwort.

Features von JaCoCo

• Abdeckungsanalyse von Anweisungen (C0), Verzweigungen (C1), Zeilen, Methoden, Typen und zyklomatischer Komplexität (McCabe-Metrik).
• Basiert auf Java-Bytecode und funktioniert daher auch ohne Quelldateien.
• Einfache Integration durch Java-Agent-basierte On-the-fly-Instrumentierung. Andere Integrationsszenarien wie benutzerdefinierte class loader sind über die API möglich.
• Framework-unabhängig: Reibungslose Integration in Java VM-basierte Anwendungen wie einfache Java-Programme, OSGi-Frameworks, Web-Container oder EJB-Server.
• Kompatibel mit allen freigegebenen Java-Klassendateiversionen.
• Unterstützung für verschiedene JVM-Sprachen.
• Verschiedene Berichtsformate (HTML, XML, CSV).
• Remote-Protokoll und JMX-Steuerung zur Anforderung von Ausführungsdaten-Dumps vom Coverage Agent zu jedem beliebigen Zeitpunkt.
• Ant-Tasks zum Sammeln und Verwalten von Ausführungsdaten und zum Erstellen strukturierter Abdeckungsberichte.
• Maven-Plug-in zum Sammeln von Abdeckungsinformationen und Erstellen von Berichten in Maven-Builds.

JaCoCo bietet die Instructions, Line- und Branchabdeckung. Im Gegensatz zu beispielsweise Atlassian Clover und OpenClover, die eine Instrumentierung des Quellcodes erfordern, kann JaCoCo Java Bytecode mit zwei verschiedenen Ansätzen instrumentieren:

1. JCov on the fly, während der Code mit einem Java-Agenten ausgeführt wird beispielsweise wie Cobertura und JCov vor der Ausführung (offline)
2. Man kann es aber auch so konfigurieren, dass man die gesammelten Daten in einer Datei speichert oder via TCP versendet. Im Gegensatz zu Cobertura und EMMA ist die Unterstützung von so ziemlich allen Java Versionen ab der Java Version 7 gewährleistet.

Tools, die JaCoCo verwenden oder enthalten

Einige davon habe ich bereits in diversen Beiträgen thematisiert. Mit einem Klick auf das jeweilige Tool kommt man auf den jeweiligen Beitrag.

• SonarQube JaCoCo Plugin – Standardmäßig für Code Abdeckungsanalysen innerhalb der Code-Qualitätsmanagement-Plattform
• EclEmma Eclipse (Software) Code Coverage Plugin
• Jenkins JaCoCo Plugin
• Netbeans JaCoCo support
• IntelliJ IDEA (Seit Version 11)
• Gradle JaCoCo Plugin
• Visual Studio Team Services
• TeamCity

Fazit

JaCoCo bietet sich für die Codeabdeckungsanalyse bei der modularen Softwareentwicklung bzw. bei den Unit Tests an. Die Abdeckungsgrade geben an, wie viele Anweisungen, Zweige usw. die Tests durchlaufen. Auf Basis der so gewonnenen Erkenntnisse kann man weitere sinnvolle Testfälle ermitteln oder aber nicht beanspruchten bzw. toten Code entfernen. Es gibt kein allgemeingültiges Mindestmaß an Codeabdeckung. Man definiert die jeweils erforderliche Testabdeckung in Anbetracht des Anwendungsfalls nach einer Risikoeinschätzung sowie der eigenen Entwickler-Fähigkeiten.

Der Beitrag JaCoCo – Messen und Optimieren von Testabdeckung für robuste Java-Anwendungen erschien zuerst auf CEOsBay.

Seit 2009 ist es ein Open-Source-Projekt, dass auf gute Testbarkeit ausgelegt ist (An dieser Stelle möchte ich auf den Test Driven Development Beitrag verweisen 😉 ). Dies bietet ein MVC/MVVM-Framework, welches bidirektionales Databinding unterstützt.

MVC/MVVM?

MVVM teilt die verschiedenen Komponenten des Entwicklungsprozesses in drei Kategorien auf. Model, View und ViewModel. In der Regel handelt es sich dabei um Code-Markup oder grafische Benutzeroberflächen (GUI). MVC (Model-View-Control) ist eine Methode, mit der Entwickler Programme in diese drei Komponenten aufteilen. Auf diese Weise lassen sich geschäftliche Anforderungen und Regeln von der Art und Weise unterscheiden, wie Benutzer mit der Anwendung arbeiten. Gerne gehe ich in einem zukünftigen Beitrag näher darauf ein.

Unterschiede zwischen Angular und AngularJS

Angular ist wie bereits erwähnt der Nachfolger von AngularJS. Von Grund auf neu geschrieben, unterscheiden die beiden sich grundsätzlich und in vielerlei Hinsicht.

• Angular kennt keine „scopes“ oder Controller, sondern verwendet eine Hierarchie von Komponenten als zentrales Architekturkonzept.
• Angular hat eine einfachere Syntax für Ausdrücke: Mit „[ ]“ werden Bindings für Eigenschaften und mit „( )“ werden Bindings für Events erzeugt.
• Mobile-First-Ansatz: Die Anforderungen von mobilen Plattformen haben besondere Priorität.
• Modularität: Module können Funktionalitäten auslagern, sodass Code leichtgewichtiger und schneller sein kann.
• Es liegt lediglich die Unterstützung moderner Browser vor, wodurch man weniger Workarounds wegen Browser-Kompatibilitätsproblemen benötigt.
• Angular empfiehlt die Verwendung von TypeScript. Es bietet Klassenbasierte objektorientierte Programmierung, Statische Typisierung und Generics.
• TypeScript ist eine Obermenge von ECMAScript 6 (ES6) und ist rückwärts kompatibel mit ECMAScript 5, damit JavaScript. Angular bietet somit auch die Vorzüge von ES6: (Lambdas, Iteratoren, for…of-Schleifen, Generatoren im Stil von Python, Reflexion)
• Verbesserte Dependency Injection: Bindings ermöglichen die Benennung von Abhängigkeiten.
• Directives dienen dem Zweck, dass Aussehen und Verhalten eines Tags dynamisch zu verändern.
• Dynamisches Laden ist möglich
• Asynchrone Kompilierung von Templates
• Einfacheres Routing
• Kontroller und $scope sind durch Komponenten und Directives ersetzt. Eine Komponente ist eine Directive mit einem Template.
• Reaktive Programmierung mit RxJS

Angular für konventionelle Websites?

Angular ist ideal für Websites mit dynamischem Inhalt, jedoch nicht für kleine Seiten mit statischem Inhalt geeignet. Die Implementierung von Angular erhöht in diesem Fall lediglich die Gesamtgröße des Projekts und folglich auch die Ladezeiten. Dies ist eines der Hauptgründe, warum man Angular nicht für Landing Pages und Websites mit statischem Inhalt verwenden sollte. Davon abgesehen ist Angular weit davon entfernt, SEO-freundlich zu sein. Und im Zeitalter von Search-Engine-Optimization gibt es weitaus bessere Alternativen, um dieses Ziel zu erreichen. Auch ist Angular keine gute Lösung für kurzfristige Projekte oder Start-ups mit begrenzten Ressourcen. Die Komplexität des Front-Ends kann in relativ kurzer Zeit immense Ausmaße annehmen und später schwer zu bändigen sein.

Das Hauptanwendungsgebiet von Angular bestand darin, Einzelseiten-Webanwendungen zu erstellen. Aus diesem Grund verfügt es über eine breite Palette von Werkzeugen für die SPA-Entwicklung. Darüber hinaus ist es eine ideale Technologie für Websites, bei denen sich der Inhalt auf der Grundlage des Nutzerverhaltens und der Präferenzen der Benutzer dynamisch anpasst. Dependency Injections stellen sicher, dass im Falle der Änderung einer Komponente andere Komponenten, die mit ihr in Zusammenhang stehen, automatisch mitgeändert werden.

Die 3 verschiedenen Ladetechniken

Bei der Arbeit mit Angular bieten sich 3 verschiedene Ladetechniken an. Diese sind das Eager Loading, Lazy Loading und Preloading, auf die ich nachfolgend eingehe.

Eager Loading (Eifriges Laden)

Der Abruf aller benötigten Daten möglichst wirksam und umgehend bzw. sofort. Hierzu gibt es im Grunde genommen nicht viel anzumerken. Die Technik ist zwar effizient, doch die Tatsache, dass man eventuell nur einen bestimmten Teil der Daten benötigt aber dennoch alle Daten lädt, kann sich schnell zu einem Nachteil entwickeln, wenn es sich um große Datenmengen handelt.

Lazy Loading (Langsames Laden)

Die am wenigsten eifrige bzw. nicht eifrige Ladetechnik. Wenn man faul ist, tut man so lange nichts, bis man es wirklich muss oder dazu gezwungen wird. Man stelle sich vor, dass die Anwendung drei Bereiche hat. Home, Admin und das Dashboard. Auf den Home-Bereich wird ständig zugegriffen, auf den Dashboard-Bereich die meiste Zeit. Der Admin-Bereich wird jedoch nur von einigen wenigen Nutzern verwendet. Folglich kann man die Admin-Route nach und nach laden. So lange niemand auf die Idee kommt, auf den Verwaltungsbereich der Anwendung zu klicken, wird der damit verbundene Code auch nicht ausgeführt bzw. nicht geladen.

Die Mehrheit der Nutzer lädt den Code für den Verwaltungsbereich schlichtweg nie. Wenn man also Lazy Loading verwendet, kann man grundsätzlich schneller auf die Anwendung zugreifen, da man nicht so viel Code vom Server laden muss. Dies hängt damit zusammen, dass das ORM-Werkzeug (Objekt-Relationales Mapping-Werkzeug) jeglichen Zugriff auf alle Objektreferenzen »abfangen« muss, um hier bei Bedarf die verbundenen Objekte nachladen zu können. Dieses Abfangen erfolgt durch die Verwendung bestimmter Klassen für Einzelreferenzen und Mengenklassen. Der Unterschied zwischen den ORM-Werkzeugen liegt darin, ob der Entwickler diese Klassen explizit im Code verwenden muss oder ob das ORM-Werkzeug diese beim Kompilieren oder zur Laufzeit austauscht.

Preloading (Vorladen)

Die „somewhere-in-between“ (Irgendwie Zwischendrin) Ladetechnik. Beim Preloading macht man im Grunde genommen dasselbe wie beim Lazy Loading, nur ein bisschen anders.

Anhand des Home, Dashboard und Admin Beispiels lässt sich dies folgendermaßen darstellen. Die Startseite braucht man immer. Also lädt man diese schnell bzw. eifrig. Der Admin-Bereich wird nur selten und nur von wenigen Benutzern benötigt, also kann man diesen erst einmal etwas vernachlässigen bzw. „lazy“ laden. Aber das Dashboard ist nicht das Erste, was ein Benutzer sieht, also kann es grundsätzlich erst einmal warten. Doch das Dashboard ist gleichzeitig etwas, dass die meisten der Benutzer irgendwann sehen möchten. Also sollte es zumindest dann zur Verfügung stehen, wenn das Laden des Home-Bereichs fertiggestellt ist. Nach jeder erfolgreichen Navigation sucht der Router in seiner Konfiguration nach einem nicht geladenen Modul, das er vorladen kann.

Der Home-Bereich wird erfolgreich geladen und unmittelbar danach wird der Dashboard-Bereich im Hintergrund geladen.

Welche Ladetechnik kann/soll ich nun verwenden?

Wie bei vielen Angelegenheiten in der IT kommt es hier auf den spezifischen Anwendungsfall und den zur Verfügung stehenden Ressourcen an. Wenn man nicht genau weiß, ob man die zusätzlichen Daten benötigt oder nicht, dann kann es ungünstig sein, sie direkt zu laden. Es kann aber auch ungünstig sein, sie später nachladen zu müssen. Entscheidend bei der Entscheidung ist die Wahrscheinlichkeit, ob und wann man die jeweiligen Daten für wen benötigt, um welche Datenmenge es sich handelt und ob man die Daten später einfach nachladen kann. Zu beachten ist, dass man ein automatisches Nachladen, nach einer Serialisierung, in der Regel nicht mehr initiieren kann.

Release-Frequenz

Angular Releases folgen dem Konzept des Semantic Versionings. Man unterscheidet zwischen Major-, Minor- und Bugfix-Releases. Alle 6 Monate gibt es eine neue Major Release. Major Releases enthalten signifikante neue Features, sind aber nicht abwärtskompatibel. Der Umstieg auf eine neuere Major Release benötigt daher oft Update-Scripts, Refactorings des bestehenden Codes, weitere Tests und das Erlernen neuer APIs. Zu jeder Major Release gibt es ein bis drei Minor Releases. Patch Releases und Pre-Releases gibt es fast jede Woche.

Support

Der Support von Major Releases beträgt typischerweise 18 Monate lang nach Release. Davon 6 Monate aktiv. Aus diesem Grund gibt es in regelmäßigen Abständen Minor Releases und Patch Releases. Es folgt ein 12-monatiger Long Term Support (LTS) in Form von Patch-Releases, ausschließlich zur Behebung kritischer und sicherheitsrelevanter Fehler.

Fazit

Bei der Verwendung von Angular sollte von vornherein klar sein, dass die Realisierung eines Projekts mit der Abnahme vieler Entscheidungen über Architektur und des Renderings verbunden ist. Dies hat den Vorteil, dass sich das Projektteam zu 100% auf die Umsetzung von Features konzentrieren kann und nicht die grundlegende Architektur eigenständig aufbauen muss.

Durch die sehr einheitliche Struktur von Angular Anwendungen lassen sich gute Entwickler sehr schnell in das Projekt integrieren, da Angular Anwendungen stets einer gewissen Struktur folgen. Dies vereinfacht die Skalierbarkeit des Teams als auch des Projektes selbst als vergleichsweise bei Individuallösungen der Architektur in anderen Frameworks.

Generell ist es für Enterprise Projekte sicherlich eine gute Wahl. Dennoch sollte man andere Frameworks wie React und VueJS nicht außer Acht lassen, über die ich in den kommenden Tagen schreibe.

Der Beitrag Angular – Entfaltung des vollen Potenzials von Webanwendungen erschien zuerst auf CEOsBay.

Kurze Zeitreise

Anfang 2001 trafen sich vor der Kulisse der Wasatch Mountains in Snowbird, Utah, 17 Personen, um über die Zukunft der Softwareentwicklung zu diskutieren. Die Mitglieder der Gruppe teilten die Enttäuschung über den aktuellen Stand der Dinge, wenn es um die Softwareentwicklung in agilen Teams ging. Zu diesem Zeitpunkt waren Sie sich einig, dass man etwas ändern muss. Lediglich bestand noch keine Einigkeit darüber, was genau und wie genau es aussehen sollte.

Das Problem, so waren sie sich einig, bestand darin, dass die Unternehmen sich so sehr auf die exzessive Planung und Dokumentation ihrer Softwareentwicklungszyklen konzentrierten, dass sie das Wesentliche aus den Augen verloren – die Zufriedenheit der Kunden.

Die Unternehmen rühmten sich zwar mit Unternehmenswerten wie „Exzellenz“ und „Integrität“, aber diese Werte trugen wenig dazu bei, die Menschen – insbesondere die Softwareentwickler – auf einen besseren Weg zu bringen. Das musste sich ändern. Viele der Snowbird 17 hatten bereits Ideen, wie man die neue Ära der Softwareentwicklung einläuten kann. Die Reise in die Berge war die Chance, dies zu diskutieren.

Aus diesem verlängerten Wochenende ging das Agile Manifest mit gerade einmal 68 Wörtern hervor. Dieses kurze und knappe Dokument sollte die Softwareentwicklung für immer beeinflussen. In den zwei Jahrzehnten, die seit der Entstehung vergangen sind, haben unzähligen Einzelpersonen, Teams und Unternehmen (in unterschiedlichem Maße) diese Worte bzw. die nachfolgenden 4 Kernaussagen und 12 Prinzipien übernommen.

Die 4 Kernaussagen

„Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan„

Folglich

Individuen und Interaktionen stehen über Prozessen und Werkzeugen

Funktionierende Software steht über umfassender Dokumentation

Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung

Eingehen auf Veränderung steht über dem Befolgen eines Plans

Die 12 Prinzipien:

„Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.„

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Lieferung von wertvoller Software zufrieden zu stellen.

„Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.„

Anforderungsänderungen sind auch spät in der Entwicklung willkommen. Agile Prozesse machen Veränderungen für den Wettbewerbsvorteil des Kunden nutzbar.

„Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.„

Liefern Sie regelmäßig, alle paar Wochen bis alle paar Monate, funktionierende Software, wobei ein kürzerer Zeitrahmen bevorzugt wird.

„Business people and developers must work together daily throughout the project.„

Geschäftsleute (Fachleute) und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten.

„Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.„

Bauen Sie Projekte um motivierte Einzelpersonen herum auf. Geben Sie ihnen das Umfeld und die Unterstützung, die sie brauchen, und vertrauen Sie darauf, dass die Arbeit erledigt wird.

„The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.„

Die effizienteste und effektivste Methode der Vermittlung von Informationen an und innerhalb eines Entwicklungsteams ist ein Gespräch von Angesicht zu Angesicht.

„Working software is the primary measure of progress.„

Funktionierende Software ist der primäre Maßstab für den Fortschritt.

„Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.„

Agile Prozesse fördern die nachhaltige Entwicklung. Sponsoren, Entwickler und Benutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.

„Continuous attention to technical excellence and good design enhances agility.„

Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design erhöht die Agilität.

„Simplicity–the art of maximizing the amount of work not done–is essential.„

Einfachheit – die Kunst, die Menge nicht-getaner Arbeit zu maximieren – ist essenziell.

„The best architectures, requirements, and designs emerge from self-organizing teams.„

Die besten Architekturen, Anforderungen und Designs gehen aus sich selbst organisierenden Teams hervor.

„At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.„

In regelmäßigen Abständen reflektiert das Team darüber, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Und das war’s. Seitdem hat sich die Website des Agilen Manifests, wenn überhaupt, nur minimal verändert. Aber die Welt rund um Agile könnte nicht unterschiedlicher sein.

Die große Debatte

Den Snowbird 17 ist es gelungen, ihre unterschiedlichen Standpunkte unter einigen wenigen Kernpunkten zu vereinen. Doch damit war die Debatte noch nicht beendet. In gewisser Weise hat sich Agile in viel mehr Arbeitsweisen aufgesplittert, als die Visionäre es ursprünglich geplant hatten bzw. erahnen konnten. Es scheint, als ob jeder seine eigene Sichtweise von dem Begriff „Agile“ hat und so auch an der eigenen Suppe kocht.

Heute gibt es SAFe und LeSS. Anwendungen von Agile, die nichts mit Softwareentwicklung zu tun haben, auch wenn es im Manifest zu Beginn heißt: „Wir entdecken bessere Wege, Software zu entwickeln, indem wir es tun und anderen helfen, es zu tun“.

Grundsätzlich kann man sagen, dass Zwei Fragen unmittelbar zusammengehören. Die eine richtet sich auf die Wahl des passenden Frameworks als Tool. Die andere auf die Entwicklung der agilen Kultur im Unternehmen. Beides lässt sich nicht getrennt voneinander betrachten.

Darum sollte man sich gleich zu Beginn die Fragen stellen: Was erwartet man? Was soll am Ende des Tages als Ergebnis stehen? Das Skalierungs-Framework selbst ist letztendlich nur ein methodisches Stützrad, um Organisationen Agilität beizubringen. Aber dazu in einem separaten Beitrag mehr.

Dave West, CEO von Scrum.org, der zu verschiedenen Organisationen reist, um agile Praktiken zu beobachten, nannte in einer Publikation ein Forschungsteam, dass agile Methoden einsetzt, um mit Hilfe von Viren ein Heilmittel für genetische Blindheit zu entwickeln.

In der Tat hat sich agiles Vorgehen außerhalb des Softwarebereichs durchgesetzt. Aber es ist nicht unbedingt das, was die Urheber des Manifests beabsichtigten.

Der agile Industriekomplex

Viele argumentieren, dass „Faux Agile“ und sein böser Zwilling „Dark Agile“, durch die Monetarisierung der agilen Ausbildung und Beratung, die gesamte Situation verschlimmern bzw. verschlimmert haben. Einige gehen sogar so weit, dass sie die Organisationen, die hinter dieser Monetarisierung stehen, als „The Agile Industrial Complex“ bezeichnen.

„Es gibt den agilen Cargo-Kult, bei dem man zwar die richtigen Dinge tut und sagt aber die grundlegenden Prinzipien nicht versteht bzw. schlichtweg nicht einhält. Ich selbst kann dies noch nicht so gut beurteilen, da ich noch nicht so viele agile Teams in Aktion gesehen habe, um eine global repräsentative Aussage zu treffen.

Man kann es nennen, wie man will. Ob „faux“, „dark“ oder „Cargo-Kult“, diese agilen Subversionen führen oft zu Situationen, die den Intentionen des Manifests zuwiderlaufen – Mikromanagement, Burnout-Rate, mangelnde Lieferfähigkeiten und das Festhalten an veralteten Prozessen bzw. Konzepten, statt an Prinzipien, sind die auffälligsten Beispiele. Selbst wenn man in dem Bereich ein Zertifikat erworben hat, führen Erfahrungen wie diese, die man in Zusammenhang mit agilen Methoden hatte, oft dazu, dass manche Menschen agilen Methoden ganz abschwören oder sie so umschreiben, dass sie ihre realen Erfahrungen damit widerspiegeln.

Ron Jeffries, einer der Snowbird 17, hat versucht, diesen Irrwegen mit folgender Einschränkung zu begegnen:

“Here and in other writings, I use the quoted word ‘Agile’ to refer to the many instances, approaches, and processes that use the word ‘agile’ to describe themselves, but that do not necessarily adhere to the letter or spirit of Agile Software Development we wrote about in the Agile Manifesto. I will sometimes refer to ‘Faux Agile’ for emphasis, or to ‘Dark Agile’, which I use to describe so-called ‘Agile’ approaches that have really gone bad. I might refer to ‘Manifesto Agile’ to mean the core ideas from the Manifesto, in which I still believe.”

„Hier und in anderen Schriften verwende ich das zitierte Wort ‚Agile‘, um mich auf die vielen Instanzen, Ansätze und Prozesse zu beziehen, die das Wort ‚Agile‘ verwenden, um sich selbst zu beschreiben, die aber nicht unbedingt den Buchstaben oder dem Geist der Agilen Softwareentwicklung entsprechen, über die wir im Agilen Manifest geschrieben haben. Ich beziehe mich manchmal auf „Faux Agile“, um dies zu betonen, oder auf „Dark Agile“, womit ich sogenannte „agile“ Ansätze beschreibe, die wirklich schlecht geworden sind. Mit ‚Manifest Agile‘ bezeichne ich die Kernideen des Manifests, an die ich immer noch glaube.“

Jetzt kann man sich natürlich die Frage stellen, ob das Agile Manifest angesichts der weiten und manchmal fehlgeleiteten Verbreitung von Agile immer noch ein Dokument darstellt, auf das man sich beziehen sollte oder ob es nicht schon obsolet ist.

Ist das Manifest noch relevant?

Nun, nachdem ich mich erst seit kurzer Zeit mit dieser Thematik auseinandersetze, mag meine Einschätzung nicht qualifiziert genug sein. Dennoch glaube ich, dass Zeit relativ ist. Und soweit es mir meine Recherchen und unzähligen Gespräche mit Mitstreitern sowie Entwicklerfreunden gestatten, bin ich davon überzeugt, ein recht gutes Bild von der Ist-Situation erhalten zu haben. Die Antwort lautet „Ja!“. Man kann sich meiner Meinung nach immer noch auf das Manifest beziehen!

Fazit

Die zwölf Prinzipien machen deutlich, dass die Anfänge des agilen Projektmanagements von einer Ablehnung traditionellen Projektmanagements mit intensiver Planung, Überwachung und Steuerung geprägt sind.

Das agile Manifest beinhaltet vier Werte und zwölf Prinzipien. Damit ist es keine Checkliste, die man befolgt und abhakt. Vielmehr gilt es, diese Werte und Prinzipien im Team zu etablieren und damit ein agiles Mindset zu entwickeln.

Damit lassen sich meiner Meinung nach komplexe Anwendungen sinnvoll und human, sowohl mit kleinen als auch großen Teams realisieren.

Der Beitrag Agile Manifest – Die bessere Art der Softwareentwicklung erschien zuerst auf CEOsBay.

Wie funktioniert SonarQube?

SonarQube besteht aus drei Komponenten

1. Einem Modul für Build-Management-Tools wie Apache Maven oder Apache Ant. (Hauptsächlich für die Analyse des Quelltextes hinsichtlich verschiedener Qualitätsmerkmale.)
2. Einer Datenbank, für Speicherung der Ergebnisse der Qualitätsanalyse.
3. Einer Website für die visuelle Darstellung, Auswertung und das Management der Qualitätsanalyse-Ergebnisse.

Durch diese Architektur kann man sowohl eine Prüfung des Quelltextes auf dem Entwicklungsrechner ermöglichen als auch eine Einbindung von SonarQube in den Entwicklungsprozess gewährleisten. Dies unterstützt die Ermittlung der Qualitätsmetriken auf einem Build-Server für die kontinuierliche Integration.

SonarQube analysiert den Quelltext hinsichtlich der Abdeckung durch Modultests, checkt den Quellcode nach doppeltem Code und in Bezug auf die Komplexität. Auch werden unter anderem potenzielle Fehler im Code, Kodier-Richtlinien als auch Kommentare überprüft.

Modularer Aufbau und Erweiterungen

SonarQube ist modular aufgebaut und integriert selbst einige bekannte Entwicklungswerkzeuge zur Analyse der Codequalität, darunter PMD und Checkstyle für die Erkennung von doppeltem Code für die Prüfung von Kodier-Richtlinien. Damit wird unter anderem auch nach ineffizientem Code gesuche. FindBugs dient beispielsweise zum Aufdecken potenzieller Fehler sowie Surefire und Cobertura zur Messung der Qualität der Modultests.

Diese Werkzeuge nutzen entsprechend ihrer Natur und Einsatzgebiete Metriken, um die jeweiligen Auswertungen bzw. Statistiken zu erzeugen. Der Name „Metrik“ trägt jedoch wenig Bedeutung von dem in sich, was eine Metrik ausmacht. Schlägt man nämlich nach woher der Name kommt, landet man im Lateinischen: „ars metrica„, die Lehre von den Maßen. Fragt man jedoch das Institute of Electrical and Electronics Engineers, was eine Softwaremetrik ist, erhält man folgende Antwort:

„software quality metric: A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which software possesses a given attribute that affects its quality.“ „Eine Softwarequalitätsmetrik ist eine Funktion, die eine Software-Einheit in einen Zahlenwert abbildet, der als Erfüllungsgrad einer Qualitätseigenschaft der Software-Einheit interpretierbar ist.“ – IEEE Standard 1061, 1998

Folglich bedeutet dies, dass es sich bei einer Metrik am Ende des Tages um eine Funktion handelt, die für beliebige Eingaben Zahlen erzeugt. Die Beschaffenheit ist so, dass sie, nur so 

lange sie von derselben Funktion erzeugt wurden, vergleichbar sind. Dadurch kann man Rückschlüsse auf die Eingabe mit Hinblick auf die Funktion erzielen.

Ein Beispiel dafür ist die McCabe-Metrik, auch zyklomatische Komplexität genannt. Diese sehr grundlegende Metrik berechnet die Anzahl der unterschiedlichen Pfade durch ein Stück Code. Die Formel ist relativ einfach: Es wird die Anzahl an Kontrollstrukturen wie if, while, case und boolescher Operatoren wie && und || summiert und nochmals mit 1 addiert. Möchte man diese Information nochmals anhand eines Beispiels betrachten, sieht es folgendermaßen aus:

String nameDesWochenTags(int nr) {
  switch(nr) {
    case 1: return "Montag";
    case 2: return "Dienstag";
    case 3: return "Mittwoch";
    case 4: return "Donnerstag";
    case 5: return "Freitag";
    case 6: return "Samstag";
    case 7: return "Sonntag";
  }
  return "";
}

Diese relativ einfache Methode gibt den Namen eines Wochentages entsprechend seiner 1-indizierten Position innerhalb der Woche zurück. Ihre zyklomatische Komplexität beträgt 8. Zumal 1 + 7 x case. Dies ist ein verhältnismäßig hoher Wert. Ein Maximalwert von 10 gilt als allgemein akzeptiert und ausreichend erprobt. Um also die Komplexität dieser Methode zu verringern, findet eine Refaktorisierung statt, die folgendermaßen aussehen kann:

String nameDesWochenTags(int nr) {
  String[] names = new String[] {
    "Montag", "Dienstag", "Mittwoch",
    "Donnerstag", "Freitag", "Samstag",
    "Sonntag"
  };
  if(nr) > 0 && <= names.length) {
    return names[nr - 1];
  }
  return "";
}

Die zyklomatische Komplexität dieser Methode beträgt 3. Zumal 1 + 1 x if + 1 x &&. Durch den unterschiedlichen Ansatz kann man die Komplexität verringern. Dennoch ist es relativ unstrittig, dass die erste Version leichter zu verstehen ist.

Will man nun also alle Tools gemeinsam benutzen, muss man alle konfigurieren und ihre Ergebnisse zusammenführen, damit sich ein Gesamtbild darstellen lässt. Außerdem kommt es dabei zwangsweise zu Dopplungen in ausgewerteten Metriken oder anderen Kennzahlen. PMD beispielsweise besitzt durch seinen relativ vagen Aufgabenbereich Überschneidungen im Hinblick auf Codestil mit checkstyle, während es aber auch genauso wie FindBugs auf toten Code achtet. An solchen und weiteren Stellen kann SonarQube Verbesserungen herbeiführen.

Neben der visuellen Anzeige der Ergebnisse der einzelnen Bereiche, ermöglicht SonarQube das Drill-Down der Ergebnisse bis auf die einzelne Metrik und Codezeile sowie die Verknüpfung der einzelnen Metriken sowie die Darstellung ihrer historischen Entwicklung in einer recht übersichtlichen grafischen Oberfläche.

Über einen ausgeklügelten Plugin-Mechanismus ist eine relativ einfache Integration von Erweiterungen möglich. Neben den Erweiterungen für die Analyse zusätzlicher Programmiersprachen gibt es Plugins für ergänzende Metriken, Governance, Schnittstellen zu Entwicklungsumgebungen, Visualisierungen, Integration sowie zur Berechnung der technischen Schuld(en).

Fazit

Ich arbeite noch nicht so lange mit SonarQube. Um genau zu sein, habe ich es mir erst heute das erste Mal angeschaut. Zusammenfassend kann ich folgendes sagen:

Statistiken sind zwar interessant und es kann Spaß machen, sich diese anzuschauen, doch ist eine statische Codeanalyse erst dann wirklich vollständig, wenn ein Mindestmaß an Interpretation hineingeflossen ist.

Die Codeanalyse liefert ein gutes Gefühl für die Codebasis. Erst so kann man fundierte Aussagen darüber treffen, welche Bereiche des Projekts besonders gefährdet, instabil oder verbesserungsfähig sind.

Regelmäßige Analysen können die Teammotivation erhöhen. Eine positive Issuebilanz am Ende eines Sprints und aufwärtszeigende Historiengraphen sollten gute Treiber für eine Gruppe Entwickler und ein Beweis für die eigene Leistung sein.

Alles in allem sind Analyseergebnisse immer gut als Argumentationsgrundlage. Mit Hilfe der Projekthistorie, die eine Auswahl gut darstellbarer Kennzahlen beinhaltet, kann man vor Kunden oder Entscheidern besser über ein eventuell nötiges technisches Release diskutieren.

Der Beitrag SonarQube – Das Code-Qualitätsmanagement-Tool erschien zuerst auf CEOsBay.