Bibliotheken auswählen und bewerten
In L3 hast du Paketmanager kennengelernt – sie holen Bibliotheken in dein Projekt. Aber welche Bibliothek solltest du wählen, wenn du zwischen 20 Optionen entscheiden musst? Diese Frage ist nicht trivial – die falsche Wahl rächt sich Jahre später durch unwartbaren Code, Sicherheitslücken oder Lizenz-Probleme.
Diese Lektion zeigt dir einen systematischen Auswahl-Prozess: welche Kriterien sind wichtig, wie bewertet man eine Bibliothek, wann macht eine eigene Implementation mehr Sinn als eine Drittbibliothek, und welche Lizenz-Fallen lauern.
1) Build vs. Buy – die erste Entscheidung
Bevor du eine Bibliothek auswählst, frag dich: muss ich überhaupt eine? Manche Funktionen sind so simpel, dass eine eigene Implementation besser ist. Andere so komplex, dass selbst bauen Wahnsinn wäre.
2) Die wichtigsten Auswahl-Kriterien
Wenn du eine Bibliothek kaufen willst, gibt es klare Kriterien. Hier die wichtigsten:
npm audit / Snyk-Scores prüfen.3) Bewertungs-Scorecard – interaktiv
So sieht eine systematische Bewertung in der Praxis aus. Probier die Scorecard für eine fiktive Bibliothek (z.B. SuperLogger). Klick auf die Sterne – die Punkte werden live addiert:
4) Open-Source-Lizenzen verstehen
Lizenzen sind das am meisten unterschätzte Risiko. Wer eine GPL-lizenzierte Bibliothek in einem kommerziellen Produkt nutzt und es nicht weiß, hat ein massives rechtliches Problem. Hier die wichtigsten Lizenzen:
| Lizenz | Was bedeutet das? | Kommerziell? |
|---|---|---|
| MIT | Mach was du willst, behalte die Lizenz im Code-Header. | ✓ Ja |
| Apache 2.0 | Wie MIT + Patent-Schutz + Hinweis-Pflicht für Änderungen. | ✓ Ja |
| BSD-3 | Wie MIT, mit Werbe-Klausel ähnlich Apache. | ✓ Ja |
| LGPL | Linkbar an proprietären Code, eigene Änderungen müssen offen sein. | ⚠ Eingeschränkt |
| GPL v3 | Copyleft: dein gesamtes Projekt muss unter GPL stehen! | ⚠ Riskant |
| AGPL | Wie GPL, aber auch für Web-Services (gilt auch bei reiner Nutzung über das Netz). | ⚠ Sehr restriktiv |
| Proprietär | Hersteller-Lizenz, oft mit Gebühren und Nutzungs-Limit. | ⚠ Kosten |
| Public Domain / CC0 | Komplett frei, keine Bedingungen. | ✓ Ja |
5) Wo finde ich gute Bibliotheken?
Quellen für die Recherche:
- npmjs.com: für JS/TS. Suche, Downloads-Statistik, Dependents-Liste.
- PyPI (pypi.org): Python-Pakete mit Statistiken.
- Maven Central (search.maven.org): Java-Bibliotheken nach GAV.
- GitHub: Stars, Issues, Last-Commit, Code lesen. Direkter Einblick in die Qualität.
- Awesome-Listen: kuratierte Listen wie awesome-python, awesome-java – Standard-Empfehlungen.
- StackOverflow: Diskussionen über „X vs Y" finden meistens etablierte Empfehlungen.
- State-of-X-Surveys: State of JS, State of Java – jährliche Beliebtheits-Übersichten.
- libraries.io / Sourcegraph: Cross-Repository-Suche mit Metriken.
6) Praxis-Beispiel: HTTP-Client für Java
Du brauchst einen HTTP-Client in Java. Was wählen? Die Optionen 2026 grob:
- java.net.HttpClient (Java 11+): in der Standardbibliothek, keine extra Dependency, modern. Standard-Wahl heute.
- OkHttp: sehr populär, gut gepflegt von Square, viele Features.
- Apache HttpClient: Klassiker, sehr mächtig, dafür schwergewichtig.
- Spring RestTemplate / WebClient: wenn du Spring Boot nutzt.
- Unirest: einfache API, weniger verbreitet.
Faustregel: erst Standard-Bibliothek prüfen, dann etablierte Bibs. Wer einen exotischen Newcomer wählt, übernimmt das Risiko.
7) Versionsstrategie für Bibliotheken
Wenn du eine Bibliothek nutzt, ist die Versions-Frage wichtig. Drei Ansätze:
- Latest-and-greatest: immer aktuellste Version. Modernste Features, aber Risiko von Breaking Changes.
- Latest-stable: aktuellste, aber kein Beta/RC. Standard-Wahl für die meisten.
- LTS (Long-Term-Support): bestimmte Versionen werden lange gepflegt (z.B. Spring Boot 3.x LTS). Sicher, aber manchmal verpassst du Features.
- Konservativ: Version pinnen, manuell updaten. Bei sicherheitskritischen Bibs.
Vgl. K51 L7 für mehr zu SemVer und Versionierung.
8) Anti-Patterns bei der Bibliothekswahl
- Hype-Driven Development: die neueste Bib nehmen, weil sie auf Twitter trending war. 6 Monate später nicht mehr gepflegt.
- Bib für 5 Zeilen Code: sinnloser Mehraufwand, Risiko-Vergrößerung. Berühmt: left-pad – eine 11-Zeilen-Funktion brachte 2016 das halbe npm-Ökosystem zum Erliegen, als sie zurückgezogen wurde.
- Verkrampfter Tausch: bestehende Bib durch neue ersetzen, ohne klaren Vorteil. „Refactor-around"-Aufwand übersteigt Nutzen.
- Mehrere ähnliche Bibs: 3 verschiedene HTTP-Clients im selben Projekt. Wartungs-Hölle.
- Override transitive Versionen: Bibliothek X braucht Lib-Y in v1.2, du forcierst v1.5 → läuft vielleicht, vielleicht auch nicht.
9) Was tun bei „End of Life"?
Auch die beste Bibliothek wird irgendwann nicht mehr gepflegt. Wenn das passiert:
- Erkennen. Last-Commit-Monitoring, EOL-Listen wie endoflife.date.
- Bewerten. Wie kritisch? Wie viel Code hängt dran?
- Alternativen prüfen. Gibt es Forks? Successor-Projekte?
- Migration planen. Schichtenarchitektur (vgl. K50 L6) hilft – wenn die Bib nur an einer Stelle benutzt wird, ist Tausch leicht.
- Im Notfall forken. Open-Source-Lizenz erlaubt es – eigene Patches pflegen.
Zusammenfassung
Vor dem Hinzufügen einer Bibliothek: Build vs. Buy entscheiden. Kriterien: Aktivität, Popularität, Doku, Lizenz, Größe, Sicherheit, Tests, Abhängigkeiten, Community. Lizenzen: MIT/Apache 2.0 → unkritisch kommerziell, GPL → Copyleft (Risiko), AGPL → auch für Web-Services. Standard-Bibliothek vor Drittlib prüfen. Anti-Patterns: Hype-Driven, Bib für 5 Zeilen, mehrere ähnliche. Nächste Lektion: Bestehende Anwendungen lesen und anpassen.