Rallye Driven Development

Definition von RDD

1. Code ist nur Mittel zum Zweck, setze so wenig wie nötig davon ein
   • Jede Zeile muss sich stets aufs Neue beweisen
   • Tests:
     • Tests dürfen nie zum Selbstzweck existieren - "weil man das so macht"
     • Abdeckung ist vollkommen egal
       • Nur wichtiger Code muss getestet sein
     • Wann ist ein Test wichtig? Wenn er Klärung bringt
   • Bringt diese Zeile Code mir etwas?
     • Befriedigt sie nur irgendwelche Frameworks oder Patterns?
   • Wozu braucht man während eines Rennens eine Klimaanlage oder elektrische Fensterheber?
2. Alles hat seine Kosten
   • Meistens kostet es dich Komplexität
     • Und damit den Verstand
     • Vergleichbar mit Werbung und Aufmerksamkeit
   • Cyclomatic Complexity / Cognitive Complexity
   • Physik: überschüssige Energie wird Wärme; Code: überschüssiger Code wird Komplexität
   • Quattro-Autos waren schwerer als die Konkurrenz, brauchten mehr Leistung, die Fahrer mussten lernen, mit den Wagen zu fahren
3. Verbaue dir nicht deine Möglichkeiten
   • Änderungen werden kommen (Kunde)
   • Änderungen werden nötig sein (Architektur)
   • Du wirst Änderungen vornehmen wollen (Aufräumen)
   • Es wird inkompatible Änderungen geben (DB)
     • Keine Annahmen treffen, explizit sein
     • Nicht zuviel in einer Aufrufhierarchie machen
   • Das Differential muss auf der Rennstrecke tauschbar sein
4. Der gesunde Menschenverstand hat das letzte Wort
   • Kürzerer Code mag besser sein, aber wenn er unlesbar ist, ist er unwartbar und damit unbrauchbar

Zusammenfassung

Rallye-Meisterschaften stellen die Fahrzeuge, ihre Fahrer und die Konstrukteure vor ganz besondere Herausforderungen. Im Gegensatz zu Rundrennen wird hier nicht auf speziell konstruierten Strecken, sondern auf abgesperrten Straßen- und Schotterabschnitten bei Wind und Wetter gegen die Uhr gefahren. Dabei reicht die Variation von waldigen Strecken in Finnland bis zum afrikanischen Kontinent. Um diesen stark unterschiedlichen Ansprüchen zu genügen und die Fahrzeuge derartig anpassbar zu gestalten, muss vor allem eins gegeben sein: Simplizität. Ich möchte bei meinem Vortrag Parallelen zwischen der Softwareentwicklung und dem Rallyefahren herausarbeiten und versuchen, Prinzipien aus dem Sport auf unsere Tätigkeit als Entwickler anzuwenden. Wie schafft man es beispielsweise seine Software so zu konstruieren, dass man am Straßenrand das Differential auswechseln kann? Wieviel Schrauben muss man am Kotflügel lösen, um mitten im Sprint eine größere Anpassung an der Architektur vorzunehmen? Dabei soll auch nicht davor zurückgeschreckt werden, mit alteingesessenen Mustern und Grundsätzen zu brechen, um herauszufinden, ob sie wirklich so universell sind, wie es viele glauben. Denn: ohne radikal zu denken, schafft man es nicht, von 0 auf 100 in unter 2,6 Sekunden auf Schotter zu beschleunigen.

Kürzer

Bei Rallyes wird nicht auf Rennstrecken, sondern auf abgesperrten Straßen bei Wind und Wetter gefahren. Um diesen Strapazen zu widerstehen muss vor allem eins gegeben sein: Simplizität. Ich möchte unsere Softwareentwicklung fit für den Wahnsinn des Alltags machen und versuchen, Prinzipien aus dem Sport auf unsere Tätigkeit als Entwickler anzuwenden. Wie schafft man es seine Software so zu konstruieren, dass man am Straßenrand das Differential auswechseln kann? Wieviel Schrauben muss man lösen, um die Architektur zu verändern? Dabei soll auch nicht davor zurückgeschreckt werden, mit bekannten Mustern und Grundsätzen zu brechen, um herauszufinden, ob sie wirklich so universell sind. Denn: ohne radikal zu denken, schafft man es nicht, in unter 2,6 Sekunden auf Schotter auf 100 zu sprinten.

Dramatis persona

Aus Goslar stammend und mit Braunschweig als Wahlheimat arbeite ich seit mehr als 10 Jahren als Javaentwickler in allen Bereichen, die Software zu bieten hat. Dabei interessiert mich am Meisten die Meta-Seite der Entwicklung: wie baut man Code, der noch in der fernen Zukunft flexibel und wartbar ist? Wie kann man zusammen an Software arbeiten, ohne sich gegenseitig auf die Füße zu treten? Dabei beschäftige ich mich nicht nur mit Java allein, sondern habe im Bereich Cluster-Computing Kotlin zu schätzen gelernt und beim privaten Programmieren Clojure entdeckt und mich dabei Hals über Kopf darin verliebt.

Was

• Wo findet sich Komplexität
  • Unterschied Technische Komplexität und Fachliche Komplexität
• Schlaue Lösungen / Schlaues Denken
  • Reinsteigern in Verfeinerung von Lösungen
  • Rauszoomen
• Nur langweiliger Code ist guter Code
• Über Dinge reden, die nicht da sind
• Dinge so bauen, dass sie nicht fehlschlagen können
• Bei bestehenden Mustern bleiben
  • Der Marsianer
• Clojure
  • cli build tool
  • Simple vs Easy
  • Functional design patterns
  • https://de.slideshare.net/ScottWlaschin/fp-patterns-buildstufflt
• Tools -> Spargelschäler der IT-Welt
  • https://medium.com/the-minimalist/the-minimalist-programmer-c36e16ebf8ef
• Definitionen von Complexity
  • Complexity is anything that makes software hard to understand or to modify.
  • Wieviel Dinge muss man im Kopf behalten, um eine Aufgabe umsetzen zu können
    • Dazu zählt auch eine gute Umgebung - IDE und Arbeitsumgebung
      • Wieviele Aufgaben wurden mir erteilt
      • In wie vielen Projekten stecke ich drin
• Aussagen zu Complexity
  • Complexity is more apparent to readers than to writers. If other people think a piece of code is complex, it is
  • Isolating complexity in places that are rarely interacted with is roughly equivalent to eliminating complexity.
  • Complexity is caused by obscurity and depen dencies.
• Lindbergh war der Meinung, dass beim Ausfall eines Motors eines voll beladenen mehrmotorigen Flugzeugs die verbleibenden Motoren die Maschine auch nicht in der Luft halten könnten. Das Risiko eines Motorenausfalls steige aber mit der Zahl der Motoren.
  • https://de.wikipedia.org/wiki/Spirit_of_St._Louis
• Messy codebase die funktioniert, ist besser als eine saubere, die nicht funktioniert
• Sarah Mei: Carving services out of a monolith and carving objects out of a large class are the same skill
  • Object boundaries sind einfacher anzupassen als service boundaries
• Was will man mit einer Architektur erreichen?
  • Einfache Erweitbarkeit
  • Der Fachlichkeit gerecht werden
  • Best Practices einhalten
  • Technologische Neugier befriedigen
  • Dem Code Struktur geben
• Wo will man lose Kopplung erhalten?
  • DB und Backend, Applikationen, Services, Layer, Slices, Klassen, Objekten, Funktionen
• Wer kennt die Anforderungen
• Tradeoff zwischen Cost of Understanding und Cost of Change
• Was sind Layer
  • Systemgrenzen
  • Klassengrenzen
  • Packages
  • Proxies in Menschenkommunikation
  • Architekturgewichse
  • Patterns
    • Factory
    • Decorator
  • Systemische Hürden
    • Docker
  • Branches
  • Git-Flow
    • "Das geht so aber nicht in Git-Flow"
  • Benamung
  • Paradigmenwechsel
  • Coderauschen
• Wer hat schon OO so richtig verstanden?
  • Warum benutzen wir es denn?
  • Teamowner lädt jemanden in ein Team ein, Eingeladener erhält Mail
    • Entities: Team, Owner, Account, Member
    • Wer ist Akteur?
    • Wo ist das Aggregate Root?
    • DDD oder OO nach ursprünglicher Lehre?
    • Domänenservice?
    • Wer verschickt die E-Mail?
      • Event-Hub?
        • Für ein Programm, das < 5k Locs hat und zwei verschiedene Events?
  • Wer hindert mich daran, alles in den MVC-Controller zu packen und es funktioniert?
    • Refactoring ist immernoch möglich
• Tesla wird von einer Reihe Python-Skripten zusammengehalten
  • https://twitter.com/atomicthumbs/status/1032939617404645376
• Alles hat seine Kosten
  • Ist man bereit sie zu zahlen
  • Ist es wert
  • Hat man genug Budget
• SOLID
  • Single Responsibility
    • Was ist eine Responsibility überhaupt
  • Open/Closed
    • Aber wir wollen doch Code ändern können!
    • "Code bauen ist einfacher, als ihn zu verändern"
      • Mehr Code oben drauf? Ernsthaft?
  • Liskov substitution
    • A: B, überall wo A, auch B benutzen können
    • Composition over Inheritance?
    • Wer kümmert sich schon darum?
  • Interface Segregation
    • Keine großen Klassen!
    • Ach was
  • Dependency Inversion
    • Von Abstraktionen abhängen
    • Interface - Impl
    • DI ist Implementierung von D
      • Objekte reingeben lassen
      • Entscheidungen nach außen delegieren
    • Gute Idee
      • Global State?
  • Wer kennt überhaupt alle einzelnen Bedeutungen
    • Ist es dann so wichtig?
• Verhalten testen, nicht Implementierung
• Kennt eure Werkzeuge und lernt, sie effektiv einzusetzen
  • Opel Ascona 400
    • ca 1T fahrbereit
    • 230 bis 300 PS
    • Audi Quattor mit Allrad und 300PS, aber auch 1,2T Gewicht, gleichzeitig im Rennen
    • Röhrl gewinnt Weltmeisterschaft
  • Fiat Abarth 131
    • 2 Liter Hubraum, 140 PS, 950kg
    • Röhrl 1980 Weltmeister
    • Setzte sich durch gegen
      • Lancia Stratos HF 280PS, Ferrari-Motor, V6, 2,4L, 880kg
      • Saab 99 Turbo, 200PS
      • Mercedes 450 SLC 5.0, 5L, V8, 225PS
• Im Fiat 131 Homologationsmodell wurden an der Vorderachse untaugliche, da zu schwache, Bremsen verbaut. Für den Motorsport war dies egal, am Rennmodell wurden Motorsportteile verwendet.
• UNIX ping hat ca 1000 Zeilen Code
• Designer schieben Elemente hin und her um zu gucken, wie ELemente anders angeordnet aussehen
  • Warum kann so etwas in Software nicht gemacht werden?
  • Warum wird das nicht vorangetrieben?
  • Warum wird das aktiv vermieden?
• Welche Architekturstufen gibt es?
  • Stufe 0: Keine
  • Stufe 1: Architektur aus dem Internet
    • Zwiebel
    • DDD
    • Microservices
  • Stufe 2: Mit Wissen selbst auf Anwendungsfall angepasst
• Codestil
  • Clarity
  • Concise
  • Verbose
• /u/captain_pablo Software, like religion, has almost no constraints so almost everybody's opinion is valid. Unlike engineering where if your opinion is wrong the roof falls down on your head, as a reminder.