update

Writerside/topics/02/OOAD/AgileDesign.md

@@ -0,0 +1,86 @@
+# 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
+