# Agile Design
> [UML](UML.md) ist nicht Software Design

- Diagramme repräsentieren einen Teil des SW-Designs
  - Source Code
- Design ist ein abstraktes Konzept
  - Struktur und Form des Projekts
  - Detaillierte Beschreibung der Klassen, Module, Methoden


## What goes wrong with Software
- Im besten Fall
  - Projekt startet mit klarem Bild, was das System tun soll
    - Design ist ein Bild in den Köpfen der Devs
    - Mit Glück: Klarheit des Designs schafft es bis zum ersten Release
- Häufig geht vorher was schief
  - Programm wird schwieriger wartbar
  - kleinste Änderungen werden kompliziert
- Neudesign geht meistens schief
  - Das alte System wächst weiter, neues muss mithalten
  - Probleme im neuen Design entstehen
- Software geht kaputt, wenn es anfängt mit Design Smells:

## Design Smells
### Rigidity (Steifigkeit)
- Das Design ist schwer zu ändern
  - Code ist schwer zu ändern
    - kleine Änderungen erzeugen Probleme in dependent Modulen
    - je mehr Module geändert werden müssen, desto mehr steif ist das Design
- Ergebnis:
  - Änderungen dauern deutlich länger als gedacht

### Fragility (Zerbrechlichkeit)
- Das Design ist einfach kaputtzumachen
- Neue Probleme sind in unvorhergesehenen Umgebungen
  - Lösen dieser Probleme führt zu neuen Problemen
  - Fragilität wird mit der Zeit höher
- Ist sehr normal
  - Module sind bekannt dafür, dass sie repariert werden müssen
  - Sind auf der Bug Liste
  - Niemand will sich der Aufgabe widmen

### Immobility
- Das Design ist kaum neu zu benutzen
  - Enthält Teile, die in anderen Systemen sinnvoll wären
    - Risiko involviert in Aufteilung
- Ungünstig, aber sehr häufig

### Viscosity
- Es ist schwer das Richtige zu tun. Zwei Formen:
1. Viskosität der Software
    - Devs entscheiden zwischen Designerhaltung und einfacher Lösung
    - Design sollte design erhaltende Änderungen fördern
2. Viskosität der Umgebung
    - Umgebungen, die einfache statt design erhaltende Änderungen
    - Lange compile Zeiten verringern Lust auf recompilen
    - Lange VCS-Check-ins verringern Check-ins

### Needless Complexity 
- Ein Design enthält Elemente, die momentan nicht nützlich sind
- Passiert häufig, wenn Devs Änderungen erwarten
  - Vorbereitung für zukünftigen Code
  - Das Design muss das Gewicht dieser Elemente nun mittragen
  - Manche Vorbereitungen sind nützlich, aber nicht alle
- Software wird komplex

### Needless Repetition
- Copy Paste sollte nicht benutzt werden
  - Wenn Code mehrfach in minimal unterschiedlichen Formen vorkommt
    - Devs haben Abstraktion vergessen
    - Wiederholungen sollten gefunden und beseitigt werden
- Wiederholender Code macht Änderungen schwierig
  - Bugs müssen in allen Wiederholungen geändert werden
  - Änderungen nicht immer gleich in allen


### Opacity
- Code ist in einer unverständlichen Art geschrieben
  - Häufig in Code der über Zeit weiterentwickelt wird
- Benötigt konstanten Einsatz den Code clean zu halten
  - Wenn Code das erste Mal geschrieben wird, scheint er clean
    - Verständnis auf intimer Ebene
- Devs müssen aus der Sicht eines Außenstehenden gucken
  - Refactor bis Leser es verstehen können
  - Code von anderen lesen lassen