This commit is contained in:
David Schirrmeister 2025-04-14 13:28:08 +02:00
parent f8f954f98f
commit 2036b2ce1a
7 changed files with 98 additions and 1 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 49 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 64 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 56 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 56 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 49 KiB

View File

@ -519,4 +519,101 @@
- höhere Code-Qualität
### Pairing Styles
-
#### Pairing Style: Driver and Navigator
- **Fahrer**
- Person an der Tastatur
- ist fokussiert das nächste kleine Ziel zu erreichen
- ignoriert größere Probleme
- sollte die ganze Zeit mitreden, was er tut
- **Navigator** (_hoffentlich ohne link rechts Schwäche_)
- ist in der überwachenden Position, während der Fahrer tippt
- Reviewed den Code durchgängig
- direktes Feedback
- Hat auch größere Probleme, Bugs im Kopf
- Notizen für mögliche nächste Schritte
- **Möglicher Arbeitsablauf:**
- ![image_663.png](image_663.png)
#### Pairing Style - PingPong
- Perfekt für einen TDD-Task
- **Ping**
- Dev A schreibt einen fehlschlagenden Test
- **Pong**
- Dev B schreibt Implementierung damit er klappt
- **Ping**
- Dev B schreibt den nächsten Test
- Bei jedem Pong kann man auch nochmal refactoren
#### Pairing Style - Strong-Style Pairing
- Super für Wissenstransfer
- Regel: "Jede Idee, die von deinem Kopf in den Computer soll, muss durch die Hände von jemand anderem gehen"
- **Navigator**
- erfahrene Person
- **Fahrer**
- Person die was lernen will/soll
- sollte dem Navigator voll vertrauen
- Warum?-Fragen und Challenges nach dem Implementieren besprechen
#### Pairing Style - Research and Explore
- Überlegen und herausfinden ist häufig notwendig
- bspw. bei neuen Technologien etc.
- Wie kann man das im Pair-Modus angehen
- Liste mit Fragen für eine mögliche Situation machen
- Aufsplitten für einzelne Zeitslots
- entweder Fragen aufteilen oder gleichzeitig Antworten auf gleiche suchen
- Zusammenkommen und diskutieren/teilen was man gefunden hat
#### Pairing Style - Documentation
- Je nach Situation und Präferenz
- Dokumentation zusammen machen
- Einer schreibt, anderer macht Anmerkungen
### Benefits / Challenges
| Vorteile | Herausforderungen |
|--------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|
| Wissensaustausch | Kann anstrengend sein |
| Reflektion: hat mans wirklich (richtig) verstanden? | Verschiedene Skill Levels: Können zu falschen Erwartungen und Frustration führen |
| Fokus behalten: Zusammen arbeitet man strukturierter, keine "schnellen" side-quests | Power-Dynamics: Chef-Mitarbeiter → kann das ganze schwierig machen |
| Code Review on-the-go: | Pairing erfordert Verletzlichkeit: ist schwer zu sagen, dass man etwas nicht weiß/kann - aber notwendig |
| Zwei Denk-Modi kombiniert: verschiedene Perspektiven haben | Chef überzeugen, dass es gut ist |
| Gemeinsames Code-Ownership: Höhere Chance, dass jemand sich traut Änderungen vorzuschlagen | |
| Schnelles Onboarding | ![image_665.png](image_665.png) |
| ![image_664.png](image_664.png) | ![image_666.png](image_666.png) |
## Static Code Analysis
- Code analysieren, ohne ihn auszuführen
- Tools inspizieren das Programm für ...
- alle möglichen Verhalten
- suchen Coding-Fehler, Back-Doors, ...
- generieren Metriken für den Code die helfen die Qualität zu analysieren
- Kann Qualität verbessern
### Beispiele für die Identifikation von Bekannten Problemen und Bad Practices
- **Generische Beispiele**
- Größe
- Kann verschieden gemessen werden
- _Code-Zeilen, Klassen, Dateien, Funktionen, ..._
- Kommentare
- zeigen häufig, dass der Code zu komplex ist
- Duplikate
- _Dont repeat yourself!_
- **Sicherheitsrelevante Issues**
- OWASP Top Ten
- Sammlung von kritischen Risiken für Anwendungssicherheit
- SAST Tools
- finden bekannte Risiken
### Simple Metrik für Komplexität: McCabe Metrik
![image_667.png](image_667.png)
- Cyclomatische Komplexität
- Behandelt Programmstuktur als Graphen
- Wird folgendermaßen kalkuliert:
- $$C = E-N + 2P$$
- E = Nummer der Ecken
- N = Nummer der Nodes
- P = Nummer der verbundenen Komponenten (für eine OO Funktion ist P = 1)
- Beispiel:
- $$C = 9-8+ (2*1) = 3$$
- ![image_668.png](image_668.png)