mehr material

README.md

@@ -21,9 +21,83 @@
   - 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 dependencies.
+  - 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
+  - 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