Suche
Strategisch wählen

Frameworks und Tools (nicht nur) für große Java-EE-Projekte richtig auswählen

Michael Schnell

© Shutterstock/Dziobek

Frage: „Warum habt Ihr gerade diese Bibliothek ausgewählt?“ Antwort: „Weiß ich nicht mehr. Hat damals Peter hinzugefügt. Leider können wir ihn nicht mehr fragen, da er das Projekt schon verlassen hat.“ Solche oder ähnliche Dialoge kennt vermutlich jeder, der neu in ein Projekt kommt. Wäre es nicht besser, wenn man an dieser Stelle einfach auf die Architekurdokumentation verweisen könnte? Dieser Artikel zeigt, wie man strukturiert eine solche Auswahl treffen kann und nachvollziehbar dokumentiert.

Wer schon einmal in großen Softwareentwicklungsprojekten mitgearbeitet hat, weiß: Hier gelten andere Regeln als bei kleinen Projekten. Kann man in überschaubaren Teams noch „schnell mal etwas ausprobieren“, wird dies bei größeren Gruppen leicht zu einem Kosten-, Zeit- und Qualitätsproblem.
Jeder Fehler multipliziert sich schon während der Entwicklung mit der Anzahl der Entwickler: 80 Entwickler können eine Stunde nicht arbeiten und schon sind zwei volle Arbeitswochen verbrannt worden. Noch schlimmer wird es in der Produktion: 2 000 Anwender können eine Viertelstunde nicht arbeiten und 12 ½ Arbeitswochen sind verloren …
Eine gezielte Auswahl der richtigen Tools und Frameworks ist daher ein zentraler Baustein für ein erfolgreiches Projekt und einen stabilen Betrieb. Wie findet man aber die „richtigen“ Tools und Frameworks?
Wichtig ist eine strukturierte und rationale Herangehensweise, welche die getroffenen Entscheidungen auch dokumentiert und nachvollziehbar macht. Entscheidungen „aus dem Bauch heraus“ sollen vermieden werden, um das Risiko von Fehlentscheidungen zu minimieren.
Um eine fundierte Entscheidung treffen zu können, braucht man sinnvolle Kriterien für den Vergleich der zur Auswahl stehenden Optionen. Aus Sicht der Architektur gibt es im Wesentlichen vier Punkte:

  • Technische Eignung (K.-o.-Kriterium)
  • Leicht zu verstehen
  • Qualität/Stabilität
  • Gute Dokumentation/Information

Betrachtet man diese Frage aus dem Blickwinkel der Projektleitung, kommen vier weitere Punkte hinzu:

  • Entwickler mit Know-how sind verfügbar
  • Langjähriger Support ist gesichert
  • Kostengünstig
  • Passende Lizenzierung

Im Folgenden soll als Beispiel eine Java-Persistence-(JPA-)Implementierung ausgewählt werden.

Die Kandidaten

Ein guter Einstiegspunkt für eine Recherche sind die Suchmaschinen (Abb. 1). Meistens reicht es schon aus, die ersten zwei bis drei Ergebnisseiten durchzuarbeiten. Unter dem Begriff „JPA Implementations“ finden sich schnell einige Kandidaten:

Die erste Überraschung ist DataNucleus: Ein eher unbekanntes, aber JPA-2.1-konformes Framework, das dazu auch noch JDO-Funktionalität bietet. Bei einer spontanen Auswahl wäre diese Bibliothek vermutlich gar nicht betrachtet worden.

Abb. 1: Guter Einstiegspunkt: Die Suchmaschinen

Abb. 1: Guter Einstiegspunkt: Die Suchmaschinen

Vorbereitung

Technische Eignung (K.-o.-Kriterium): Das Java Persistence API liegt derzeit in der Version 2.1 vor, die mit dem JSR 338 spezifiziert wurde. Sowohl DataNucleus, EclipseLink (Referenzimplementierung des JSR) als auch Hibernate ORM setzen die aktuellen Features vollständig um. BatooJPA und OpenJPA hingegen unterstützen lediglich die Vorgängerversion 2.0. Da wir auf dem aktuellen Stand der Technik arbeiten wollen, scheiden beide Libraries an dieser Stelle leider aus. Damit sind nur noch DataNucleus, EclipseLink und Hibernate im Rennen.

Leicht zu verstehen: Generell sollte bei Frameworks die Devise gelten: Wenn Du es nicht wirklich brauchst, verwende es nicht. Jede vorgefertigte Bibliothek erhöht die Komplexität und will erst einmal verstanden werden. Ein gutes Beispiel dafür sind gerade O/R Mapper in Java mit dem verführerischen Versprechen: „Du brauchst Dich um die Datenbank gar nicht zu kümmern – schreib einfach Deine Java-Objekte und der O/R Mapper kümmert sich um alles“. Was bei einem typischen „Hello World“-Beispiel noch prima funktioniert und einfach aussieht, wird bei umfangreichen Enterprise-Projekten schnell zu einem Alptraum. Neben der Frage, ob man es wirklich benötigt, sollte daher auch die Komplexität der hinter dem Framework versteckten Funktionalität betrachtet werden. Kann ein durchschnittlicher Entwickler noch verstehen, was dort passiert? Wer kann helfen, wenn es nicht wie gewünscht läuft? Im untersuchten Fall setzen alle drei Kandidaten den Standard „JPA“ um und sind damit gleichermaßen leicht oder schwer zu verstehen. Für unser Beispiel spielt dieser Punkt daher keine große Rolle und wird nicht weiter betrachtet.

Support und Preis: Da es sich bei allen drei Kandidaten um (kostenfreie) Open-Source-Software handelt, kann ein langjähriger Support als gesichert gelten. Selbst wenn eine Bibliothek also zukünftig nicht mehr weiterentwickelt werden würde, besteht die Möglichkeit, selber Bugs zu fixen oder einen Spezialisten dafür zu engagieren. Bei kommerzieller (Closed-Source-)Software ist hier mehr Vorsicht geboten. Der Hersteller sollte entweder ein großes, renommiertes Unternehmen sein oder der Quellcode der Bibliothek müsste bei einem Treuhänder hinterlegt werden (Software Escrow). Im Falle einer Insolvenz könnte dann notfalls darauf zugegriffen werden. Im Vorfeld einer solchen Vereinbarung ist es ggf. auch ratsam, den Quellcode einzusehen und ein Qualitätsaudit durchzuführen.

Passende Lizenzierung: Ein wichtiger Punkt, der bei Verwendung von Open-Source-Software gerne vergessen wird, ist die Frage der Lizenz. Da vermutlich kaum jemand seinen kommerziellen Quellcode später offenlegen möchte, scheidet z. B. eine Bibliothek mit einer viralen Lizenz, wie die GNU General Public License (GPL), von vornherein aus. Unsere drei Kandidaten sind unter GNU Lesser General Public License 2.1 (Hibernate), Apache-2-Lizenz (DataNucleus) und Eclipse Public License v1.0/Eclipse Distribution License v1.0 (EclipseLink) verfügbar und können deshalb alle problemlos verwendet werden.

Das Werkzeug: Gewichtete Entscheidungsmatrix: Am besten lassen sich die verschiedenen Kriterien mit einer Entscheidungsmatrix übersichtlich darstellen, auswerten und dokumentieren. Für die Bewertung der Optionen wird z. B. eine Schulnote verwendet (15 = Bester Wert, 0 = Schlechtester Wert). Um die Bedeutung einzelner Aspekte herauszustellen, werden die Kriterien zusätzlich gewichtet (Gewichtete Entscheidungsmatrix).

Um die Punktezahl für messbare Aspekte zu ermitteln, wird der höchste gemessene Wert („Erg.“) mit 15 Punkten bewertet. Die anderen Werte werden dann relativ dazu in Punkte umgerechnet. Danach werden die ermittelten Punkte („Pt.“) anhand des vorgegebenen Gewichts in gewichtete Punkte („Gew.“) umgerechnet und zum Ergebnis summiert.

Bei subjektiven (nicht messbaren) Aspekten wird der Punktestand direkt eingetragen und das Ergebnisfeld bleibt leer. Auf Basis der Punkte können messbare und subjektive Aspekte miteinander kombiniert werden (Abb. 2).

Abb. 2: Gewichtete Entscheidungsmatrix – Kriterien können *messbar oder **subjektiv sein

Abb. 2: Gewichtete Entscheidungsmatrix – Kriterien können *messbar oder **subjektiv sein

Entscheidungsfindung

Qualität/Stabilität: Weder bei kleinen noch bei großen Entwicklungsprojekten möchte man in Stabilitätsprobleme laufen. Wie aber findet man heraus, ob eine Bibliothek stabil ist und eine gute Qualität hat?

Zunächst kann man auf die Lebensdauer, Aktivität und Verbreitung des Projekts schauen: Eine lange Historie mit aktiver Entwicklung und ein hoher Verbreitungsgrad sind gute Indikatoren um davon ausgehen zu können, dass viele Fehler schon bei jemand anderem aufgetreten und längst gefixt sind.

Die Codequalität eines Projekts ist ein weiterer entscheidender Faktor. Man kann sie über verschiedene Metriken mit Tools wie Checkstyle, FindBugs, JDepends, Cobertura oder Emma ermitteln und vergleichen.

Der Einfachheit halber wird nachfolgend als Beispiel das (kommerzielle) Tool „inFusion“  der Firma Intooitus verwendet, da es eine große Anzahl verschiedener Aspekte abdeckt und das Ergebnis vereinfacht in Form eines „Quality Deficit Index“ (QDI) bereitstellt.

  • Gute Codemetrik (Qualitätsindex)
  • Lange Projekthistorie (Anzahl Jahre – com)
  • Aktive Entwicklung (Anzahl Entwickler, Anzahl Commits ‑ net)

Für unser Beispiel ergeben sich die Werte in Abbildung 3. Der von inFusion ermittelte „Quality Deficit Index“ (QDI) ist indes ein negativer Wert. Es gilt: „Kleiner ist besser“. Um einen positiven Wert für die Matrix zu erhalten („größer ist besser“), wurde der QDI in einen „Quality Index“ (QI) umgerechnet. Es wurde folgendes Ergebnis erzielt:

  • Eclipselink QDI 21,6 = QI 20
  • Hibernate QDI 20,6 = QI 21
  • DataNucleus QDI 20 = QI 21,6
Abb. 3: Qualität/Stabilität

Abb. 3: Qualität/Stabilität

Gute Dokumentation/Information

Die zentrale Anlaufstelle für jedes Framework oder Tool ist ganz sicher das Internet. Gibt es eine gut organisierte Homepage? Ist die verfügbare Dokumentation ausreichend? Sind Beispiele vorhanden? Bei ausreichend verbreiteter Software stehen zusätzlich Foren, Blogs, FAQs (Abb. 4) und andere externe Informationsseiten bei Problemen oder Fragen zur Verfügung.

  • Anzahl Ergebnisse in Suchmaschinen (google.com)
  • Wie viele Einträge in den FAQ? (stackoverflow.com)
  • Gibt es viele Präsentationen? (slideshare.net)
  • Gute Dokumentation (Subjektives Kriterium)
  • Anzahl Bücher (amazon.com)
  • Übersichtliche Homepage (Subjektives Kriterium)
Abb. 4: Hilfe gesucht: Wie viele Antworten liefern FAQs?

Abb. 4: Hilfe gesucht: Wie viele Antworten liefern FAQs?

Übertragen auf die zur Auswahl stehenden JPA-Implementierungen ergibt sich ein Bild wie in Abbildung 5.

Abb. 5: Gute Dokumentation/Information   [*Subjektive Kriterien]

Abb. 5: Gute Dokumentation/Information [*Subjektive Kriterien]

Entwickler mit Know-how sind verfügbar

Der erste Faktor, den es zu ermitteln gilt, ist das Know-how im vorhandenen Team. Wie viele Entwickler kennen sich mit dem Tool/Framework bereits aus? Wie aufwändig ist es, sie gegebenenfalls zu schulen? Bei großen Teams ist es außerdem normal, dass regelmäßig neue Entwickler ins Projekt kommen und andere es verlassen. Gibt es am Markt genügend Personal mit dem entsprechenden Know-how? Muss jeder neue Entwickler zunächst aufwändig geschult werden, falls es keine passenden Ressourcen gibt?

  • Know-how im Team (Befragung)
  • Anzahl verfügbarer Entwickler außerhalb des Teams (gulp.de)
  • Generelles Interesse (LinkedIn und Monster)

In unserem Beispiel besitzen wir ein Team von insgesamt 50 Entwicklern. Über eine Befragung haben wir ermittelt, wer schon einmal mit EclipseLink, Hibernate oder DataNucleus gearbeitet hat. Im deutschsprachigen Raum liefert gulp eine gute Übersicht der verfügbaren Freiberufler mit dem entsprechenden Stichwort. Um die Popularität des Frameworks noch mit einzubeziehen, ermitteln wir auch die Anzahl der Profile bei LinkedIn und suchen bei Monster nach entsprechenden Stellenangeboten (Abb. 6).

Abb. 6: Jobportale liefern einen guten Anhaltspunkt, wie verbreitet ein bestimmtes Know-how ist

Abb. 6: Jobportale liefern einen guten Anhaltspunkt, wie verbreitet ein bestimmtes Know-how ist

Berücksichtigt man diese Aspekte, ergibt sich für das Beispiel die Tabelle in Abbildung 7.

Abb. 7: Entwickler mit Know-how sind verfügbar

Abb. 7: Entwickler mit Know-how sind verfügbar

And the winner is …

In der Gesamtübersicht werden die einzelnen Teilaspekte zusammengefasst und erneut gewichtet. So ergibt sich eine eindeutige Reihenfolge bei den zur Auswahl stehenden Optionen. Im konkreten Beispiel ist der Gewinner – wie erwartet – mit deutlichem Abstand Hibernate. Überraschend für uns ist, dass das eher unbekannte DataNucleus nur knapp hinter EclipseLink liegt (Abb. 8).

Abb. 8: Die finale Entscheidungsmatrix

Abb. 8: Die finale Entscheidungsmatrix

Fazit

Eine gewichtete Entscheidungsmatrix ist eine große Hilfe, um strukturiert und rational eine Auswahl zu treffen. Welche Aspekte letztlich in die Tabellen einfließen und wie sie gewichtet werden, bleibt dem Entscheider überlassen. Es ist auf jeden Fall sinnvoll, diese Auswahl mit mehreren erfahrenen Entwicklern zu treffen, da das Ergebnis je nach Kriterien stark variieren kann. Deshalb ist eine gemeinsame Sicht des Teams auf das Problem besonders wichtig. Naturgemäß wird es hier unterschiedliche Ansichten geben, aber am Ende ist eine getroffene Entscheidung nachvollziehbar und sauber dokumentiert.

Aufmacherbild: Male hand moving the black chess knight von Shutterstock / Urheberrecht: Dziobek

Verwandte Themen:

Geschrieben von
Michael Schnell
Michael Schnell
Michael Schnell betreut ein Java Competence Center bei der Lufthansa Industry Solutions. Er ist seit mehr als 25 Jahren im Bereich der Softwareentwicklung tätig, davon rund sechzehn Jahre mit Schwerpunkt Java. Wenn es die knappe Zeit zulässt, entwickelt er auch immer noch gerne selbst ein paar Zeilen Code.
Kommentare
  1. Waldemar2015-12-07 10:04:25

    tl;dr

    Impliziert Java EE und die Wahl eines AS nicht schon die JPA-Implementierung?

  2. Laura2018-02-07 17:44:44

    schöner Artikel, vielen Dank.

    @Waldemar: Es ist nur ein Beispiel für das Verfahren der Software-Auswahl. Statt tl,dr hättest du es einfach lesen und dir damit diesen Kommentar sparen können.

  3. TestP2018-02-08 12:41:41

    @ Waldemar
    Nein, man kann im AS auch die Implementierung wechseln.

    -

    Ansonsten würde ich jetzt die Anzahl der Google- und SO-Treffer nicht in so eine Gewichtung einfließen lassen. Das kann nämlich auch ein Hinweis darauf sein, dass viele Leute mit der Komponente Probleme haben.

    Grüße

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.