87 lines
3.1 KiB
Markdown
87 lines
3.1 KiB
Markdown
# 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
|
|
|