/NUrZxHMGas

Green Coding

Links:

Mobile First , Accessbility First

Prozess-Lebenszyklus optimieren

Kommunizieren auch außerhalb der Entwickler-Bubble
Stakeholdern klarmachen welche Variante/Ziele (Servertool vs. Singletool) welche umsetzen wird

Obsoleszenz

Technologieauswahl

Carbon Awareness

Datenmüllflut

Emissionen Messen:

Messen schön und gut als Zusatzmaßname, aber Low Hanging Fruits wichtiger:
- Nachts/Wochenende dev Server runter fahren
- Features hinterfragen
- Geräte länger unterstützen
- ....
Seiten die häufig aufgerufen werden, eher Seiten messen, ansonsten ist das Optimierungspotential auf Serverseite höher (da wo kleine Änderungen viel bewirken können)
schon vorhandene Daten nutzen
- Cloud Anbieter (AWS, Google Cloud..) stellen schon Infos zu CO2 Verbrauch zur Verfügung
- Google Lighthouse / Firefox Profiler hat Informationen (oft unter Performance)
- Webseiten kann über Testseiten gestestet werden (Website Carbon Calculator, Cleaner Web Klimatest...)
muss nicht reale Emissionen wiederspiegeln:
- mit sich selbst vergleichen
- "Zählen von Servern"
- Verbesserung gegenüber letzter Messung
nette Seiteneffekte klar machen:
- gut an Kunden verkaufbar
- Performance Optimierung
- Kostenersparnisse feststellbar
nach außen Kommunizieren:
- Blauer Engel für Software <- Zertifizierung
- CO2 Challenge <- Karlsruher Initiative in der sich Firmen selbst herausfordern 40% CO2 zu reduzieren (kein Wettbewerb)
- für andere Nachvollziebar machen mit der SCI-Formel
- Video/Bilder Auflösung

UN-Nachhaltigkeitsziele

Geschlechter-Gleichstellung:
- Geschlechtseintrag in Formularen
- bias durch machine learning / in Algorithmen
Weniger Ungleichheiten:
- Zugang ermoeglichen
- finanzielle Unterstuetzung // open source
- physische Erreichbarkeit
Menschenwuerdige Arbeit:
- Vermeidung von Software, die unter menschenunwuerdigen Bedingungen produziert wurde (Bsp: Click- Worker ChatGPT)
- Alternativen schwierig zu finden/ Huerden fuer Nutzung gross
Widerstandsfaehige Infrastruktur:
- Dezentralisierung / single points of failure vermeiden/minimieren
- mehr finanzieller Einsatz fuer robuste Systeme
Nachhaltigen Staedte/Gemeinden:
- robuste Software einsetzen
- Kritis unabhaengig und nicht proprietaer
Grundsaetzliches:
- bei Entwicklung beachten, dass Risiko fuer Ausschluss bestimmter Gruppen (z.B. offline-Angebote) besteht --> Schnittstellen schaffen/ Konkurrenz vermeiden
- weg von Gewinnmaximierung
- Dekapitalisierung von Infrastruktur (Beispiel wie Fediverse)
- Solidarisch mit sozialen und gruenen Bewegungen sein, intrasektional mit demonstrieren

Daten minimieren

Reproducible builds und dann dependencies nicht per Schedule updaten, sondern nur bei Änderungen: https://docs.renovatebot.com/getting-started/running/#docker-images
- Wo läuft der "nightly build"? Auf https://app.electricitymaps.com/map gucken, wann dort de Strommix physikalisch grün ist (nicht nur laut RZ-Zertifikat) und scheduled jobs in jene Zeiten legen (mittags = "lunchly build")
Dependencies ausmisten/minimieren, insb. wenn nur wenige Code-Pfade derselben benutzt werden.
Bei Ausbildung / Pair Programming auf profiling & observability, einfachere Tools, etc. achten
- Erwartungen kommunizieren: "Wie schnell sollte ein Web Request sein?" "Ab 200ms gibt es wohl ein Problem!"
Big Data mit grap & Co, statt Hadoop, etc.
- https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html
- https://stackoverflow.com/questions/9066609/fastest-possible-grep/9067042#9067042
Immutable Data Structures & Event Sourcing
Datenfluss visualisieren & Events modellieren

Ereignisbasierte Architektur

Eventbasierte Kommunikation erhöht i.d.R. die Komplexität
Man braucht Entwickler*innen, die Erfahrung damit haben
Entscheidung für eine Architektur sollte kollaborativ gefällt werden -> RFCs, Peer-Reviews
Rolle des Managements: Nachhaltigkeit als Ziel setzen, ABER erst wenn betriebswirtschaftlich das Unternehmen überlebt
Hosting-Kosten als Proxy für den Nachhaltigkeits-Impact
Auf Unternehmenseben: Nachhaltigkeit in der Software-Entwicklung kann mit anderen Nachhaltigkeits-Zielen konkurrieren

Überkomplexität vermeiden

Technische Komplexität != kognitive Komplexität
Messen ob Features benutzt werden
Aber: Messen erhöht auch die Komplexität! Zusätzliche Tools, Extra-Requests etc.
Ab wann macht es Sinn, zu messen?
Neue Technologien nur mit sehr gutem Grund einführen, im Team diskutieren, auf stabile Technologien setzen
Rolle der*des Tech Lead: kritisch prüfen, ob eine Technologie eingesetzt werden soll
aber alle Teammitglieder sollten sich in der Verantwortung fühlen
Rolle der*des PO: Muss Raum für Verbesserungen und gute Implementierung lassen