Nachhaltige Softwareentwicklung

Einweg kann weg

Wie Software länger lebt.

Meine Freundin und ich besitzen jetzt einen Wassersprudler. Wir wollen unseren Verpackungsmüll reduzieren. Einwegprodukte kaufen wir kaum noch. Es stört uns Geld für etwas auszugeben, das direkt wieder im Müll landet.

Schlimmer noch ist es bei der Arbeit. Mich frustriert es Software herzustellen, die bald wieder im Müll landet.

Zuletzt mussten wir große Teile unsere Webanwendung wegwerfen und neu bauen. Auf diese Komponenten waren wir bei Veröffentlichung stolz. Das ist nicht lange her. Jetzt stellen sie sich als Einwegkomponenten heraus. Einwegsoftware.

Versteht mich nicht falsch. Als Entwickler ist es normal, dass sich Technologien schnell ändern. Sie erlangen rasant Relevanz und sind noch schneller vergessen. Das ist normal, aber manchmal eben frustrierend.

Wie können wir das Leben unserer Webanwendung verlängern? Wie können wir nur Kleines ersetzen? Es braucht weniger Zeit und tut weniger weh.

In unserem Projekt nutzen wir Angular von Google. Seit Version 6 können wir einzelne Anwendungen in einem gemeinsamen Workspace organisieren. Wir nutzen diese Organisation, um eine große Anwendung in mehrere kleine aufzuteilen. Diese Mikro-Anwendungen basieren so auf einer gemeinsamen Technologie und entwickeln sich dennoch eigenständig.

Die Komponenten innerhalb der Mikro-Anwendungen ähneln sich. Wir brauchen immer Knöpfe oder Eingabefelder. Der Kunde gibt vor, wie sie aussehen und sich verhalten sollen. Ich kann dieses Aussehen jetzt in jede Anwendung programmieren. Ich baue also drei Knöpfe, drei Einwegknöpfe. Bitte nicht schon wieder.

Angular bietet auch die Möglichkeit Bibliotheken zu schreiben. Sie sind eine Sammlung loser Komponenten und besitzen keine eigene Oberfläche. Anwendungen können diese Bibliotheken konsumieren und ihre Komponenten für sich nutzen. Wir können einen Knopf so mehrfach verwenden. Wir bauen Mehrwegknöpfe.

Damit die Knöpfe dann auch sichtbar werden braucht es unseren UX-Designer. Der erledigt genauso ungerne Dinge doppelt, programmiert aber nicht. Bisher konnten wir ihn auch noch nicht überzeugen damit anzufangen. Diese Künstler.
Er stellt Designartefakte her und organisiert sie angelehnt an das Atomic-Design. Wir stehen während der gesamten Phase der Entwicklung, also von Design bis Test, in engem Austausch. Die Komponenten werden nach gemeinsamen Vorgaben organisiert. Beide Seiten nutzen aber vollkommen unterschiedliche Werkzeuge, um diese Komponenten herzustellen.

Allein diese Werkzeuge führen zu Brüchen in der Kommunikation. Uns ist häufig nicht klar, wie der Kollege die Komponenten definiert hat. Abstände, Farbwerte und Schriftarten müssen wir erfragen. Wie schließen wir diese Lücke und kommen schnell an die Informationen, die wir benötigen? Wie kann das Mehrweg-System zu einem geschlossenen Kreislauf werden?

Ideen haben wir schon und auch erste Erfahrungen. Ein paar gesprudelte Flaschen Wasser müssen noch die Kehle hinab rinnen, bis ich das genauer beschreiben kann.

Jetzt teilen: