RDD

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?
2. Alles hat seine Kosten
   • Meistens kostet es dich Komplexität
     • Vergleichbar mit Werbung und Aufmerksamkeit
   • Cyclomatic Complexity / Cognitive Complexity
   • Physik: überschüssige Energie wird Wärme; Code: überschüssiger Code wird Komplexität

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