Shared Libraries

geschrieben von Jürgen Happe, Lesezeit 2 Minuten
Die gemeinsame Nutzung von Code in Ihrem Team oder Unternehmen ist eine wirklich gute Idee, aber wenn Sie es falsch machen, werden Sie viel mehr verlieren als gewinnen können.
Shared Libraries

Warum Code teilen?

Teams, die langfristig zusammenarbeiten, werden früher oder später mit mehr als einer Anwendung konfrontiert, selbst wenn sie nicht den ganzen Weg hin zu Microservices gehen. Die Vermeidung von Code-Duplikation, ein zentrales Problem in der Softwareentwicklung, wird schnell eine Rolle spielen. Da es nicht möglich ist, von jedem Service auf den eigenen Code zuzugreifen, ohne diesen in eine gemeinsame Bibliothek zu integrieren, wird der Wunsch nach einer solchen Bibliothek sehr schnell entstehen.

Nicht nur eine Bibliothek bauen

Die häufigste Lösung ist eine gemeinsame Bibliothek, die für den gesamten Code verwendet wird. Authentifizierung, grundlegende Definitionen von Datenbankschichten, Einstellungen für Integrationstests, Export von Excel-Dokumenten und vieles mehr werden in einer Bibliothek zusammengepackt.

Stellen Sie sich vor, Sie sind ein Entwickler in einem Team, das die Authentifizierung von Basic Auth auf OAuth2 umstellen möchte. Alles ist in der gemeinsamen Bibliothek vorbereitet. Sie müssen nur die Bibliothek auf den neusten Stand bringen und die Authentifizierung konfigurieren. Dann stoßen Sie auf das erste Problem: In der letzten Version der Bibliothek wurde der Dokumentenexport (der auch Teil der Bibliothek ist) geändert, um die Anforderungen eines anderen Projekts zu erfüllen. Nun müssen Sie zunächst alle Compiler-Fehler rund um den Dokumentenexport beheben. Und die Syntax für die Listener auf Ihrer Datenbankebene wurde geändert. Auch das müssen Sie jetzt beheben. Vielleicht möchten Sie Ihre Korrekturen zuerst testen, bevor Sie mit Ihrer ursprünglichen Änderung fortfahren? Auch das kostet Zeit.

In diesem Fall sind Sie gezwungen, alles, was in der gemeinsamen Bibliothek enthalten ist, gleichzeitig zu aktualisieren. Sie können nicht mehr wählen, wann oder was Sie aktualisieren möchten. Das Schlimmste ist jedoch, dass Sie dadurch gezwungen sind, Kontextwechsel zwischen verschiedenen Teilen Ihrer Anwendung durchzuführen, was Sie beim Arbeiten ausbremsen wird. Dieses Phänomen ist gut dokumentiert in Jeff Sutherlands Buch (Seite 87) [1]. Selbst wenn Sie sich grundsätzlich entscheiden immer alles zu updaten, können Sie Ihre Arbeit möglicherweise nicht so organisieren, wie Sie es möchten.

Lernen Sie von der Open-Source-Welt

Die offensichtliche Lösung ist, Ihre Bibliothek auf eine ähnliche Art und Weise aufzuteilen, wie es Leute online tun. Wenn Sie einen Blick auf GitHub- oder GitLab-Projekte werfen, werden Sie in der Regel Bibliotheken finden, die nur eine Sache tun. Wenn Sie ein Excel-Dokument erstellen müssen, verwenden Sie eine Bibliothek, die genau das tut. Die Excel-Bibliothek, die Sie online finden, wird in der Regel kein OAuth2-Modul enthalten.

Fazit

Organisieren Sie Ihren gemeinsam genutzten Code auf die gleiche Weise, wie die Leute es online tun. Teilen Sie ihn in verschiedene kleine Bibliotheken auf, die alle genau ein Anliegen abdecken. Die kommenden Teile werden sich mit den gängigen Implementierungen der REST-Kommunikation beschäftigen, die in der Regel Shared Code wie Schnittstellen und Datenklassen verwenden. Die Probleme, die dadurch langfristig entstehen, sind beim Entwurf einer neuen Architektur kaum absehbar, weshalb viele Teams zunächst den falschen Weg wählen.

Referenzen

[1]: Scrum: The Art of Doing Twice the Work in Half the Time, 2014, Sutherland, J. and Sutherland, J.J.