razzfazz.io pflanzt Bäume
Software. Agile. Developed. Tested. Documented. razzfazz.io is faster than you can say performance!
Wien, 08.07.2025 (PresseBox) - Als Entwickler:in verwendet man täglich unterschiedlichste Software, wahrscheinlich mehr als die meisten anderen Nutzer:innen. Durch das Erleben zweier Perspektiven – Nutzung und Entwicklung – erlebt man auch mehr als bei dem Rest der Verwender, das Stoßen auf Probleme oder schlicht Ärgernisse, die einem die Benutzung erschweren.
Die Kehrseite davon ist, dass man auch aktiv Einfluss darauf nehmen kann und die Software, die man verwendet, analysieren und verbessern kann. Nichts ist ein besseres Beispiel davon, als unser hauseigener SEQITracker*, den wir alle verwenden und für dessen Umsetzung und Wartung wir verantwortlich sind. Wenn wir Schwierigkeiten und Unstimmigkeiten bei der Nutzung entdecken, oder rückgemeldet bekommen, setzen wir uns zusammen und arbeiten daran.
Ähnlich ist es für die VS Code Extension: GitLab Workflow[1] abgelaufen. Die Integration von GitLab Merge Requests[2] in unseren Standardablauf hat bedeutet, dass wir auch ohne Context-Switching aus der IDE weiter Code Reviews durchführen wollten. Dem hat GitLab mit der Entwicklung der eigenen VS Code Extension abgeholfen, die einen Großteil von Features des Web-UIs abdeckt. Leider wurde aber nie eine vollständige Feature-Parity erreicht und besonders das Verfassen von Reviews aus den VS Code Webviews ist nicht vergleichbar mit dem Komfort und den Möglichkeiten des Web Äquivalents.
Die Recherche zu Alternativen oder Lösungen blieb fruchtlos; so entstand die Idee, eine zeitliche begrenzte Entwicklung eines der fehlenden Features selber umzusetzen zu versuchen. Die Einsicht, wie stark die andauernde Nachfrage nach spezifisch dieser Funktionalität ist, hat dieses Commitment nur bestärkt.
Problem
Die Ausgangslage ist in bestehenden Issues bereits ausführlich diskutiert, mein Fokus war beschränkt auf:
Review und Draft-Notes Feature für GL Workflow
- Unterstützung für Draft Notes, die in GitLab als Entwürfe gespeichert werden können
- Darstellung und visuelle Unterscheidung dieser in der Code-Review Ansicht
Optimierung des API-Handlings
- Einführung einer diskriminierten Union zwischen Nachrichten der API, die als GQL und JSON übermittelt werden
- Konditionelles Abhandeln dieser in UI
Strategie
Der Großteil des Entwicklungsaufwands bestand aus der Analyse der bestehenden Codebasis, sowie der GitLab-API und der Anbindung an diese. GitLab verfolgt dabei eine hybride Architektur und bietet eine klassische nach OpenAPI spezifizierte REST API, sowie auch eine versionslose GRAPHQL API, an. Für die Umsetzung ist diese Unterscheidung relevant geworden: Die Draft Notes werden nur von der REST API unterstützt.
Initial war mein Ansatz, nicht abgegebene Kommentare (= Draft Notes) lokal, in Memory zu halten und nach entsprechender Interaktion des Users zusammen (= in Batch) an die API zu posten. Der erste Stand meiner Entwicklung, der noch diese Strategie verfolgte und als PoC von dem verantwortlichen GitLab Maintainer unter die Lupe genommen wurde, war zu komplex und zu umständlich, um so übernommen zu werden. Nach Rücksprache wurde meine andere Konzeption bevorzugt: einen „API-First“ Approach.[nbsp] Die Verwendung der Draft Notes API hilft dabei, nicht für jeden einzeln veröffentlichten Kommentar Benachrichtigungen für alle an der Review beteiligten Nutzer auszulösen.
Wie bereits oben bei der Problemstellung erwähnt, hat die Lösung mit Draft Notes zu Folge, dass der gesamte Code für das Fetchen, Konvertieren und Darstellen von Kommentaren und Diskussion für Draft Notes angepasst werden muss.[nbsp] So ist nun der jetzige Status der Umsetzung. Nach dem Fertigstellen der Unterscheidung und meiner Anfrage wird ein Ablauf losgetreten, in dem mein Beitrag aus Code und UX Perspektiven evaluiert wird.
Code, der wächst
Zum springenden Punkt, wie das bisher diskutierte nun Nachhaltigkeit bedeutet und was es mit den Bäumen auf sich hat:
Indem man Features verbessert, Bugs fixed oder an neuen Funktionen arbeitet, sammelt man automatisch Punkte. Anstatt sie für Merchandise oder andere Prämien zu nutzen, gibt es die Möglichkeit, sie in Nachhaltigkeit zu investieren – konkret in das Pflanzen von Bäumen.
Zum jetzigen Zeitpunkt ist nur ein einzelner Baum in unseren Namen bestellt, aber mit der Fertigstellung und Mergen der finalen Kontribution sollten ein Minimum von 20 Bäumen mehr durch uns gedeihen dürfen. Weitere Updates dazu gerne in Kürze!
Nachhaltige Softwareentwicklung?
Besonders durch den enormen Energieverbrauch, der mit der zunehmenden Verwendung von generativer AI verbunden zu sein wirkt[3] stellt sich die Frage, welche Verantwortung wir als Entwickler:innen sowie Unternehmen im Technologiesektor haben. Bereits früher in meiner Karriere durfte ich mich mit der Energienutzung verschiedener Programmiersprachen auseinandersetzen.[4]
Auch, wenn die Methodik dieser Messungen umstritten ist, ist es nicht gerade erfreulich, die eigenen Lieblingssprachen in den oberen Rängen des Verbrauchs zu sehen.
Fazit & Caveat
Spannend wird die Weiterentwicklung und der Verlauf des Merge Request, ich freue mich schon sehr auf den Zeitpunkt der Fertigstellung und besonders auf die Verwendung des neuen Features.
Natürlich kann der tatsächliche Energieverbrauch, der durch die Entwicklung und den Betrieb dieser Features entsteht, nicht durch das Pflanzen weniger Bäume aufgewogen werden. Doch es geht darum, Bewusstsein zu schaffen, nachhaltige Praktiken zu fördern und zumindest einen kleinen Beitrag zur Kompensation zu leisten.
Vielleicht ist es Zeit für mehr Entwickler:innen, Unternehmen und andere Organisationen, Open Source nicht nur als technischen Vorteil zu sehen, sondern auch als Möglichkeit, aktiv zu einer besseren Welt beizutragen. Eine Merge Request nach dem anderen – und ein Baum nach dem anderen.
