3 Minuten
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 zur Microservice-Architektur gehen. Die Vermeidung von Code-Duplikation, ein zentrales Problem in der Softwareentwicklung, wird schnell eine Rolle spielen. Erstmal ist es nicht möglich, von jeder Anwendung auf nützliche Tools und generische Komponenten zuzugreifen, die innerhalb des Teams oder Unternehmens entstanden sind. Dazu ist eine gemeinsame Bibliothek notwendig und der Wunsch nach einer solchen Bibliothek wird sehr schnell lauter.
Nicht alles in eine Bibliothek packen
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 dieser einen Bibliothek zusammengepackt.
Stell dir vor, du bist ein Entwickler in einem Team, das seine Authentifizierung von Basic Auth auf OAuth2 umstellen muss. In der gemeinsamen Bibliothek ist bereits alles vorbereitet. Du musst nur noch die Bibliothek aktualisieren und die Authentifizierung konfigurieren.
Dann stößt du auf das erste Problem: In der neuesten Version der Bibliothek wurde der Dokumentenexport (der auch Teil der Bibliothek ist) geändert, um die Anforderungen eines anderen Projekts zu erfüllen. Jetzt musst du zuerst alle Compilerfehler rund um deinen Dokumentenexport beheben. Außerdem hat sich die Syntax für die Listener auf deiner Datenbankebene geändert. Auch das musst du beheben. Vielleicht möchtest du deine Änderungen zuerst testen, bevor du mit deiner ursprünglichen Änderung fortfährst? Auch das kostet Zeit.
In so einem Fall ist man gezwungen, alle Inhalte der gemeinsamen Bibliothek gleichzeitig zu aktualisieren. Man kann nicht mehr wählen, wann und was man aktualisiert. Das Schlimmste ist jedoch, dass man dadurch gezwungen ist, Kontextwechsel zwischen verschiedenen Teilen der Anwendung vorzunehmen, was den Prozess einfach ausbremst. Das ist in [Jeff Sutherlands Buch (Seite 87) 1]1 gut dokumentiert. Selbst wenn man also trotzdem aktualisieren will, kann man seine Arbeit nicht so organisieren, wie man es möchte.
Von der Open-Source-Welt lernen
Die naheliegende Lösung ist, die Bibliothek so aufzuteilen, wie es die Open-Source-Community macht. Wenn man sich GitHub- oder GitLab-Projekte anschaut, findet man in der Regel Bibliotheken, die genau ein Problem lösen. Wenn man ein Excel-Dokument erstellen muss, verwendet man eine bestimmte Bibliothek, die genau das tut. Die Excelbibliotheken, die man online findet, enthalten kein OAuth2-Modul.
Fazit
Um die Vorteile von geteiltem Code nutzen zu können, ist es hilfreich von der Open-Source-Community zu lernen. Sprech, den Code in verschiedene kleine Bibliotheken aufzuteilen, die alle genau ein bestimmtes Problem lösen. So können einzelne Bibliotheken unabhängig voneinander aktualisiert werden, unnötige Kontextwechsel und Anpassungen werden vermieden.
Referenzen
[1]: Scrum: The Art of Doing Twice the Work in Half the Time, 2014, Sutherland, J. and Sutherland, J.J.
